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

[Bug 39224] New: Move Shibboleth config from koha-conf to the DB
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39224 Bug ID: 39224 Summary: Move Shibboleth config from koha-conf to the DB Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: jacob.omara(a)ptfs-europe.com Reporter: jacob.omara(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 38201 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 [Bug 38201] VueJS architecture rethink -- You are receiving this mail because: You are watching all bug changes.

1 158

[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 42317] New: [CVE-2014-1626] Require MARC::File::XML > 1.0.2
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42317 Bug ID: 42317 Summary: [CVE-2014-1626] Require MARC::File::XML > 1.0.2 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CVE-2014-1626 notes vulnerabilities in MARC::File::XML in versions less than 1.0.2. Looking at Koha's cpanfile we say that we require at least version 1.0.1, but that should be updated to 1.0.2 or even 1.0.5 since in practice only 1.0.5 is really available via CPAN or Debian repos. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 41690] New: Add MARC21 245$b (subtitle) to Cite option
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41690 Bug ID: 41690 Summary: Add MARC21 245$b (subtitle) to Cite option 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The "Cite" option in the OPAC is missing the subtitle (245$b) in MARC21. To recreate: 1. Add a record or find a record with a subtitle (in KTD, biblionumber 58 has a 245$b http://localhost:8081/cgi-bin/koha/catalogue/MARCdetail.pl?biblionumber=58 2. In the OPAC, go to the record http://localhost:8080/cgi-bin/koha/opac-detail.pl?biblionumber=58 3. Click "Cite" --> The subtitle is not in any of the citations I consulted a customer in a university and he said the subtitle should be after the title and be preceded by a colon. e.g. 'More fruitful than the soil' : army, empire and the Scottish Highlands, 1715-1815 -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 42262] New: MARC 006 tag editor plugin drops blank value in position 17 when editing existing tag
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42262 Bug ID: 42262 Summary: MARC 006 tag editor plugin drops blank value in position 17 when editing existing tag Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 When one opens the 006 tag editor plugin when editing a record that already has an 006 value, a blank value in position 17 is dropped by the plugin. This causes the record to save an invalid 006, triggering the error message added in Bug 40272. To recreate: - have a MARC record with Type of Material "BKS - Books" that does not have an 006 defined (biblio 1 in the KTD default data will work) - edit the biblio in the basic editor - open the tag editor for the 006 - observe that the values along the top of the tag editor window show a value of "" (blank) in position 17 - click Save in the tag editor window - confirm that the values in the 006 tag end with a space - open the 006 tag editor again - observe that the values along the top of the tag editor window no longer show any value for position 17. Instead, they end with the zero in position 16 - click Save in the tag editor window - confirm that the values in the 006 tag now end with a zero, not followed by a space - save your biblio - edit the biblio in the basic editor again, get warning "The following fixed-length control field(s) have an invalid length: 006. Please fix." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[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