- 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 10941] MARC21 documentation links while adding an authority
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10941 Phil Ringnalda <phil(a)chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #8 from Phil Ringnalda <phil(a)chetcolibrary.org> --- *** Bug 42073 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 40934] New: process_message_queue.pl add ability to exclude some letter code
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40934 Bug ID: 40934 Summary: process_message_queue.pl add ability to exclude some letter code Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would help to add an argument to process_message_queue.pl to exclude some letter-code (like a blacklist, send all letter-code except these ones) Use case : Some library would like to send digest once per day (say at 20:05) but all others message every hour. It is currently possible to do that by having 2 lines process_message_queue.pl that way : ``` 00 */1 * * * process_message_queue.pl --code ACQ_NOTIF_ON_RECEIV --code CART ... # list all message except digest 05 20 * * * process_message_queue.pl #send all message including digest ``` The problem with this method is that we have to list almost all letter-code in the first line (around 85), there is a high chance that we forget some notification in the every hour line (thus these notifications will not be sent every hour as wanted) It would be great to be able to do it by excluding some letter code example: ``` 00 */1 * * * process_message_queue.pl --xcode DUEDGST --xcode PREDUEDGST --xcode HOLDDGST --xcode AUTO_RENEWALS_DGST # send all exepct digest 05 20 * * * process_message_queue.pl # send all including digest ``` (In this example, argument is xcode for exclude code but I'm not sure about the name) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 41514] New: The API should fully respect lead and trail periods for bookings
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Bug ID: 41514 Summary: The API should fully respect lead and trail periods for bookings 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 37707 Currently, the lead/trail period handling for bookings is entirely handled in the UI. We should add handling to the API to ensure these settings are adhered to by third-party consumers too. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 [Bug 37707] Lead/Trail times should work in combination -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[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