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

[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 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 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 43025] New: Show metadata repair warnings in the cataloguing edit form
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43025 Bug ID: 43025 Summary: Show metadata repair warnings in the cataloguing edit form 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 makes Koha::Biblio::Metadata->store() recover non-XML characters and empty datafields automatically (recording what was fixed in biblio_metadata_errors), or throw Koha::Exceptions::Metadata::Invalid when a record's MARCXML cannot be saved at all. This patch surfaces that in the place cataloguers actually hit it: the cataloguing edit form. This patch: - Catches Koha::Exceptions::Metadata::Invalid on save in cataloguing/addbiblio.pl and shows a clear error instead of a raw exception, keeping the form populated so nothing is lost. - Shows a "Record saved with modifications" warning when a save succeeded but required automatic repair. - Lists any pre-existing, unresolved metadata errors when opening a record for editing, each with a quick-link to the affected field (where the field survived the repair) and a "Mark resolved" action. - Adds DELETE /api/v1/biblios/{biblio_id}/metadata/errors/{error_id} to resolve (delete) a metadata error row, used by the "Mark resolved" action. Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Catalogue a new record (or edit an existing one) and add a control character (e.g. paste text containing a Unit Separator, 0x1F) into a subfield value. Save the record. 3. Confirm the record saves successfully and a "Record saved with modifications" warning banner appears describing what was automatically fixed. 4. Re-open the record for editing. Confirm a "Data quality warnings" banner lists the fault, with a "Go to field" link and a "Mark resolved" button. 5. Click "Go to field" - confirm it switches to the correct tab and scrolls to the affected field. 6. Click "Mark resolved" - confirm the warning disappears immediately and does not reappear after reloading the page. 7. Save a record that cannot be repaired at all (e.g. temporarily force Koha::Biblio::Metadata::store to throw Koha::Exceptions::Metadata::Invalid, or use a MARC::File::XML error you can reproduce) - confirm a clear error message is shown and the form is redisplayed with your data intact, rather than a raw exception or a 500 error. 8. prove t/db_dependent/api/v1/biblios_metadata_errors.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 watching all bug changes. You are the assignee for the bug.

1 8

[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