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

[Bug 39637] New: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39637 Bug ID: 39637 Summary: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Continuation of bug 31104 which did not solve the problem completely. Steps to reproduce: 1. Log in to staff interface 2. In the top search bar, select "Patrons search" and type "a b c d e f g h i j k l m" and submit the form 3. The patrons table should fail to load with a message like this: "Something went wrong when loading the table. 414: Request-URI Too Long.". If the table loads successfully, try adding a few more letters (separated by space) to the search. Another error that can happen is a 5XX error caused by the length of Link headers. Here is the (decoded) URL generated for "a b c d e": http://koha-dev-main/api/v1/patrons?_page=1&_per_page=20&q=[{"-and":[[{"me.firstname":{"like":"a%"}},{"me.preferred_name":{"like":"a%"}},{"me.middle_name":{"like":"a%"}},{"me.surname":{"like":"a%"}},{"me.othernames":{"like":"a%"}},{"me.cardnumber":{"like":"a%"}},{"me.userid":{"like":"a%"}}],[{"me.firstname":{"like":"b%"}},{"me.preferred_name":{"like":"b%"}},{"me.middle_name":{"like":"b%"}},{"me.surname":{"like":"b%"}},{"me.othernames":{"like":"b%"}},{"me.cardnumber":{"like":"b%"}},{"me.userid":{"like":"b%"}}],[{"me.firstname":{"like":"c%"}},{"me.preferred_name":{"like":"c%"}},{"me.middle_name":{"like":"c%"}},{"me.surname":{"like":"c%"}},{"me.othernames":{"like":"c%"}},{"me.cardnumber":{"like":"c%"}},{"me.userid":{"like":"c%"}}],[{"me.firstname":{"like":"d%"}},{"me.preferred_name":{"like":"d%"}},{"me.middle_name":{"like":"d%"}},{"me.surname":{"like":"d%"}},{"me.othernames":{"like":"d%"}},{"me.cardnumber":{"like":"d%"}},{"me.userid":{"like":"d%"}}],[{"me.firstname":{"like":"e%"}},{"me.preferred_name":{"like":"e%"}},{"me.middle_name":{"like":"e%"}},{"me.surname":{"like":"e%"}},{"me.othernames":{"like":"e%"}},{"me.cardnumber":{"like":"e%"}},{"me.userid":{"like":"e%"}}]]},{"-or":[{"me.firstname":{"like":"a+b+c+d+e%"}},{"me.preferred_name":{"like":"a+b+c+d+e%"}},{"me.middle_name":{"like":"a+b+c+d+e%"}},{"me.surname":{"like":"a+b+c+d+e%"}},{"me.othernames":{"like":"a+b+c+d+e%"}},{"me.cardnumber":{"like":"a+b+c+d+e%"}},{"me.userid":{"like":"a+b+c+d+e%"}}]},{"-and":[[{"extended_attributes.value":{"like":"a%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"b%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"c%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"d%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"e%"},"extended_attributes.code":[["Nickname","PAT_1"]]}]]}]&_match=contains&_order_by=+me.surname,+me.preferred_name,+me.firstname,+me.middle_name,+me.othernames,+me.street_number,+me.address,+me.address2,+me.city,+me.state,+me.postal_code,+me.country (Ignore the extended_attributes.* params that are not the main issue here, even though they contribute to the problem) If I'm counting correctly, for each word searched, the URL length is increased by (216 + 7 * <word length>) characters (before encoding, which also increases the URI length by a lot). For me, with Apache, the problem happens around 8k characters (after encoding). IMO it would be better to send only parameters like 'search', 'search_type' and 'search_field' to the API and translate this to DBIC dialect on the backend. This would make it a lot harder to reach the limit (and would make the URI far more readable, which is always nice :)) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 17387] New: Add an undelete feature for items/biblios
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17387 Bug ID: 17387 Summary: Add an undelete feature for items/biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to be able to restore items accidentally deleted. This should be possible, rows can be copied over as long as there are checks in place for unique ids. -- You are receiving this mail because: You are watching all bug changes.

