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

[Bug 42952] New: Public SRU with OPAC logic out-of-the-box
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 Bug ID: 42952 Summary: Public SRU with OPAC logic out-of-the-box Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- While working with Terry Reese to fix the MarcEdit integration with Koha, he pointed out that Koha doesn't have a public Z39.50/SRU endpoint out of the box. I think the reasoning previously has been that the z3950responder.pl and Zebra provide unfiltered access to the indexes. But... with the z3950responder.pl we could provide a more mediated access. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 31606] New: Enhance acquisitions to allow ordering on next year's budget when still in current year.
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31606 Bug ID: 31606 Summary: Enhance acquisitions to allow ordering on next year's budget when still in current year. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 140860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140860&action=e… Full description of problem of end-of-year processing & possible solution. The topic of end-of-year processing has come up regularly in the koha-us Acquisitions SIG. Librarians would like to have a way to order things for the next year when still in the current year and have the items showing up on the next year's budget. Example: our library has a fiscal year that goes from Oct 1 to Sept 30. A popular book will release October 15. We want to order the book in August. We would like to have the item ordered on the new fiscal year starting October. How do we do that? I have attached a Word document that more fully explains the issue and I have suggested a solution that I think will work for both EDI and non-EDI vendors. Please look over the solution and share any problems or improvements. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 61

[Bug 42994] New: Atomic update for Bug 40658 (local-number sortable) fails on Zebra-only installations
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42994 Bug ID: 42994 Summary: Atomic update for Bug 40658 (local-number sortable) fails on Zebra-only installations Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: dghdghfghfgh04(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- The atomic update script that implements Bug 40658 ("Ensure local-number is sortable"), located at installer/data/mysql/db_revs/251104011.pl (25.11.x) / equivalent on main, unconditionally instantiates the Elasticsearch indexer and calls update_mappings(), regardless of the SearchEngine system preference: my $index_name = $Koha::SearchEngine::Elasticsearch::BIBLIOS_INDEX; my $indexer = Koha::SearchEngine::Elasticsearch::Indexer->new( { index => $index_name } ); $indexer->update_mappings(); On a Zebra-only installation with no Elasticsearch server configured or running, this call fails, and koha-upgrade-schema / updatedatabase aborts partway through the atomic update with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_<instance>_biblios". Reason was: "". Index needs to be recreated and reindexed' accompanied by: Use of uninitialized value $reason in concatenation (.) or string at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Indexer.pm line 276. The "Reason was: ''" text and "Index needs to be recreated and reindexed" wording are misleading — they suggest a mapping conflict on an existing index. In practice, the failure occurs even when there is no Elasticsearch server reachable at all (verified via `ss -tlnp | grep 9200`, `curl` returning connection refused/000, and no elasticsearch systemd unit present). The root cause is that $reason in Indexer.pm (line 276) is never populated with the actual underlying error (connection failure, mapping conflict, or otherwise), so all failure modes are reported identically and misdirect troubleshooting toward index/mapping issues rather than connectivity. Steps to reproduce: 1. Set up or use an existing Koha instance with: - SearchEngine system preference = Zebra - No Elasticsearch server configured/running 2. Run koha-upgrade-schema <instance> (or updatedatabase.pl) up to/through the 40658 atomic update. 3. Observe the exception above; the upgrade halts. Expected behavior: The atomic update should check the SearchEngine system preference before attempting any Elasticsearch operations, e.g.: if ( C4::Context->preference('SearchEngine') eq 'Elasticsearch' ) { # existing ES mapping update logic } else { say_info($out, "Zebra in use: skipping Elasticsearch mapping update"); } The underlying database change (search_marc_to_field.sort = 1 for the local-number field) should still be applied regardless of search engine, since that part is search-engine-agnostic and succeeds independently of the ES call. Additionally, Indexer.pm line 276 should be fixed so that $reason is actually populated from the underlying exception/error, rather than being left uninitialized — this would have surfaced the real cause (connection failure) immediately instead of a misleading mapping-conflict message. Workaround used: 1. Manually verified and applied the DB-only change: UPDATE search_marc_to_field SET sort = 1 WHERE search_marc_map_id = <id for local-number/biblios/marc21>; 2. Patched the local copy of the atomic update script to skip the Elasticsearch call when SearchEngine != 'Elasticsearch'. 3. Re-ran the schema upgrade successfully. Note: this workaround needs to be reapplied after any package upgrade that overwrites the vendored atomic update script, until this is fixed upstream. Related: Bug 40658 (this report is about the atomic update script it introduced, not the local-number__sort fix itself, which is unrelated and working as intended). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36548] New: koha-zebra should fix ownership on /var/run/koha/instancename files
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36548 Bug ID: 36548 Summary: koha-zebra should fix ownership on /var/run/koha/instancename files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com koha-zebra is unable to stop and start a zebra process if ownership on /var/run/koha/instancename is wrong it already checks permissions on the relevant log files, it should also check on this directory -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 38360] New: Price extraction from MungeMarcPrice should be improved
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38360 Bug ID: 38360 Summary: Price extraction from MungeMarcPrice should be improved Change sponsored?: --- 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org MungeMarcPrice's "rescue mode", tries and catch the whole possible number patterns in one regexp, which leads to very curious authorized values, and can leave some price unmatched for curious reasons. Unmatched price that should be: 49.3 ; 555,555.3 (only 1 digit after separator) 50 (no digit) Matched prices that should not: ,,,,,,,35 ; ,.,..,.45 ; 99,999.999,99 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 38745] New: Add a proof of concept JSON-RPC driven endpoint for RPC style calls that don't fit REST ideals
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38745 Bug ID: 38745 Summary: Add a proof of concept JSON-RPC driven endpoint for RPC style calls that don't fit REST ideals Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a few places where RPC style calls to perform various actions makes sense.. thinking 'bulk' actions and also 'test' actions for things like the sftp connection checks I propose a distinct /rpc endpoint with a basic router built into the endpoint and oneOf being used to specify using the existing OpenAPI specifications. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 30096] New: Allow to change "late issue notification" setting in subscriptions batch modification tool
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30096 Bug ID: 30096 Summary: Allow to change "late issue notification" setting in subscriptions batch modification tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29997 Bug 29997 adds a "late issue notification" setting for subscriptions. This bug is for being able to modify this setting in the subscriptions batch modification tool. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29997 [Bug 29997] Allow to send email notification when a serial issue is late -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 42993] New: Koha::Edifact::Transport should log transport failures via Koha::Logger
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42993 Bug ID: 42993 Summary: Koha::Edifact::Transport should log transport failures via Koha::Logger Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Edifact::Transport reports every transport failure (no transport configured, connect failure, directory-change failure, file-listing failure and per-file download/upload failure) with carp. Under misc/cronjobs/edi_cron.pl these go to STDERR, so on a normal cron run the messages are lost: EDI simply goes quiet with nothing in editrace.log to explain why. This routes those failures through Koha::Logger on the 'edi' interface (the same interface edi_cron.pl already uses) so they are recorded in the EDI log. The two ingest()-level data warnings (duplicate filename, unreadable file) are intentionally left as carp: one is asserted by the existing unit test and neither is a transport failure. No change to the transfer logic. Test plan: 1. prove t/db_dependent/Koha/Edifact/Transport.t 2. Point an EDI account at an unreachable transport and run misc/cronjobs/edi_cron.pl; confirm the failure is now written to the EDI log rather than only to STDERR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42987] New: Opac renewal column does not have select all/none links
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '26

