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

[Bug 34551] New: Don't allow Z39.50 import if MARC can't be converted to MARCXML
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34551 Bug ID: 34551 Summary: Don't allow Z39.50 import if MARC can't be converted to MARCXML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 As I note on bug 34014 and bug 34549, if you've got the wrong encoding on your Z39.50 server, you can wind up importing MARC data that contains invalid data (like control characters). During copy cataloguing, there should be a warning that there's a problem with the data (possibly because of Z39.50 server config). That way we have librarians raising the flag that there's a problem before the data is in Koha rather than us doing cleanup after it's been imported. (Of course, bulk loaded MARC will still be a problem, but baby steps...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 43029] New: Guard maintenance scripts against biblios with corrupt metadata
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43029 Bug ID: 43029 Summary: Guard maintenance scripts against biblios with corrupt metadata Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 35104 Target Milestone: --- Bug 35104 makes Koha::Biblio::Metadata->record()/store() throw Koha::Exceptions::Metadata::Invalid for a record whose MARCXML cannot be decoded. misc/maintenance/sanitize_records.pl and misc/maintenance/touch_all_biblios.pl both read a biblio's metadata record and unconditionally re-save it across every biblio in the database, so a single already-corrupt record (which could exist from before bug 35104, or from a source outside Koha's own validation) would abort the whole run. This patch wraps the read (and, for touch_all_biblios.pl, the resulting ModBiblio) so one such biblio is skipped and reported rather than aborting the whole maintenance run. Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Create a biblio with metadata that is already corrupt, bypassing Koha::Biblio::Metadata's validation (e.g. write invalid MARCXML directly to the biblio_metadata row via the DBIC schema result, not through ->store()), alongside several normal biblios. 3. Run misc/maintenance/sanitize_records.pl --verbose across all biblios. Confirm the corrupt one is skipped with a clear "ERROR: Invalid record" message and the script completes for every other biblio without dying. 4. Run misc/maintenance/touch_all_biblios.pl similarly. Confirm the corrupt record is counted/logged as an error and the other records are still touched successfully. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43026] New: Show metadata repair warnings on the biblio detail and MARC detail pages
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43026 Bug ID: 43026 Summary: Show metadata repair warnings on the biblio detail and MARC detail pages 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35104 Target Milestone: --- Bug 35104 records unresolved metadata repair faults (e.g. stripped non-XML characters) in biblio_metadata_errors. Cataloguers reviewing a record via catalogue/detail.pl or catalogue/MARCdetail.pl, rather than opening it for editing, currently have no way to know it was automatically repaired on its last save. This patch lists any unresolved biblio_metadata_errors as a warning banner on both pages. Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Using a biblio with at least one unresolved metadata error (see bug 35104's test plan for how to create one), open catalogue/detail.pl?biblionumber=X. Confirm the warning banner listing the fault appears. 3. Open catalogue/MARCdetail.pl?biblionumber=X for the same biblio. Confirm the same warning appears there too. 4. Open a biblio with no metadata errors on either page. Confirm no warning banner appears. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43023] New: A single record with corrupt metadata can break rendering of search results
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43023 Bug ID: 43023 Summary: A single record with corrupt metadata can break rendering of search results Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 35104 Target Milestone: --- Two unguarded MARC decode calls in search result rendering: 1. C4::Search::searchResults (C4/Search.pm), the "scan" search branch, calls MARC::Record->new_from_usmarc directly on each raw Zebra scan result with no eval. 2. C4::Search::new_record_from_zebra's Elasticsearch fast path (C4/Search.pm) returns MARC::Record->new_from_xml($raw_data, 'UTF-8') directly, without the eval wrapper that the Zebra dom/grs1 branches further down in the same sub already have. If a corrupted record ends up in the index (e.g. left over from a legacy import, or synced from a source that had this problem), rendering the result list can die for that page of results instead of degrading gracefully for the one bad record. Found while auditing other places in the codebase that ingest externally-sourced MARC data, prompted by bug 35104. Test plan: 1. Get a record with undecodable stored metadata into the search index (e.g. via direct DB manipulation of biblio_metadata before reindexing, or by reindexing a legacy corrupt record). 2. Run a scan search, and separately a normal search, that includes that record among the results, on both a Zebra and an Elasticsearch installation. 3. Before a fix: the results page/list can die instead of just omitting or flagging that one result. 4. After a fix: the rest of the results render normally. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43027] New: Handle undecodable metadata gracefully when merging bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43027 Bug ID: 43027 Summary: Handle undecodable metadata gracefully when merging bibliographic records 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35104 Target Milestone: --- Merging into a reference record calls ModBiblio, which can now throw Koha::Exceptions::Metadata::Invalid (bug 35104) if the merged result cannot be saved. cataloguing/merge.pl did not handle this, so the cataloguer would see a raw exception with no indication of what happened to the merge. This patch catches the exception, aborts the merge (the reference record was not modified, since ModBiblio failed before anything was merged away), and shows a clear message. A recoverable fault fixed during the merge is shown as a warning instead, the same as the cataloguing edit form (bug 43025). Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Merge two normal bibliographic records as usual. Confirm the merge still completes successfully and the report screen displays as before. 3. Arrange for the merge result to be unrecoverable (e.g. temporarily force Koha::Biblio::Metadata::store to throw Koha::Exceptions::Metadata::Invalid for this merge). Attempt the merge. Confirm a clear error is shown, the reference record is unchanged, and no partial merge occurred (the other record(s) were not deleted/merged away). 4. Arrange for the merge result to require automatic repair (a recoverable fault). Confirm the merge completes and the report screen shows a warning describing what was fixed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42958] New: Expand Elasticsearch/Opensearch usage across Koha beyond bibliographic search
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42958 Bug ID: 42958 Summary: Expand Elasticsearch/Opensearch usage across Koha beyond bibliographic search Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 42835 Blocks: 42508 Target Milestone: --- Koha's Elasticsearch/Opensearch integration is currently focused primarily on bibliographic records (the biblios and authorities indices). This META bug tracks efforts to extend Elasticsearch-backed search and indexing to other areas of Koha where it can improve performance, relevance ranking, and scalability over traditional SQL-based queries. Initial goals: - Provide Elasticsearch-backed indices for data types beyond bibliographic records - Reduce reliance on expensive SQL LIKE queries for search-heavy workflows - Enable faceting, relevance ranking, and full-text search in more areas of the staff interface and OPAC Potential future scope (not exhaustive): - Acquisitions/orders search - Serials search - Course reserves - Z39.50/SRU target expansion This is a tracking/collection bug only. Individual feature bugs should be filed separately and blocked against this one. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 [Bug 42508] Add Elasticsearch patron search feature https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 [Bug 42835] ElasticSearch should have an items index -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43022] New: Biblio create/update REST endpoints return a raw 500 for undecodable MARC
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43022 Bug ID: 43022 Summary: Biblio create/update REST endpoints return a raw 500 for undecodable MARC Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 35104 Target Milestone: --- Koha::REST::V1::Biblios's create and update actions call MARC::Record->new_from_xml / new_from_mij_structure / new_from_usmarc directly on the request body with no eval (Koha/REST/V1/Biblios.pm, the create and update methods). A malformed MARCXML/MARC-in-JSON/ISO2709 payload from an API client currently produces a raw 500 response with a Perl exception message in the body, instead of a clean 400-style validation error. Found while auditing other places in the codebase that ingest externally-sourced MARC data, prompted by bug 35104. Test plan: 1. POST to /api/v1/biblios (or PUT to update an existing one) with a Content-Type matching one of the supported MARC formats, and a body that cannot be decoded (e.g. truncated/invalid MARCXML). 2. Before a fix: the response is a 500 with a raw exception/stack trace. 3. After a fix: the response is a 400-class error with a clear message describing the decoding problem. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 43024] New: A couple of lower-traffic paths don't guard against undecodable MARC either
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43024 Bug ID: 43024 Summary: A couple of lower-traffic paths don't guard against undecodable MARC either Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35104 Target Milestone: --- Two lower-traffic, isolated spots with the same unguarded-MARC-decode pattern as bug 35104 and its other follow-ups, found during the same audit but rated lower priority since they're narrower/rarer code paths: 1. C4::Items::_parse_unlinked_item_subfields_from_xml (C4/Items.pm) calls MARC::Record->new_from_xml on an item's more_subfields_xml with no eval. This would only be hit if that column's content is itself malformed, which would usually already have failed at storage time - but there's no guard here if it happens anyway (e.g. data imported directly into the DB, or written before item metadata was validated on save). 2. C4::Record::marc2endnote (C4/Record.pm) calls MARC::Record->new_from_usmarc with no eval, when exporting a record to EndNote format. A record with undecodable stored MARC would fail the export with no clear message, though this failure is isolated to the one export action and doesn't cascade. Found while auditing other places in the codebase that ingest/re-decode MARC data, prompted by bug 35104. Filed for tracking; lower priority than the other bugs from the same audit given how narrow and rarely-hit these two paths are. Test plan: 1. Get an item with undecodable more_subfields_xml (e.g. via direct DB manipulation), then trigger whatever code path calls _parse_unlinked_item_subfields_from_xml for it. 2. Get a biblio with undecodable stored MARCXML, then export it via whatever UI/API path calls marc2endnote. 3. Before a fix: both die with an unhandled exception. 4. After a fix: both fail gracefully with a clear message. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43028] New: Isolate one undecodable record from aborting a batch import or revert
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43028 Bug ID: 43028 Summary: Isolate one undecodable record from aborting a batch import or revert Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 35104 Target Milestone: --- Bug 35104 makes Koha::Biblio::Metadata->store() throw Koha::Exceptions::Metadata::Invalid for MARCXML it cannot save. Batch import (C4::ImportBatch::BatchCommitRecords/_batchCommitItems), batch revert (BatchRevertRecords), the corresponding background jobs, the CLI tools built on them (misc/commit_file.pl, misc/migration_tools/bulkmarcimport.pl), and Koha::Import::Record::get_marc_record all needed updating so one bad record doesn't take the rest of the batch down with it. This patch: - Catches the exception per-record in BatchCommitRecords (which already commits per-record) and per-item in _batchCommitItems, flagging the record/item with an 'error' status and message and counting it via a new $num_errored return value, instead of letting it propagate. - Does the same for BatchRevertRecords, which runs as a single whole-batch transaction: both the marcxml_old decode step and the ModBiblio/ModAuthority call that follows it are isolated, so one record that can't be restored doesn't roll back every other record already reverted in the same batch. - Threads the new error counts through Koha::BackgroundJob::MARCImportCommitBatch/RevertBatch's job report, and counts errored records towards job progress so a batch containing them doesn't get stuck showing as still running. - Reports the new counts in misc/commit_file.pl's CLI summary and logs a warning line for records automatically repaired during bulkmarcimport.pl. - Surfaces each errored row's reason as a tooltip on its "Error" status badge in the manage-marc-import listing. - Makes Koha::Import::Record::get_marc_record reuse Koha::Biblio::Metadata::repair_marcxml (bug 35104) instead of its own weaker strip-and-retry, so staged import records get the same recovery (including empty-datafield handling) as the interactive cataloguing form. Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Stage a MARC file for import (Tools > Stage MARC records for import) containing at least one deliberately malformed record (e.g. a datafield with no subfields, or invalid control characters that cannot be repaired) alongside normal records. 3. From Manage staged records, commit the batch. Confirm: the bad record is flagged with an 'error' status and a tooltip explaining why; every other record in the batch imports successfully; the job report/CLI summary shows a "Number of records with errors" count. 4. Revert the same batch. Confirm one record whose marcxml_old cannot be restored does not prevent the rest of the batch from reverting, and the job report reflects the error count. 5. Run misc/migration_tools/bulkmarcimport.pl from the CLI against a file containing a record with a recoverable fault (e.g. a non-XML character). Confirm a WARNING line is logged for that record and the import otherwise completes normally. 6. prove t/db_dependent/ImportBatch.t t/db_dependent/Koha/BackgroundJob/MARCImportCommitBatch.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 41162] New: Warn that printing large barcode ranges can lead to running out of memory
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 Bug ID: 41162 Summary: Warn that printing large barcode ranges can lead to running out of memory Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org If you are using the barcode range option in the label creator, if your barcode range is too large, your Koha server may run out of memory before the process finishes. This causes out of memory errors. This could happen if a library had e.g. "100101223" as their last used barcode and they wanted to print the next 50 barcodes and they make a mistake while entering the "To:" field in the barcode range creator. From: 100101224 To: 1000101274 You could very easily accidentally cause the label-create.pl process to create insane amounts of barcodes. In this case 900 million barcodes would be created, if my math is right. :) The memory usage will slowly increase as barcodes are created and "eventually" there will be no more memory left, causing OOM killer to strike. We should at least warn in the barcode range creation tool that such problems can happen if you aren't careful while entering values. I don't know if there's a good way to stop users from entering too large ranges, maybe there is a valid use case for a large barcode range if you have enough memory. To reproduce (assuming you are on ktd): 1. Check your current memory usage, e.g. with "ps aux --sort -rss" (or "free -h" to see how much memory is still free) 2. Make sure you know how to kill a process in Debian, e.g. "killall -9 /kohadevbox/koha/labels/label-create-pdf.pl" - you will need it soon.. 3. Go to Cataloging -> Label Creator -> Print barcode range 4. Enter in a number in "From:" and a crazy high number in "To:"; see above for an example 5. Print range -> Export (doesn't matter which templates etc.) -> Click on "Download as PDF" 5. Check your memory usage again, it should start spiking over the next minutes. The guilty process should be /kohadevbox/koha/labels/label-create-pdf.pl (assuming you are on ktd). 6. Either kill the process or you will run out of memory -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9