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

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia(a)bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |martin.renvoize@ptfs-europe | |.com --- Comment #10 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Works as expected.. a look through the code doesn't highlight any issues regressions.. I'm tempted to PQA and push and let Jenkins do it's thing here rather than let it languish and require another rebase. As for the note.. I think we're safe with the signature.. the db column name mismatch isn't the first and should likely get cleaned up as a distinct issue upon more to Koha:: PQA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #98708|0 |1 is obsolete| | --- Comment #9 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 98710 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98710&action=ed… Bug 14711: Change prototype for AddReserve - pass a hashref The number of parameters of AddReserve makes it hard to read and maintain. This patch replace it with a hashref, which will make the calls more readable. Moreover the bibitems has been removed as it was not used by the subroutine. Test plan: - Make sure the tests pass - Read the diff and search for typos - Place a hold on few items Note for QA: reservation_date and expiration_date do not match the DB column's names, should we? Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7611] Show the NOT_LOAN authorised values for item status in XSLT OPAC search results
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7611 --- Comment #45 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #44) > Nick, could you confirm it will not break the display for UNIMARC and > NORMARC? NORMARC is no longer maintained according to Magnuse, so we cna ignore that UNIMARC is not affected by these changes - the status for notforloan items remains the same, only substatus is added. The CSS changes rely on classes that don't exist in the UNIMARC xslt I did file bug 24630 and attempt UNIMARC changes, but that should not block this patchset -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77940|0 |1 is obsolete| | --- Comment #8 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 98708 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98708&action=ed… Bug 14711: Change prototype for AddReserve - pass a hashref The number of parameters of AddReserve makes it hard to read and maintain. This patch replace it with a hashref, which will make the calls more readable. Moreover the bibitems has been removed as it was not used by the subroutine. Test plan: - Make sure the tests pass - Read the diff and search for typos - Place a hold on few items Note for QA: reservation_date and expiration_date do not match the DB column's names, should we? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14711] Make C4::Reserves::AddReserves take a hashref in parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14711 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6383] itemnumber not stored when a lost item is returned and credited to account
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6383 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- This will be resolved as a side effect of bug 24592. *** This bug has been marked as a duplicate of bug 24592 *** -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 24376] New: Wording of Fine Returned is confusing
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24376 Bug ID: 24376 Summary: Wording of Fine Returned is confusing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With 19.05 Koha Fines were given new descriptions. We moved away from F and FU fines to Fines Accruing and Fine Returned. However, libraries find that the Fine Returned confusing when the item has been renewed and / or lost. Example: If an item has been lost, the fine will stop accruing and therefore get the description of Fine Returned. However the item is not returned but the fine has, in essence, stop accruing. Or if an item has been overdue, then renewed. The first fine will have stopped accruing and be given a Fine Returned when really the item has been renewed and could potentially get more fines. Recommendations of the wording could be "Fine Final" instead of "Fine Returned" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 17483] New: Forgiving charge should apply to item's last fine.
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '20

11 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17483 Bug ID: 17483 Summary: Forgiving charge should apply to item's last fine. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When returning an item with a fine, if the Forgive checkbox is clicked, this forgives the first accountline associated to the item/user, not the current/latest as it should. Scenario (Real world): - A patron returns a book late, ensuring a 5$ fine. Does not pay it. - The patron borrows the book again 3 months later. Gets late again, and fined 2$. - Great timing: The library offers amnesty for a week. Bring back your book and we'll forget that they're late. - On checkin, the librarian clicks "Forgive overdue charges" and scan the book. - Koha cancels the 3-months-ago 5$ fine. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16