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

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 David Cook <dcook(a)prosentient.com.au> 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 42086] New: Maintain position of today's and previous sections in checkouts table
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42086 Bug ID: 42086 Summary: Maintain position of today's and previous sections in checkouts table Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 24533 allowed items to be sorted within the Today's checkouts and Previous checkouts groupings of the checkouts table. But depending on your sort, sometimes the Today's checkouts grouping is at the top and sometimes the Previous checkouts grouping is at the top, which is confusing. I suggest that the position be fixed, that the Today's checkouts section should always come above the Previous checkouts section when using a sort that maintains these groupings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42079] New: Remove blank entries in items diff
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42079 Bug ID: 42079 Summary: Remove blank entries in items diff Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Similar to the work done to remove items that were blank both before and after a change for bibs and patrons, we should do the same for items. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29393] New: Ability to send emails from patron details page
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '26

12 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 Bug ID: 29393 Summary: Ability to send emails from patron details page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 116

[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 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