May 2025 - Koha-bugs - lists.koha-community.org

[Bug 32019] New: Add option to mark items returned in batch modification
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '25

12 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32019 Bug ID: 32019 Summary: Add option to mark items returned in batch modification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 31746] New: Patron record saves when cardnumber required and value entered is whitespace
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '25

12 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31746 Bug ID: 31746 Summary: Patron record saves when cardnumber required and value entered is whitespace Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This happens both with the full patron entry form and the quick add form. When the cardnumber is required, it's possible to enter either spaces or non-printing characters into the cardnumber field and save the record. That is, there's nothing but whitespace. The value of cardnumber saved in the database in this case is NULL. It would be helpful if Koha verified that the cardnumber field contained something other than whitespace and prevented it from saving if it did not, when the cardnumber is required. I'm not sure if this relates to bug 30978 in any way, but I'm referencing it here just in case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 37138] New: If "protected" is in BorrowerUnwantedField, it still shows when adding a patron
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '25

11 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37138 Bug ID: 37138 Summary: If "protected" is in BorrowerUnwantedField, it still shows when adding a patron Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 35474 introduced a Y/N toggle to indicate that a patron is protected. While this is an option in the BorrowerUnwantedField system preference, Koha doesn't obey it. Even if Protected is selected, it still shows when adding or editing a patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 36825] New: Cannot hide "Protected" field via BorrowerUnwantedField syspref
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '25

11 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36825 Bug ID: 36825 Summary: Cannot hide "Protected" field via BorrowerUnwantedField syspref Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Setting field "Protected" as hidden in patron entry/modification form via BorrowerUnwantedField syspref doesn't work. Form is missing condition "UNLESS noprotected" To reproduce: 1. From BorrowerUnwantedField, check field "Protected" as hidden. 2. Either attempt to create a new patron or edit existing one. => Note that "Protected" is still displayed in the form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 38458] New: Add more fields to patron matching options during import
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '25

11 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38458 Bug ID: 38458 Summary: Add more fields to patron matching options during import Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Current import tool only allows username or cardnumber or unique patron attributes. When checking for duplicate patrons we can select a combination of fields to search on in the PatronDuplicateMatchingAddFields It would be nice to have an option to define a custom matching rule based on one or more columns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35224] New: AllowRenewalIfOtherItemsAvailable description is misleading
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '25

11 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35224 Bug ID: 35224 Summary: AllowRenewalIfOtherItemsAvailable description is misleading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At the moment the AllowRenewalIfOtherItemsAvailable syspref description is "Allow a patron to renew an item with unfilled holds if other available items can fill that hold." Nothing indicates that there should be more available items than holds. Either the description should be fixed or allow renew if holds exceeds available items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32731] New: Option for cataloguing tools to also be shown in Tools Home
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '25

11 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32731 Bug ID: 32731 Summary: Option for cataloguing tools to also be shown in Tools Home Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org While the new staff interface design is beautiful, big enhancements like the shift of cataloguing tools out of Tools Home requires process changes and training, which takes time. It would be good to be able to enable those tools to show in Tools Home again to ease the transition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 36029] New: Add the ability to backdate a transaction in POS
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '25

10 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36029 Bug ID: 36029 Summary: Add the ability to backdate a transaction in POS 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: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org We've been using the POS (Point of sale) feature since August 2023. During that time we have encountered some issues that we believe could be solved by adding the ability to backdate a POS transaction. Here is our use case: Sometimes staff forget to enter the sale in POS. This usually happens for credit card sales when the staff member does the credit card transaction, the patron signs, a receipt is given and then the staff member is interrupted by someone/something else causing the sale to never be entered into Koha. We have a large number of funds because our library takes care of not only fees for copies, ILLs, faxes, etc. but also Friends & Foundation sales for earbuds, flash drives, tote bags, book sales, pumpkins, event tickets, to name a few. Each of these sales goes to a different account per our City Finance dept. Staff will sometimes select the wrong debit code which is especially bad when the funds collected should have gone to a different entity, such as the Friends. The Finance dept. wants an exact recording of sales on the day they happened. However, these issues are often not detected until staff reconciles the drawer each morning. At that time they have to enter the missed/incorrect sales into the POS. That can cause issues with reporting since these transactions are now being entered on the wrong date. Being able to enter a transaction and backdate it would help solve this problem for the library, keep our Finance staff happy and make our reports accurate. I think this would need to be covered by a permission since we would only want certain staff to be able to do this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 20555] New: usage() function in cleanup_database.pl needs refactoring
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '25

10 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20555 Bug ID: 20555 Summary: usage() function in cleanup_database.pl needs refactoring Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 1) '-m --mail DAYS' is misleading -- this cleans up the message queue, which covers a lot more than mail. 2) usage() should be implemented using pod2usage -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36497] New: Cancel unfilled holds should be a system preference
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '25

10 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36497 Bug ID: 36497 Summary: Cancel unfilled holds should be a system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com While libraries can run cancel_unfilled_holds with various parameters, nowhere in the staff client suggests that option, nor is it in cron jobs in the manual. It should be a system preference a la ExpireReservesMaxPickUpDelay, with a "Cancel/Don't cancel" option for unfilled holds and a second preference for days, followed by verbiage indicating that this requires running cancel_unfillled_holds.pl. This would let library staff know both that the cancellation of old holds is possible as well as give them some basic configuration from the staff client. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4