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

[Bug 35203] New: Koha::Biblio->get_coins support 214 field in addition to 210 (pubyear and publisher values)
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35203 Bug ID: 35203 Summary: Koha::Biblio->get_coins support 214 field in addition to 210 (pubyear and publisher values) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello, The publisher info and publication date for the <span Z3988> tag (corners) are based on the 210 but more and more records are now based on 214. Hence a loss of information. NB This is also the case for BIBTEXT and RIS formats. I will therefore propose a patch to add the new 214 field to the get->coins() method. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42926] New: Return passwordmustchange flag when patron password is expired
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42926 Bug ID: 42926 Summary: Return passwordmustchange flag when patron password is expired Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- Hello, When a patron's password is expired (whether due to ForcePasswordResetWhenSetByStaff or natural expiration), the REST API can returns a structured 403 response with a `passwordmustchange` boolean flag. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 20859] New: SMS and other notification preferences during self registration
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20859 Bug ID: 20859 Summary: SMS and other notification preferences during self registration Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Some libraries would prefer the option for patrons to choose their notification preferences and setup their SMS information during registration. -- You are receiving this mail because: You are watching all bug changes.

1 37

[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 41860] New: With zebra, authority search plugin gives no result in some cases
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41860 Bug ID: 41860 Summary: With zebra, authority search plugin gives no result in some cases Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41859 When using Zebra, authority search plugin gives no result when the search term was was auto completed and it contains subdivisions and the search is performed with 'Search all headings' or 'Search entire record'. To reproduce: 1. Have SearchEngine set to Zebra. 2. When cataloging, go to field 650 and use the authority plugin. 3. In 'Search all headings:' or 'Search entire record:' start typing 'Computer software' and choose any hint (with subdivision). Note that the operator has changed to 'is exactly'. Perform the search. You should get no results, despite of the existence of the record. You only get the results after changing the operator to 'contains'. This is because of the construction of Match and Any indexes in Zebra. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41859 [Bug 41859] Authority search autocomplete results not consistent with search results -- You are receiving this mail because: You are watching all bug changes.

1 11

[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 41250] New: Horizontal scrollbar in Koha home page
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41250 Bug ID: 41250 Summary: Horizontal scrollbar in Koha home page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com reset to commit prior to 35402: git reset --hard f44d2cccc75c614ec6f030c465d9f1d8800317d5 run reset_all, check Koha home at /cgi-bin/koha/mainpage.pl = no horizontal scrollbar reset to commit at 35402: git reset --hard d321dc6934d960ff38b2dbeed10c65cb04d485e9 run reset_all, check Koha home at /cgi-bin/koha/mainpage.pl = notice horizontal scrollbar at the bottom of the page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42625] New: Allow records to be locked for editing based on library & group
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42625 Bug ID: 42625 Summary: Allow records to be locked for editing based on library & group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Bug 31791 established record locking based on record source. We'd like to extend that to allow records to be locked for some users based on library and library group. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2