1 274

[Bug 38953] New: borrower_message_preferences.borrowernumber should not be DEFAULT NULL
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38953 Bug ID: 38953 Summary: borrower_message_preferences.borrowernumber should not be DEFAULT NULL Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org borrowernumber in borrower_message_preferences is DEFAULT NULL in kohastructure.sql, despite ON DELETE CASCADE in the foreign key. Also borrower message preferences without a borrowernumber don't make any sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30515] New: Move Overdue transports to patron messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30515 Bug ID: 30515 Summary: Move Overdue transports to patron messaging preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The idea of this bug would be to allow patrons to choose which format they would like to receive their overdues in while maintaining at least one selection as mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 110

[Bug 26129] New: Add a new 'configurations' table
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 Bug ID: 26129 Summary: Add a new 'configurations' table 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This table should be designed from the beginning to allow global and per-library configuration entries. It would replicate the circulation_rules schema, but adapted to be a(n eventual) replacement for system preferences. This came up on my development for an SMTP configuration page, in which I originally added an smtp_servers page, that could really be generalized like this for other uses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 95

[Bug 32196] New: One should be able to remove a borrower relationship whenever one exists
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32196 Bug ID: 32196 Summary: One should be able to remove a borrower relationship whenever one exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 12446 Per bug 32195, there is still at least one way for a patron to end up with a guarantor in a category that does not allow guarantors. When that happens, the patron edit screen does not show one the relationship and therefore the relationship cannot be removed. One should *always* be able to remove an existing relationship. To recreate: 1: have a patron category where CanBeGuarantee is set to Yes. 2: Create a patron in that category, give them a guarantor 3: edit the patron category to set CanBeGuarantee to No 4: confirm your patron still has a guarantor that shows on the details page, but the guarantor no longer shows on the edit screen 5: this means the guarantor cannot be removed :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 [Bug 12446] Enable an adult to have a guarantor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31681] New: Daily digest notice for ALL notices
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31681 Bug ID: 31681 Summary: Daily digest notice for ALL notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org What if a patron had the option to have a SINGLE notice per day, that was a digest of all notices to them? So, if they have this option checked, they would get a notice at the end of the day, or beginning, that would contain any hold, overdue, predue, etc notices. So, if this is checked, instead of queuing up for the regular cron, maybe the notice is sent in a new cron that is once a day. If done, it might also be beneficial to note on the parton's notifications how the notification was queued (right away/daily). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40478] New: Add option to center barcode on labels
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40478 Bug ID: 40478 Summary: Add option to center barcode on labels Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 40473 fixes barcode length calculator of Code39 barcodes in the label creator. When using barcode width of 1 or 100%, the barcode will be centred on the label. But if you use a smaller barcode width, your barcode will be left aligned. Surely it would be good to have the ability to have centred barcodes even when using narrower barcodes? -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 33374] New: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33374 Bug ID: 33374 Summary: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Have a multibranch system where holds can transfer between 2 or more libraries 2. Have a bib with 2 or more items at different branches. 3. At Branch A checkout Branch A's copy of the item to a patron 4. At Branch B place a record level hold for a Branch B patron (where branch b has a copy of the item available on the shelf) 5. Return Branch A's book at Branch A. It fills the hold for Branch B patron In some cases this makes the patron wait much longer for a hold. It would be great if there was a way to set holds not to fill from other libraries if there was a copy available at the pickup location. Some consortiums have branches that only get deliveries once or twice a week. If they happen to check in an item that could be filled at the pickup branch before the pickup branch scans the hold there, it could take much longer for the patron to get the item. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39164] New: Add max_statement_time to SQL report quieries
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39164 Bug ID: 39164 Summary: Add max_statement_time to SQL report quieries Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: koha(a)trust-box.at Sometimes an unlucky report can create an issue for the DB server. To avoid that an easy to achieve fix would be to add a configurable timeout via max_statement_time to the query. This way the query would abort automatically if going over the time limit. See: https://mariadb.com/kb/en/aborting-statements/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54