04 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42987 Bug ID: 42987 Summary: Opac renewal column does not have select all/none links 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The opac-user.pl page does not give the patron the option to select all/none in the renewal column like the staff have on circulation.pl. Is that purposeful, or should it be added? -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 42989] New: AccountAutoReconcile should apply to rental charges and overdue charges
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42989 Bug ID: 42989 Summary: AccountAutoReconcile should apply to rental charges and overdue charges Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The AccountAutoReconcile system preference, when set to 'Do', automatically balances a patron's debits and credits after a transaction. However, it does not apply to all transactions; in particular, it does not apply to rental charges and overdue charges. It is not logical for the reconciliation to happen automatically for some transactions and not for others. To replicate on main using KTD or a sandbox: 1. Go to Administration > System preferences. 2. Search for AccountAutoReconcile and set it to 'Do'. 3. Go to a user account, e.g. cardnumber 23529000033739. 4. On this user account, go to Accounting > Create manual credit. 5. Add a credit, e.g. Description = Credit; Amount = 20.00. 6. Still in the user's Accounting view, switch to Create manual invoice. 7. Add a manual invoice, e.g. Type = Lost item; Description = Lost item; Amount = 10.00. Save. 8. Still in the user's Accounting view, switch to Make a payment. Observe that the user has no outstanding charges: the credit and debit amount have been automatically reconciled, leaving the user in credit. 9. Go to Administration > Item types. Check that the Music item type has a rental charge of 5.00. 10. Go to user account's 23529000033739 > Check out view. 11. Note the message "Attention. Credits: Patron has outstanding credits of 10.00". 12. Check out Music item 39999000013634. 13. Note the message is now "Attention. Charges: Patron has outstanding charges of 5.00. Credits: Patron has outstanding credits of 10.00". This is a sign that unlike in steps 7-8, the debit and credit have not been automatically reconciled. 14. On this user account, go to Accounting > Make a payment. 15. Confirm that, unlike in step 8, there are outstanding credits to be applied manually. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2