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

[Bug 42702] New: Acquisitions: Cancel order link on parcel.pl absorbs following HTML into href
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42702 Bug ID: 42702 Summary: Acquisitions: Cancel order link on parcel.pl absorbs following HTML into href Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: nugged(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The pending orders table on parcel.pl builds a malformed "Cancel order" link. The generated href is not closed after the invoice_id value, so the link text and following HTML are appended to the href. Steps to reproduce: 1. In Acquisitions, create or use a closed basket with a pending order. 2. Receive a shipment for the vendor and open the invoice receive page. 3. Inspect the "Cancel order" link in the pending orders table. Expected result: The link is rendered as valid HTML: <a href="/cgi-bin/koha/acqui/cancelorder.pl?...&referrer=/cgi-bin/koha/acqui/parcel.pl?invoiceid=3">Cancel order</a> Actual result: The link text and following HTML are included in the href: <a href="/cgi-bin/koha/acqui/cancelorder.pl?...&referrer=/cgi-bin/koha/acqui/parcel.pl?invoiceid=3Cancel order</a>... Notes: This appears to be a regression from the Bug 41563 parcel.tt tidy follow-up. Bug 41848 and Bug 42603 fixed nearby variable-name issues, but this malformed href remains. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 41425] New: Log entries for merging patrons are untranslatable
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41425 Bug ID: 41425 Summary: Log entries for merging patrons are untranslatable Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Depends on: 22632 Koha/Patron.pm: . " has been merged into " We should never hardcode strings into .pm, they are not translatable. This should be solved on template level instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22632 [Bug 22632] Add logging of merged patrons -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 42669] New: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42669 Bug ID: 42669 Summary: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 39769 es_indexer_daemon.pl has two issues that cause silent data loss: 1. When update_index() throws an exception (e.g. NoNodes, BadResponse), the exception is caught and logged, but the job is still marked status='finished'. This means records are never re-indexed and silently disappear from search results. 2. The Search::Elasticsearch client (cxn_pool=Static) marks nodes as 'dead' after a connection failure and applies exponential backoff up to 60 minutes. Since the indexer objects are created once at daemon startup, a brief ES restart (e.g. Docker upgrade) leaves the daemon permanently stuck in NoNodes state until manually restarted. Fix: - On NoNodes: abort the batch, recreate the indexer object (resetting the connection pool), and reset jobs to status='new' for automatic retry. - On other indexing errors: mark jobs as 'failed' instead of 'finished'. Test plan: 1. Start es_indexer_daemon.pl 2. Stop Elasticsearch 3. Add/modify a biblio record (triggers indexing job) 4. Verify the job stays in status='new' (not 'finished') 5. Restart Elasticsearch 6. Verify the job is picked up and indexed successfully Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39769 [Bug 39769] es_indexer_daemon.pl uses stale L1 cache -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42937] New: Not testing 'strict' for perl?
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42937 Bug ID: 42937 Summary: Not testing 'strict' for perl? Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- t/db_dependent/00-strict.t 22 $Test::Strict::TEST_STRICT = 0; 0? -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 42920] New: Looking up authority records in Advanced editor appends 20 extra spaces
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42920 Bug ID: 42920 Summary: Looking up authority records in Advanced editor appends 20 extra spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21453 Target Milestone: --- The patch for bug 21453 replaced an Advanced editor-specific (in the "[% IF rancor %]" block) "[%- END -%]‡9[% authid | html %]";" which trims whitespace with several lines of "[% ... %]" which do not trim whitespace. The result is that when you look up an authority from the Advanced editor, you get something like ‡aBildungsromans. ‡9220 with twenty extra spaces before the ‡9. While we could restore trimming the whitespace, that section of the patch wasn't needed, and has made things incorrect for anyone who dares to use the Advanced editor with UNIMARC (probably nobody, since it doesn't do UNIMARC fixed-field builders): since the Advanced editor is only used for biblio records, not authority records, it *should* be putting the authid in ‡9 for both MARC flavors the way it was before, but now it will put it in ‡3, the right field for auth-to-auth linking but the wrong field for biblio-to-auth linking. So the right fix is just to revert the changes to the [% IF rancor %]" block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 [Bug 21453] blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 42617] New: ILL availability pagination not working
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42617 Bug ID: 42617 Summary: ILL availability pagination not working Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 42568] New: Match maxlength attributes to marc_order_accounts column sizes
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42568 Bug ID: 42568 Summary: Match maxlength attributes to marc_order_accounts column sizes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 34355 There are a few fields in the MARC order accounts entry form which should have a maxlength attribute to prevent an error if the user enters more characters than the db can accept. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34355 [Bug 34355] Automated MARC record ordering process -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42349] New: Incorrect filter by recalls
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42349 Bug ID: 42349 Summary: Incorrect filter by recalls 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 Depends on: 37334 On the holdings table the filter by status=recalls is not working correctly. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37334 [Bug 37334] Cannot filter holdings table by status -- You are receiving this mail because: You are watching all bug changes.

1 20