February 2018 - Koha-bugs - lists.koha-community.org

[Bug 19280] New: CanBookBeIssued must take a Koha::Patron in parameter
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19280 Bug ID: 19280 Summary: CanBookBeIssued must take a Koha::Patron in parameter Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We need to make subroutine from C4 use more Koha::Object objects Seeing bug 19276, starting here is a good start. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 9262] Patch complexity field user interface is awkward to use
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9262 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org Severity|major |minor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 7882] Add ability to move and reorder fields in MARC editor
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7882 David Bourgault <david.bourgault(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david.bourgault(a)inlibro.com Status|Failed QA |In Discussion --- Comment #44 from David Bourgault <david.bourgault(a)inlibro.com> --- >There's a more serious issue, however, which isn't caused by this patch but which would become more obvious with it -- if you open the record again in the editor, field order isn't maintained. For example, if you construct your record so that subject headings are in the following order: > >650 $aElizabethan theatre >600 $aShakespeare, William > >Then open it up again in the editor, the 600 will be displayed before the 650, even though the 650 field is stored first in the record. This has the potential to be seriously confusing to users, and I feel that a patch that allows sorting of the fields in a user-specified order needs to be accompanied by work that makes the editor display existing fields in the order that they appear in the record. This raises another question as to how to order the fields when loading a Marc record. Let [1,2,3,4] be the framework structure Let [1,4,2] be the saved record Currently we load on the framework structure order, giving us 1, 2, 3 (empty), 4 This does not respect the saved record order. But if we load according do the saved record order, where should the empty tag (3) go? Should we place it before the saved record's fields or after? Or do some weird half-sorted behavior? before : [3 (empty), 1, 4, 2] after : [1, 4, 2, 3 (empty)] weird : [1, 3 (empty), 4, 2] Let me know if my explanation isn't clear enough. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19906] New: Move template JavaScript to the footer: NORMARC editor plugins
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19906 Bug ID: 19906 Summary: Move template JavaScript to the footer: NORMARC editor plugins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 17858 NORMARC plugin templates already have JavaScript at the bottom of the template instead of the top, but they should still be modified to be consistent with other templates which have been updated as part of Bug 17858. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17858 [Bug 17858] Omnibus: Move staff client JavaScript to the footer -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 2696] Fine Payments Should Show What Was Paid For
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2696 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |BLOCKED --- Comment #33 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Can't wait to have this, but currently blocked by FAILED QA on bug 18790 - Kyle, can you put this in our queue again once the other is in? Thx! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20309] New: Machine generated 'Invoice or Receipt Number' against every fine receipt
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20309 Bug ID: 20309 Summary: Machine generated 'Invoice or Receipt Number' against every fine receipt Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: sujan.lib(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Now we can very easy to manage 'Fines and Fees' system in Koha ILS. But at present we could not able to set automatically machine generated 'Invoice or Receipt Number' against every fine receipt. It also require to count Total 'Amount' on the basis of total 'Quantity' for the money receipt in creation of 'manual invoice receipt' For Reprography services. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 13153] Waiting hold checked in at different library doesn't re-route item to correct library
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13153 --- Comment #19 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Thx for commenting - it's good. :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13153] Waiting hold checked in at different library doesn't re-route item to correct library
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13153 --- Comment #18 from Hugh Rundle <hughr(a)brimbank.vic.gov.au> --- Great, ok I'll wait a bit to see if Marc or Nick can shed any light and if they think further testing is needed we might be able to test at Brimbank. (In reply to Katrin Fischer from comment #17) > It looks like Christopher moved this into 'in Discussion' pointing out some > issues he found - moving to failed QA to get some feedback from the > developer. > > It could help if you could test the patch and confirm good/bad behaviour > looking at the test plans. > > I also notice the bug was not assigned, so might have slipped through the > saved searches. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13153] Waiting hold checked in at different library doesn't re-route item to correct library
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13153 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Status|In Discussion |Failed QA Assignee|koha-bugs(a)lists.koha-commun |nick(a)bywatersolutions.com |ity.org | --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- It looks like Christopher moved this into 'in Discussion' pointing out some issues he found - moving to failed QA to get some feedback from the developer. It could help if you could test the patch and confirm good/bad behaviour looking at the test plans. I also notice the bug was not assigned, so might have slipped through the saved searches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13153] Waiting hold checked in at different library doesn't re-route item to correct library
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '18

28 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13153 Hugh Rundle <hughr(a)brimbank.vic.gov.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hughr(a)brimbank.vic.gov.au --- Comment #16 from Hugh Rundle <hughr(a)brimbank.vic.gov.au> --- This bug has been listed since 2014 and a patch provided 12 months ago. It is a really big problem for multi-branch libraries and as others have noted, the workarounds are cumbersome. What needs to happen to close this off? I note the issue raised by Christopher but it seems unclear whether this is caused by the patch or is simply revealing a different bug. My own preference would be to note it as a separate bug and push this patch, which will do the job in most scenarios. Not getting the right info in a popup telling staff who the hold is for is a minor problem compared to not getting any indication at all that an item has an allocated hold on it and needs to be transferred. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0