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

[Bug 42661] New: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42661 Bug ID: 42661 Summary: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When making a reservation for a patron whose home library differs from the library where the staff member is logged in, the current notification contains redundant repetition when system preference HidePatronName is "Don't show". Steps to Reproduce: 1. Log in as staff to a library. 2. Set HidePatronName as "Don't show" 3. Attempt to reserve an item for a patron whose home library is different from the current logged-in library. 4. Observe the notification: Pickup library is different. Patron: A patron from library Midway Patron's home library: (Midway / MPL ) This text comes from the string Patron: %s Patron's home library: (%s /%s ) (%1$s: INCLUDE 'patron-title.inc' patron => patron no_title => 1 no_cardnumber => 1 hide_patron_infos_if_needed => 1 %2$s: Branches.GetName(patron.branchcode) | html %3$s: patron.branchcode | html) And the '%s' has it's own translation: %1$s: - Branches.GetName( patron.branchcode ) | html - A patron from library %s Can these sentences be clarified in any ways to avoid repeating the library name? It is okay when the sentence contains the patron name but when HidePatronName is activated it gets confusing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[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

[Bug 39769] New: es_indexer_daemon.pl uses stale L1 cache
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39769 Bug ID: 39769 Summary: es_indexer_daemon.pl uses stale L1 cache Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As bug 36549 notes, the es_indexer_daemon.pl doesn't fork child processes to do its work. This leads to memory leaks, but it also means that it's using a stale L1 cache. If you update a system preference like IncludeSeeFromInSearches, you have to restart your es_indexer_daemon.pl worker before you can re-index your database. Note that the solution to this problem does not have to be updating the daemon to fork child process workers. Rather, we need to clear the L1 cache after we fetch a job. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 39589] New: Search returns 'No results found' despite existing matching records
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39589 Bug ID: 39589 Summary: Search returns 'No results found' despite existing matching records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This issue occurs when the records on the first page of results are not displayed. The message "No results found" is shown, and it is not possible to access records on other pages. To test 1. Set the following system preferences: OPACnumSearchResults to 5 OpacHiddenItemsHidesRecord to Hide OpacHiddenItems to withdrawn: [1] 2. Create 6 bibliographic records with the following titles: "notice test 1" "notice test 2" "notice test 3" "notice test 4" "notice test 5" "notice test 6" 3. For the first 5 records, add an item with Withdrawn status. 4. For "notice test 6", add an item with Available status. 5. In the OPAC interface, search for "notice test". ---> The message "No results found!" appears, and "notice test 6" is not visible. -- You are receiving this mail because: You are watching all bug changes.

1 68

[Bug 35061] New: Add support to preserve patron category code when importing patrons with commandline script
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35061 Bug ID: 35061 Summary: Add support to preserve patron category code when importing patrons with commandline script Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 34166] New: Show total price in table of suggestions
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34166 Bug ID: 34166 Summary: Show total price in table of suggestions Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For determining if a suggestion is accepted the price can play a big role. Sometimes libraries will have a separate custom status for items that need to wait for available funds. It would be great if Koha showed the total price of the suggestion in the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28