December 2025 - Koha-bugs - lists.koha-community.org

[Bug 35885] New: ERM vendor sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35885 Bug ID: 35885 Summary: ERM vendor sort order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: Laura.escamilla(a)bywatersolutions.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Currently the vendor drop-down list shows the vendors in the order that they were added to the Acquisitions module. It would be ideal if the vendors were sorted in alphabetical order so that libraries could easily locate their selection. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 33224] New: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33224 Bug ID: 33224 Summary: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is the situation: The library wants to prevent on-shelf holds as much as possible, only allowing for transfers if the copy at the patron's library is not available. For example, a record with a checked out copy at Centerville and an available copy at Midway. A Centerville patron should be able to place a hold for pickup at Centerville (the hold will appear on Midway's holds to pull for transfer to Centerville). A Midway patron should not be able to place a hold for pickup at Midway since the Midway copy is available. Does that make sense? This is the setting: - circulation rules allow on-shelf holds only if any unavailable - OPACHoldsIfAvailableAtPickup is set to Don't allow Currently, this allows the Midway patron to place a hold for pickup at Midway. To test: 1. Set up the circulation rule so that on-shelf holds are allowed ('Yes') 2. Create a record with two items, one at Centerville and one at Midway 3. Check out the Centerville item 4. Log into the OPAC with a Midway patron (I used Henry Acevedo) 5. Try to place a hold on the record --> Midway is not a valid pickup location (correct behaviour) 6. Cancel 7. Change the circulation rules so that on-shelf holds are only allowed 'if any unavailable' 8. Try to place a hold on the record from the OPAC again --> The system allows you to place the hold for pickup at Midway (incorrect behaviour) 9. Optionally, check the Holds to pull for Midway (the hold is there, it shouldn't) 10. Optionnaly, check in the Midway item (it is trapped for Henry's hold) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 38095] New: Custom patron messages should have access to information about the logged-in library they were sent from
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38095 Bug ID: 38095 Summary: Custom patron messages should have access to information about the logged-in library they were sent from Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 29393 Bug 29393 added the ability to define custom notices that could be sent from the patron account page. It would be useful if these notices had access to information about the logged-in library from which the notice was triggered. For example, we'd like to use this feature to add an email template for notifying a patron that a lost library card was found and turned in to the library. That notice should include which branch found the card and triggered the notice, which may not be the patron's home library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 39303] New: Add audience index to SRU
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39303 Bug ID: 39303 Summary: Add audience index to SRU Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 39379] New: The "Edit" button appears in patron search results even when you cannot edit the patron
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39379 Bug ID: 39379 Summary: The "Edit" button appears in patron search results even when you cannot edit the patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This isn't a huge deal, but I notice that the "Edit" button appears in /cgi-bin/koha/members/members-home.pl even when you don't have edit borrower permissions. This should be an easy fix. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39035] New: CookieConsentBar message prints on slip when cookies aren’t accepted
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39035 Bug ID: 39035 Summary: CookieConsentBar message prints on slip when cookies aren’t accepted Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marie-luce.laflamme(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hey everyone, I ran into a small issue with the CookieConsent system in Koha. If you forget to accept Koha’s consent cookies on a computer, the CookieConsentBar message shows up on every printed slip from that computer. The behaviour affect 24.05+ and main. Steps to reproduce: Before testing, make sure: - set the CookieConsent system preference to enable - set a CookieConsentBar message (configured in HTML personnalisations > Additional content > CookieConsentBar) Test plan: 1. Open a different web browser that hasn’t accepted Koha’s cookies yet. 2. Log into the staff interface (do not accept cookies yet). 3. Find a patron account. 4. Click on "Print" and choose any slip. 5. Check the printed slip. ---> Koha is printing the CookieConsentBar message at the bottom, which shouldn’t be there. 6. Now, accept the cookies at the bottom of the screen. 7. Print another slip. 8. Check the new slip. ---> This time, the CookieConsentBar message is gone (as expected). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 39209] New: Cookie consent banner should be 'focused' on load
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39209 Bug ID: 39209 Summary: Cookie consent banner should be 'focused' on load Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We've had an accessibility audit highlight that the cookie consent banner is 'in a strange order' for keyboard navigation. > Issue > • The cookie banner current sits in a slightly odd place in the focus order, > coming after the ‘Advanced Search’ link > • This might be somewhat disorientating for screen reader users. It may also > be frustrating for sighted keyboard users who would like want to dismiss this > prior to exploring the page > > Solution > • Review the order of focus (by tabbing through the page) to ensure the > journey users take through the page and within elements is the most logical > and efficient, and matches the visible order of content > • Move the cookie banner so it can be dismissed as the first action on the > page > • NB – avoid using positive tabindex values to artificially modify the focus > order I've researched this a little and there's evidence that moving the banner to the top is detrimental to engagement. Other research suggests that as soon as a cookie banner appears, it should take the initial keyboard focus. I propose we take the later approach and if the cookie consent banner is present on the page it should take the first focus point until dismissed at which point the focus should be reset. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37832] New: Rentaldiscount is not required to be decimal like other similar fields in smart-rules.tt
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37832 Bug ID: 37832 Summary: Rentaldiscount is not required to be decimal like other similar fields in smart-rules.tt Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 39076] New: Elasticsearch timeouts when committing import batches
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39076 Bug ID: 39076 Summary: Elasticsearch timeouts when committing import batches Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have seen in production that the ES server can get overwhelmed and start issuing timeouts during imports. The timeout errors often come from authorities linking during the bib import process -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 38313] New: RESTOAuth2ClientCredentials pref description is confusing
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38313 Bug ID: 38313 Summary: RESTOAuth2ClientCredentials pref description is confusing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Bug 20734, we added a string informing sysadmins that Net::OAuth2::AuthorizationServer is required for the RESTOAuth2ClientCredentials syspref to be operable. I don't think we need this anymore, as for git installs this is in the cpanfile, and for package installs this is included as a dependency for koha-perldeps. Could we remove this string to a) tidy things up, and b) avoid confusion of people installing the cpan module twice (once in Debian, and once in cpan-land)? Jake. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18