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

[Bug 42073] New: Authorities editor missing marcdocs links
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42073 Bug ID: 42073 Summary: Authorities editor missing marcdocs links 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the bibliographic editor, you can see "[?]" links next to the MARC field number. We should have these for the authorities editor too, especially since authorities are generally understood less well than bibliographic records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42081] New: Inclusion of Brazilian address format
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42081 Bug ID: 42081 Summary: Inclusion of Brazilian address format Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: amanda(a)koalan.com.br QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Is there a possibility of including the Brazilian address format in future updates? (In Brazil, we have several institutions that use Koha, and the Federal Technology Department is a major promoter of Koha for Libraries). Currently, Koha supports other formats from other countries, but not yet the Brazilian one. We use the following format: [Street/Avenue/etc.]: [Street Name], [House Number], Neighbourhood, City, State, Postcode. Example: Rua Rui Barbosa, 1534, Centro, Prudentópolis, Paraná, CEP. Thank you! Translated with DeepL.com (free version) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41591] XSS vulnerability via file upload function for invoices
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41591 Eric Phetteplace <ephetteplace(a)cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42080 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42061] New: Username not logged when using external authentication method
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42061 Bug ID: 42061 Summary: Username not logged when using external authentication method Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 195100 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195100&action=e… Logs screenshot We use CAS authentication and today I noticed in our Authentication logs that the userid (username) field is empty in both success and failure messages for the OPAC and staff side. To recreate: - Use CAS authentication e.g. casAuthentication and casServerUrl settings - Turn on AuthSuccessLog and AuthFailureLog settings - Sign in to the staff and OPAC side - Go to the Log Viewer Expected: Authentication log message "Valid password for USERNAME". Actual: Authentication log message "Valid password for". Looking at the auth code, I believe this is an issue no matter what external authentication is used, whether it's Shibboleth, LDAP, or CAS. The @return array is populated with $retuserid for these services (Auth.pm lines 2020-2069) but the logaction calls use $userid which is undefined. Adding $userid = $retuserid after receiving a return value fixes the SuccessLog but the checkpw_* methods do not return a username when they fail, only 0, so the FailureLog would continue to have this problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42075] New: Transforming booking to checkout may fail with false clash detection and return 500 error
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42075 Bug ID: 42075 Summary: Transforming booking to checkout may fail with false clash detection and return 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk When attempting to check out an item associated with an active booking (either via normal checkout or using "Transform to checkout"), Koha may throw a Koha::Exceptions::Booking::Clash and return a 500 error even when the booking dates and item assignment are valid. This appears to occur during the booking store() logic where both item-level and biblio-level check_booking() validations are executed. In some cases the biblio-level booking check incorrectly reports no available bookable items even though the booked item itself is valid, causing checkout to fail. The expected behavior is that a booking transitioning to checkout should complete successfully without triggering a clash when the assigned item and booking dates are valid. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41820] New: StaffSearchResultsDisplayBranch system preference should have option to display both locations
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41820 Bug ID: 41820 Summary: StaffSearchResultsDisplayBranch system preference should have option to display both locations Initiative type: --- Sponsorship --- status: 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: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Add a “both” option to the StaffSearchResultsDisplayBranch system preference to allow staff search results to display both an item’s home and current locations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 41734] New: Need way to clear mandatory patron attributes once patron is no longer in a category using that attribute
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41734 Bug ID: 41734 Summary: Need way to clear mandatory patron attributes once patron is no longer in a category using that attribute Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Scenario: library uses a reciprocal borrowing patron category and wants to track what neighboring area patrons are coming from, attribute is limited to patron category and mandatory. Patron moves, updates membership to be no longer reciprocal. The attribute cannot be removed while the patron is in a category using it, and the option disappears from the edit form once their new category no longer uses that attribute, but the data is left behind. A workaround is to blank that out with the batch patron modification tool, but it would be nice if, when moving a patron out of a category with a mandatory attribute, Koha offered a prompt to remove the no-longer-applicable attribute data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26603] New: Add the ability to have Patron driven choice in what format they receive messages
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26603 Bug ID: 26603 Summary: Add the ability to have Patron driven choice in what format they receive messages Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, specifically to Overdues, it is up the library to decide how they send out their Overdue Notices- email, SMS, phone, print. It would be extremely helpful to libraries and patrons to have the patron choose which format they receive their message in - instead of the library sending it to all formats and for those patrons that have both SMS and email on file, they would only get this message in their desired format instead of both. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39924] New: Improve language search option in advanced search
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39924 Bug ID: 39924 Summary: Improve language search option in advanced search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The list of languages has grown significantly. It might be nice to use a select2 style drop down to make it easier to find the ones you are looking for. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 41468] New: Dont force show checkin column if user hid it previously
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41468 Bug ID: 41468 Summary: Dont force show checkin column if user hid it previously Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9