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

[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

[Bug 38873] New: Update MARC21 default framework to Update 39 (December 2024)
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38873 Bug ID: 38873 Summary: Update MARC21 default framework to Update 39 (December 2024) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org https://www.loc.gov/marc/bibliographic/bdapndxg.html UPDATE 39 CHANGES ■ New content designators: Subfields $0 Authority record control number or standard number (R) in 506 (Restrictions on Access Note) $0 Authority record control number or standard number (R) in 540 (Terms Governing Use and Reproduction Note) $1 Real World Object URI (R) in 506 (Restrictions on Access Note) $1 Real World Object URI (R) in 540 (Terms Governing Use and Reproduction Note) ■ Changes in content designator names and definitions: Fields $f Use and reproduction rights renamed Standardized terminology for use and reproduction rights in 540 (Terms Governing Use and Reproduction Note) ■ Fast-track changes: New subfields $3 Materials specified (NR) in 508 (Creation/Production Credits Note) $3 Materials specified (NR) in 511 (Participant or Performer Note) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 38760] New: koha-mysql doesn't work with encrypted database connection
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38760 Bug ID: 38760 Summary: koha-mysql doesn't work with encrypted database connection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: cornelius.amzar(a)bsz-bw.de, markus.john(a)bsz-bw.de, robin(a)catalyst.net.nz We noticed that the koha-mysql command doesn't send the right parameters when using an encrypted database connection. We are using the solution as outlined in bug 36026. If you add a warn to see the connection command as created by koha-mysql, you will see something like: mysql --host=<host> --user=XXX --password=XXX koha_XXX The parameters required for the encrypted connection (--ssl and --ssl-ca) are missing/unsupported. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 39543] New: Error modal when trying to add two controlling licences to an agreement duplicates error message
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39543 Bug ID: 39543 Summary: Error modal when trying to add two controlling licences to an agreement duplicates error message Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: andrew.auld(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Created attachment 180488 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180488&action=e… Screenshot of error modal If you try to add two licences with the status 'controlling' to an agreement record, the error modal duplicates the error message 'Only one controlling license is allowed'. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 39717] New: Stock rotation stages cannot be moved
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39717 Bug ID: 39717 Summary: Stock rotation stages cannot be moved 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 In the routine Koha::StockRotationStage->move_to we are doing a stringwise comparison of the position to move to, versus the count of stages This works when we have a limited number of stages, but fails when we have many: perl -e 'warn "Yes" if "3" le "26"' It's not. Changing to <= seems to fix this -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13