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 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 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 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 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 43000] New: Trail of who places a hold/reserve
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43000 Bug ID: 43000 Summary: Trail of who places a hold/reserve Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Suzanne.Wilson(a)cntw.nhs.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- On holds/reserves, it would be useful to know who placed the hold (library staff or user) so that any issues can be queried with the person who entered it. In the log viewer it's difficult to identify the transaction and /or the member of staff. Thanks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21391] New: Add per user interface settings
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21391 Bug ID: 21391 Summary: Add per user interface settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are some setting in system preference, which are related to user interface and could be useful to have an ability to set it for each user separately and use global preference as fallback only. For example: StaffLangSelectorMode AudioAlerts intranetbookbag IntranetCatalogSearchPulldown viewISBD viewLabeledMARC viewMARC hide_marc IntranetBiblioDefaultView advancedMARCeditor CircSidebar ExportCircHistory previousIssuesDefaultSortOrder todaysIssuesDefaultSortOrder EnableSearchHistory numSearchResults defaultSortField defaultSortOrder displayFacetCount expandedSearchOption NumSavedReports And in the future the cash register from Bug 11373 There could be admin page where the system administrator could enable/disable the settings for users and then in users menu could be new item - interface settings where users could change their preferences. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 31383] New: Additional contents: We need a parent and child table
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31383 Bug ID: 31383 Summary: Additional contents: We need a parent and child table Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In the design of additional contents the idea of a parent-child relation is implicitly present. You have a default page and translations. But we do this in one table coming from the old news items. Several reports show (imo) that we would be better off creating a parent table listing the main news items, CMS pages or HTML content. And a child table containing all language related stuff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 173

[Bug 15326] Add CMS feature
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15326 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43019 -- You are receiving this mail because: You are watching all bug changes.

1 0