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

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

12 Oct '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 19

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

12 Oct '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 41

[Bug 43777] New: Koha::Biblio::Metadata->record should repair recoverable MARCXML faults on read
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43777 Bug ID: 43777 Summary: Koha::Biblio::Metadata->record should repair recoverable MARCXML faults on read 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 35104 stops MARCXML with non-XML characters or empty datafields from being saved, by repairing it in Koha::Biblio::Metadata->store() and recording what was fixed. Data that was already in the database before that (or that arrived by scripts or direct SQL outside Koha) can still be undecodable, and every place that reads it has to cope. The follow-up bugs for 35104 (43025, 43026, 43027, 43028, 43029, ...) are each re-implementing the same handling: eval { $metadata->record }, catch Koha::Exceptions::Metadata::Invalid, try repair_marcxml, fall back to record_strip_nonxml, then render the per-fault warnings in their own template. record_strip_nonxml also overlaps repair_marcxml, but only handles one of its two faults. Proposal: make the read path repair the same faults as store(). - Koha::Biblio::Metadata->record falls back to repair_marcxml when the stored MARCXML cannot be decoded, and returns the repaired MARC::Record. - The faults that were repaired are reported through object_messages, the same way store() reports them, so callers that want to tell the user can, and callers that do not care simply ignore them. record still returns a single value (no context-sensitive return). - Metadata that cannot be recovered still throws Koha::Exceptions::Metadata::Invalid. - The repair is not written back to the database; store() remains the only place that writes biblio_metadata_errors rows. - record_strip_nonxml is removed and its callers use record. - A shared template include renders the repair messages so the follow-up bugs do not each carry their own copy. Test plan: 1. Apply the patches on top of bug 35104. 2. prove t/db_dependent/Koha/Biblio/Metadata.t 3. Write MARCXML containing a control character (e.g. U+001F) or an empty datafield straight into biblio_metadata.metadata with SQL, then call $biblio->metadata->record and confirm a MARC::Record is returned and object_messages describes the repair. 4. Confirm unrecoverable MARCXML still throws Koha::Exceptions::Metadata::Invalid. 5. prove t/db_dependent/Biblio.t t/db_dependent/OAI/Server.t t/db_dependent/Exporter/Record.t Sponsored-by: OpenFifth -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 43781] New: Update syntax for overriding sysprefs from Apache config
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43781 Bug ID: 43781 Summary: Update syntax for overriding sysprefs from Apache config Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 10325 made it possible to override sysprefs from the Apache config. Today there are two template Apache config files: debian/templates/apache-site-https.conf.in does not contain information about overriding sysprefs. etc/koha-httpd.conf has this: # This syntax allows you to override a system preference # for a given virtual host. Use with caution! # You should add all the system preferences you override # in one or more vhosts to the environment variable # OVERRIDE_SYSPREF_NAMES for your staff intranet vhost # SetEnv OVERRIDE_SYSPREF_PrefName Value and this: # Repeat this virtualhost stanza changing the following environment vars to # create multiple OPAC interfaces with custom css and/or search limits: # SetEnv OPAC_CSS_OVERRIDE mystyle.css # SetEnv OPAC_SEARCH_LIMIT branch:CODE # SetEnv OPAC_LIMIT_OVERRIDE 1 and this: # If you are overriding any system preferences, # list them in this variable so the preference editor # knows that they have been overridden. # SetEnv OVERRIDE_SYSPREF_NAMES "Pref1,Pref2,Pref3" But the syntax for the syspref overrides has been changed, as shown here: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43780] New: Add staff search groups to IntranetAddMastheadLibraryPulldown
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43780 Bug ID: 43780 Summary: Add staff search groups to IntranetAddMastheadLibraryPulldown Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 9257 added OPAC search groups to the OPAC masthead, but the staff search groups are only accessible in advanced search. Consortial libraries would especially benefit from the ability to search library groups more easily. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37645] New: Add ability to batch waive fines
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37645 Bug ID: 37645 Summary: Add ability to batch waive fines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if there's an ability in Koha to waive fines/fees in a batch. This is part of a regular workflow for libraries, especially those who regularly purge patron accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 78

[Bug 43389] Remove conditional TT tags from tables thead (Holdings tables)
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43389 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #5 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Hi all, searching the holdings table is now broken on a default install: 1) Apply the patch, restart_all 2) Make sure 'EnableItemGroups' is disabled (the default): http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfie… 3) Open a record with items, with the browser console open: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=22 4) Type anything (e.g. "foo") in the 'Holdings' table 'Search' box. 5) The table errors, and /api/v1/biblios/22/items returns a 500. 6) Without the patch, the search works. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43779] New: Transaction column contents blank when exporting register transaction history
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43779 Bug ID: 43779 Summary: Transaction column contents blank when exporting register transaction history Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: martin.renvoize(a)openfifth.co.uk Target Milestone: --- When exporting the Transaction History table for a register, the "Transaction" table is blank in the export. This is the column that contains the date of each transaction and its accountlines_id. To recreate: - enable cash registers and point of sale - configure a cash register - configure a debit type to be available to sell - record one or more sales in the POS system - from POS, click "Cash summary for [branch]" - in the cash summary, click the name of your register - this brings you to the transaction history (/cgi-bin/koha/pos/register.pl?registerid=[register ID]" - see the Transaction column contains transaction dates - click Export, selecting any format - see your export has no values for the Transaction column -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43778] New: Discrepancy in OPAC results vs details with status when AllowHoldsOnDamagedItems is off
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43778 Bug ID: 43778 Summary: Discrepancy in OPAC results vs details with status when AllowHoldsOnDamagedItems is off Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- 1- Set AllowHoldsOnDamagedItems to 'Don't allow' 2- Find or create some items that have both a NOT_LOAN ( notforloan ) value and a DAMAGED value 3- Do a search in the OPAC that will return the item from step 2 in the OPAC search results 4- The item shows as in the search results like: Availability: Not available: Centerville: Damaged (1). 5- The description from the DAMAGED AV does not appear and neither does anything about the NOT_LOAN value 6- Click on the record and view the detail display. Here, in the status column, I see the NOT_LOAN description but not the DAMAAGED status or description -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43505] New: Use Koha::QA from the test suite
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '26

12 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43505 Bug ID: 43505 Summary: Use Koha::QA from the test suite Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes.

1 22