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

[Bug 42625] New: Allow records to be locked for editing based on library & group
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42625 Bug ID: 42625 Summary: Allow records to be locked for editing based on library & group 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 31791 established record locking based on record source. We'd like to extend that to allow records to be locked for some users based on library and library group. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 191

[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 43203] New: Item.t doesn't clean up after itself correctly
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43203 Bug ID: 43203 Summary: Item.t doesn't clean up after itself correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When running Item.t, three biblio records will be created and left in the database after the tests have finished -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42924] New: Restore default MaxAge for CSRF token
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42924 Bug ID: 42924 Summary: Restore default MaxAge for CSRF token Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 17110 lowered the default MaxAge for the CSRF token from 1 week to 8 hours, but that has led to increased usability problems for negligible security gains. I propose to restore the default which is closer to the per-session approach for CSRF tokens which tends to be the default in many web frameworks like Django. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 42789] New: EDI ORDRSP: Item and suggestion status not updated when order line cancelled by supplier
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42789 Bug ID: 42789 Summary: EDI ORDRSP: Item and suggestion status not updated when order line cancelled by supplier Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org When an EDI ORDRSP message cancels an order line, Koha marks the order status to 'cancelled' but does not update the status of associated items or purchase suggestions. Items created as part of the acquisition (on-order items) retain their existing status, which can prevent holds from being placed or fulfilled. Similarly, any purchase suggestion that drove the original order is not updated to reflect that the order has been cancelled, leaving suggestions in a misleading state. Customer reports confirm that in some configurations items are being deleted on cancellation, causing holds to fail. The correct behaviour â whether to delete, update status, or transfer holds â needs to be defined and implemented consistently for the EDI cancellation code path, matching the behaviour of manual cancellation via the acquisitions UI. The processing logic is in Koha/EDI.pm, process_ordrsp() (~line 199-248). Test plan: 1. Create an order with associated on-order items and/or a linked suggestion. 2. Place a hold on one of the on-order items. 3. Receive an EDI ORDRSP cancellation for that order line and run edi_cron.pl. 4. Confirm the order line is marked cancelled. 5. Confirm on-order items are handled appropriately (status updated / holds transferred). 6. Confirm any linked suggestion is returned to a pending/unfulfilled state. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 42727] New: Languages displayed in random order in language menu
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42727 Bug ID: 42727 Summary: Languages displayed in random order in language menu Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 27

[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