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

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

[Bug 35066] New: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35066 Bug ID: 35066 Summary: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For libraries using the holds queue, they should have the ability to deny filling the hold so it would push the item onto the next branch's holds queue without having to wait for the cron to run. Right now, the only way to move an item off a library's queue is to mark it as missing/lost or damaged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 7923] Performance omnibus
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7923 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |43017 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43017 [Bug 43017] [OMNIBUS] Interface optimization -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41282] New: We should alert staff when a checked out item fills a different hold for a patron
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41282 Bug ID: 41282 Summary: We should alert staff when a checked out item fills a different hold for a patron Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When an item is checked out and the patron has a hold on the biblio we will fill thart hold with the item in hand Sometimes the hold this item fills has another copy that is already in transit or waiting on the shelf. We need to alert staff when this happens -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 43013] New: Adding a column to patron 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=43013 Bug ID: 43013 Summary: Adding a column to patron search results Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- It is possible to control which columns display in the patrons search result table but is it possible to expand the options here? It would be good if the 'last seen on' field in a user record could be displayed as it would allow libraries to immmediately see active users from a search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 43012] New: Item Search title column includes author
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43012 Bug ID: 43012 Summary: Item Search title column includes author Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an item search is done in the staff interface, the results are presented clearly in a tabular form on screen. However the title column also contains the author which means that sub filtering / column sorting by author isn't an option. Can the output of this search be changed so there are separate title and author columns? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2