March 2026 - Koha-bugs - lists.koha-community.org

[Bug 18002] New: Add functionality to create a vendor and budget in the onboarding tool
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18002 Bug ID: 18002 Summary: Add functionality to create a vendor and budget in the onboarding tool Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 17855 Add two additional interfaces to the onboarding tool to allow the user to create a vendor and budget before logging into Koha for the first time, thereby allowing users to get acquisition requirements set up. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17855 [Bug 17855] Updated Koha web installer and new onboarding tool feature to guide users through setting up Koha -- You are receiving this mail because: You are watching all bug changes.

1 97

[Bug 36789] New: Transform a booking into checkout
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36789 Bug ID: 36789 Summary: Transform a booking into checkout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello, Linked to the booking feeture you can now transform a booking into a checkout directly from the booking list view. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 86

[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 41133] New: Suggestions table sharing localStorage for all tabs can prevent records from loading
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41133 Bug ID: 41133 Summary: Suggestions table sharing localStorage for all tabs can prevent records from loading Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org On suggestion.pl the local storage DataTables_acqui_suggestions_suggestions which saves the state for pagination is shared for all tabs, which can cause tabs to load with a bad state and fail to load records. To recreate: 1. Use ktd --dbshell to add a bunch of random suggestions with different statuses: INSERT INTO suggestions (suggestedby, suggesteddate, title, status) SELECT borrowernumber, '2025-10-29', firstname, ELT(0.5 + RAND() *6, 'ASKED', 'CHECKED', 'ACCEPTED', 'REJECTED', 'ORDERED', 'AVAILABLE' ) from borrowers; 2. If you are lucky you will have one tab with more than 20 records and one with less than 20, if not use the ui to adjust the statuses so that you do 3. Click on a tab with more than 20 records 4. Click Next > to go to the second page 5. Notice in local storage now DataTables_acqui_suggestions_suggestions.start is now 20 6. Click on a tab with fewer than 20 records 7. Notice the table says something illogical like: Showing 21 to 11 of 11 entries 8. And no records load :( 9. Click <<First to fix the pagination issue 10. Notice DataTables_acqui_suggestions_suggestions.start is now 0 again 11. The table loads with records :) Showing 1 to 11 of 11 entries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41049] New: Add additional deleting capabilities to the cataloging macros
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41049 Bug ID: 41049 Summary: Add additional deleting capabilities to the cataloging macros Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to have syntax added to the Advanced Editor's cataloging macros for the following: 1) ability to delete fields based on indicator 2) ability to delete subfields on all instances of a field, not just the first instance of the subfield / first instance of the field. A use case scenario would be importing records from Z39.50 sources and using a macro to strip fields/subfields that are always unwanted. Deleting fields based on indicator would allow one to strip subjects from unwanted thesauri, for example 650 _1... for a juvenile SH or 650 _2 for MESH. Deleting subfields on all instances would allow one to strip coded and linking subfields from authorized heading fields. Sometimes the same subfield repeats in the same instance of the field (for example, multiple $4's in a 100 field), and sometimes a field number has multiple instances (for example, multiple 650 fields, all with $0 linking subfields). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 42172] New: With OPACAuthorIdentifiersAndInformation show whole heading, not only $a
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42172 Bug ID: 42172 Summary: With OPACAuthorIdentifiersAndInformation show whole heading, not only $a Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org With the OPACAuthorIdentifiersAndInformation option enabled, selected information about authors is displayed, provided it present in the author's authority record. However, the author's name is limited to subfield $a, which is insufficient--especially in the case of corporate names containing a subordinate unit in $b or in the case of meeting names. -- You are receiving this mail because: You are watching all bug changes.

1 15