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

[Bug 42602] New: Patron search performance is poor if there are many patrons
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '26

18 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42602 Bug ID: 42602 Summary: Patron search performance is poor if there are many patrons 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: pedro.amorim(a)openfifth.co.uk 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 11

[Bug 42584] New: Allow extra elements on staff top navigation bar
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42584 Bug ID: 42584 Summary: Allow extra elements on staff top navigation bar Initiative type: --- Sponsorship --- status: 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Adding elements via new location StaffMastHeadExtraContent in html customizationf of additional contents. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 40290] New: a german string in a source file
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40290 Bug ID: 40290 Summary: a german string in a source file Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: e.betemps(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Hi, translating strings on Weblate, I found a sentence in german here is the link on Weblate : https://translate.koha-community.org/translate/koha-manual/valuebuilder/fr/… the file is : https://gitlab.com/koha-community/koha-manual/-/blob/main/source/images.rst… here is what il looks like (in the file) : .. |image1518| image:: images/cataloging/cn_browser_value_builder.png :alt: Signaturenbrowser in Unterfeld o von Feld 952 anschließen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41750] New: ForcePasswordResetWhenSetByStaff prohibits login via CAS
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41750 Bug ID: 41750 Summary: ForcePasswordResetWhenSetByStaff prohibits login via CAS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When ForcePasswordResetWhenSetByStaff is set to "enforce" and staff adds creates a new patron account, login by CAS is impossible. It took us a while to figure this out, since it just "won't work" without any helpful error message. I think there are different ways this could be handled. We could not check the password expiration date if a user authenticates through another external system (LDAP, CAS, OAuth2), since they cannot change the password then. The smallest solution might be warning on the pref, to not enable this for patron categories that use external authentication. I think in general it would be nicer to allow external authentication and still enforce if local login is used - there might be cases where both are the same patron category now and this would keep things more flexible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23054] New: Unable to change priority after reverting hold waiting status
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Bug ID: 23054 Summary: Unable to change priority after reverting hold waiting status Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- To Test: - Place a hold for Patron A - Place a hold on same item for Patron B - Check item in, triggering Patron A's hold - Revert waiting status on hold - Confirm holds list shows Patron A at priority 1, Patron B at priority 2 - Use arrow buttons to move Patron B to priority 1 - Query reserves table to confirm Patron B at priority 1, Patron A at priority 2 - Check item in - Patron A's hold triggers, even though Patron B was first in priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42634] New: Self-checkout Finish/logout does not reliably clear the JWT cookie
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42634 Bug ID: 42634 Summary: Self-checkout Finish/logout does not reliably clear the JWT cookie Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org On the web-based self-checkout (opac/sco/sco-main.pl), clicking the Finish/close button on the kiosk does not reliably end the patron session. The JS redirects the browser to ?op=logout, but the server-side response does not actually delete the JWT cookie - it emits an empty value with no Expires attribute, so the browser keeps a session-scoped empty cookie (or, in some intermediary/cache scenarios, retains the previous valid JWT). The patron remains logged in until the cookie genuinely expires, which presents as the Finish button "doing nothing" or working only intermittently. In opac/sco/sco-main.pl the Set-Cookie for JWT on logout is built as: -value => \$jwt // '', -expires => \$jwt ? '+1d' : '', Empty -expires produces a session cookie with an empty value rather than a deletion. The standard pattern for clearing a cookie is a past Expires, e.g. '-1d'. Test plan: 1. Enable web-based self-checkout (SelfCheckoutByLogin or IP-range). 2. Log in as a patron at /cgi-bin/koha/sco/sco-main.pl. 3. Open browser DevTools -> Application -> Cookies. Note the JWT cookie value. 4. Click the green "Finish" button. 5. Without the patch: observe Set-Cookie: JWT= on the ?op=logout response with no Expires; the JWT cookie may persist or be replaced with an empty session cookie that some browsers/proxies handle inconsistently. 6. Apply the patch and reload. Click Finish again. 7. Confirm Set-Cookie: JWT=; expires=<past>; ... is sent and the JWT cookie is removed from the browser entirely. 8. Confirm the kiosk reliably returns to the login screen and the next page load does not re-authenticate from a stale JWT. Sponsored-by: OpenFifth (Ticket #246176, John Innes Centre) -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 41706] New: "Use of uninitialized value..." warning in C4/Record.pm
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41706 Bug ID: 41706 Summary: "Use of uninitialized value..." warning in C4/Record.pm Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Use of uninitialized value $2 in split at /kohadevbox/koha/C4/Record.pm line 924. appears in the plack-opac-error.log file. To reproduce in KTD: 1. Observe plack-opac-error.log 2. In OPAC go to record with one word author like Aristophanes, Aristotle or Xenophon (biblionumbers: 64, 176, 254) 3. Show it in any of "detail" view (Normal, MARC, ISBD) 4. Warning appears in plack-opac-error.log It happens during the preparation of data for the "Cite" feature in OPAC. The warning appears because of the overlap of two regular expression matches - the variable captured from the first regular expression match is changed (by the second regular expression match) before it is used. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 41648] New: KitchenSink plugin breaks the plugins home page
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41648 Bug ID: 41648 Summary: KitchenSink plugin breaks the plugins home page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Install the KitchenSink plugin and you get: Template process failed: undef error - The given date (20-12-20) does not match the date format (iso) at /kohadevbox/koha/Koha/DateUtils.pm line 192. on /cgi-bin/koha/plugins/plugins-home.pl Because Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm: date_updated => "1900-01-01", -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 41197] New: opac/opac-account-pay-return.pl should not require CSRF
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41197 Bug ID: 41197 Summary: opac/opac-account-pay-return.pl should not require CSRF Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This page is intended for redirect/return from external payment vendors - they are not going to have/get a CSRF token from Koha for this. The payments are handled in a POST to the API, so this should not be a sensitive page, it just provides user confirmation. Some vendors use only a POST, we should not require CSRF on this page. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 40294] New: Mandatory patron expiration notice is not sent if patron does not have a primary contact method defined
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40294 Bug ID: 40294 Summary: Mandatory patron expiration notice is not sent if patron does not have a primary contact method defined Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 30301 Bug 30301 added the option to force mandatory account expiration notices for a given patron category in the membership_expiry cron. In these cases, the primary contact method on the patron account is used to determine the transport type for the notice. However, primary contact method may not be a mandatory field depending on the system preference settings. If a patron doesn't have a primary contact method set for their account, this causes the notice not to get sent at all, even if the patron has one or more valid email addresses or SMS number on their account. We need a fallback to ensure the mandatory notice is sent in this case. I think it would make the most sense to specify transport type(s) in the patron category settings when making account expiration notices mandatory for that category. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30301 [Bug 30301] Add an option to specify the patron expiration notices as mandatory by patron category -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 119