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

[Bug 24132] New: search_with_library_limits vs filter_by_branch_limitations
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '21

16 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24132 Bug ID: 24132 Summary: search_with_library_limits vs filter_by_branch_limitations 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 Depends on: 20443 Aside from the naming of these two subroutines (implemented at different times), Koha::Patron::Attribute::Types->search_with_library_limits and Koha::Patron::Attributes->filter_by_branch_limitations looks similar and that the code must be simplified. The join table is between borrower_attribute_types and branches (borrower_attribute_types_branches). So Koha::Patron::Attribute::Types can inherit directly from Koha::Objects::Limit::Library, not Koha::Patron::Attributes There are a couple of ways to deal with that: 1. Improve Koha::Objects::Limit::Library => Sounds wrong as there is no join table between borrower_attributes and branches 2. Remove Koha::Patron::Attributes->filter_by_branch_limitations and replace it by something like: my $attribute_types = Koha::Patron::Attribute::Types ->search_with_library_limits; my $attribute = $patron->extended_attributes ->search({ code => { -in => attribute_types->column('code') } }); Which sounds more correct. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20443 [Bug 20443] Move C4::Members::Attributes to Koha namespace -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 27509] New: cn_sort value is lost when editing an item without changing cn_source or itemcallnumber
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '21

16 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27509 Bug ID: 27509 Summary: cn_sort value is lost when editing an item without changing cn_source or itemcallnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is now null - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is back! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 27511] New: Don't use NOW() in saved sql last run update
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '21

16 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27511 Bug ID: 27511 Summary: Don't use NOW() in saved sql last run update Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When running a report, column last run is updated with current date-time. We should avoid using NOW(), better calculated date-time in perl. With NOW(), when importing a backup dump, you get current date-time in all rows. Also, sometimes we see errors in plack logs : DBD::mysql::db do failed: Lock wait timeout exceeded; try restarting transaction [for Statement "UPDATE saved_sql SET last_run = NOW() WHERE id = ?"] at /home /koha/src/C4/Reports/Guided.pm line 576. Replacing NOW() should avoid this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 25183] New: cleanup-database.pl --del-exp-selfreg fully deletes borrowers - should go into deleted-borrowers
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '21

16 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25183 Bug ID: 25183 Summary: cleanup-database.pl --del-exp-selfreg fully deletes borrowers - should go into deleted-borrowers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The cleanup database job for deleting expired self registrations fully deletes borrowers instead of transferring them to deleted borrowers. This is a problem when libraries think they are deleting email unverified patrons instead of ones that haven't moved out of the category, an easy thing to be confused about. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 27160] New: Fatal error when ReservesMaxPickUpDelay is empty and item with hold is checked in
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Bug ID: 27160 Summary: Fatal error when ReservesMaxPickUpDelay is empty and item with hold is checked in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you don't have any value in ReservesMaxPickUpDelay and you try to check in an item that has a hold, you will get an Internal Server Error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 25067] New: Move PO file manipulation code into gulp tasks
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25067 Bug ID: 25067 Summary: Move PO file manipulation code into gulp tasks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 101

[Bug 18195] New: Charge for expired holds per patron category
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18195 Bug ID: 18195 Summary: Charge for expired holds per patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ExpireReservesMaxPickUpDelayCharge allows one charge to be applied to all holds that expire. However, each patron category can have a unique hold fee. It would be preferable if each patron category could also have a unique 'hold expired' fee, so different patron categories could be charged different amounts (or not at all) for expired holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26523] New: In reserve/request.pl biblioitemnumber is used where biblionumber is required.
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26523 Bug ID: 26523 Summary: In reserve/request.pl biblioitemnumber is used where biblionumber is required. Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the fix of bug 24185, (commit 18ad5f5eea8aab8414783f4b75408cfebd2518da) bibliotemnumber is used where biblionumber is required. The consequence is that ItemsAnyAvailableAndNotRestricted is called on the wrong record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 27808] New: Item's onloan column remains unset if a checked out item is issued to another patron without being returned first
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '21

14 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27808 Bug ID: 27808 Summary: Item's onloan column remains unset if a checked out item is issued to another patron without being returned first Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If any item is currently checked out to a patron, and the item is then checked out directly to another patron without manually checking the item in first, the items.onloan column will remain NULL. This will only happen if the new checkout will be due the same day as the previous checked. This is caused by the item being returned without updating the item object from storage afterward. Even though AddIssue will call AddReturn which sets the value of onloan to NULL in the database, we are not passing in the item object by reference, so it's onloan value remains set to a date. Then we set the onloan value to the same date. Because the value does not change in the object, the column does not get marked dirty. We could update the object from storage first, but it seems more efficient to mark the column as dirty manually to avoid that otherwise unnecessary fetch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 27573] New: Use of NOW() in SQL should be avoided
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '21

14 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27573 Bug ID: 27573 Summary: Use of NOW() in SQL should be avoided Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org A few uses of the SQL NOW() function have crept in.. if we want to have consistent dates using the timezone set in the config then we need to handle date parsing before we hit the database as the DB timezone may differ from the instance timezone. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10