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

[Bug 43342] New: Default OVERDUES_SLIP contains empty lines
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43342 Bug ID: 43342 Summary: Default OVERDUES_SLIP contains empty lines Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- The default template for the overdues slip inserts blank lines due to template toolkit blocks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43331] New: No class on collection code in holdings table on bib detail
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43331 Bug ID: 43331 Summary: No class on collection code in holdings table on bib detail 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- In the holdings table on the bib details page, most cells have a class that denotes which piece of data is contained there ("homebranch", "shelvingloc", etc). But the collection code column does not have a class. It should have one. Probably "ccode"? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43330] New: C4::Tags fails to compile when TagsExternalDictionary is configured
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43330 Bug ID: 43330 Summary: C4::Tags fails to compile when TagsExternalDictionary is configured Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When the TagsExternalDictionary system preference contains a value, C4::Tags fails to compile with: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. This can cause HTTP 500 errors throughout the staff interface on pages which load C4::Tags, including the staff home page, catalog detail pages, and Tools. Observed on Koha 25.11.06. The problem appears to be caused by the order in which check_install is imported in C4/Tags.pm. Currently C4/Tags.pm contains: use Modern::Perl; use base 'Exporter'; use C4::Context; BEGIN { ... my $ext_dict = C4::Context->preference('TagsExternalDictionary'); if ( $ext_dict && !check_install( module => 'Lingua::Ispell' ) ) { warn "Ignoring TagsExternalDictionary, because Lingua::Ispell is not installed."; $ext_dict = q{}; } ... } but Module::Load::Conditional is loaded later: use Module::Load::Conditional qw( check_install ); Because the check occurs inside a BEGIN block, the BEGIN block is executed during compilation before Perl reaches the later `use Module::Load::Conditional` statement. As a result, when TagsExternalDictionary has a non-empty value, Perl attempts to call check_install() before that function has been imported. When TagsExternalDictionary is empty, the problem is hidden because this expression short-circuits: $ext_dict && !check_install(...) so check_install() is never called. To recreate: 1. Set the TagsExternalDictionary system preference to a non-empty value, for example: /usr/bin/ispell 2. Restart Plack if necessary. 3. Visit a staff interface page which loads C4::Tags, such as the staff home page or a bibliographic detail page. OR reproduce directly from the command line: perl -MC4::Tags -e 'print "C4::Tags loaded OK\n"' 4. Observe: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. BEGIN failed--compilation aborted at C4/Tags.pm line 53. Compilation failed in require. BEGIN failed--compilation aborted. 5. Clear TagsExternalDictionary and clear/update the system preference cache. 6. Run the same command again. 7. C4::Tags loads successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[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 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