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

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

06 Aug '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 8

[Bug 43229] New: Purchase suggestions incorrectly promises an email confirmation for anonymous suggestions
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43229 Bug ID: 43229 Summary: Purchase suggestions incorrectly promises an email confirmation for anonymous suggestions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- 1. Enable preference suggestion 2. Enable preference AnonSuggestions 3. Navigate to OPACBaseURL/cgi-bin/koha/opac-suggestions.pl?op=add_form (make sure you are not logged in) 4. Click "+ New purchase suggestion" 5. Observe text "You will receive an email when the library processes your suggestion." -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42528] New: metadata_record should always strip nonxml characters
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42528 Bug ID: 42528 Summary: metadata_record should always strip nonxml characters 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This was inspired by noticing that when importing a batch the indexing could fail for a batch of records where a single record had encoding issues. Koha::Biblio->metdata_record is used for retrieving records from the DB, and possibly filtering them. In the cases we are using this, it's better to give the user/caller a result than nothing The error on the record is logged, it can be seen when viewing the record in the staff interface, and can be found using the data inconsistencies tool. I think it makes sense for the default behavior to attempt to clean the record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 21264] New: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Bug ID: 21264 Summary: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We should test for remains of bug 20461. Which will cause that more items (serial issues) will be created with an itype to NULL See the following for more details about the issue https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461#c13 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 34632] New: Patron Importing should be a background job
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34632 Bug ID: 34632 Summary: Patron Importing should be a background job Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi friends, Now that we have a lovely queue for our background jobs, we should make the patron import use the queue to process those and store the outcome. This will help us avoid the 500/600/whatever you set apache timeouts experienced by libraries whenever they import batches of patrons of any significant size. Cheers, Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 43238] New: Bulk Purchase Suggestion Upload
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43238 Bug ID: 43238 Summary: Bulk Purchase Suggestion Upload Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, purchase suggestions in Koha can only be added individually through the OPAC or staff interface. Libraries often receive acquisition requests in bulk from faculty members, departments, or students in CSV or Excel format. Entering these suggestions manually is time-consuming and prone to errors. It would be beneficial to add a Bulk Purchase Suggestion Upload feature under the Acquisitions module. Proposed functionality 1. Add a new tool under Acquisitions (or Tools) named Bulk Purchase Suggestion Upload. 2. Allow librarians to upload purchase suggestions using CSV, Excel (.xlsx), or MARC files. 3. Provide a downloadable sample template. 4. Allow mapping of file columns to Koha suggestion fields. 5. Validate mandatory fields before import. 6. Display a preview of records before confirming the upload. 7. Generate an import summary showing: a. Total records processed b. Successfully imported suggestions c. Failed records d. Duplicate records Optionally detect duplicate suggestions based on ISBN, Title -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43020] New: One bad record can abort an entire OAI-PMH harvest
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43020 Bug ID: 43020 Summary: One bad record can abort an entire OAI-PMH harvest Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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: --- Koha::OAI::Client::Harvester::processRecord has no error handling around MARC::Record->new_from_xml when decoding a harvested record's metadata, and no handling for Koha::Exceptions::Metadata::Invalid around the subsequent AddBiblio/ModBiblio/AddAuthority/ModAuthority calls either. Since init()'s harvest loop has no try/catch around processRecord, either failure dies uncaught, aborting the entire harvest_oai.pl cron run partway through - no completion log entry, no report email, and every remaining record in that batch is left unprocessed. This was found while auditing other places in the codebase that ingest externally-sourced MARC data, prompted by bug 35104 (which fixed the same class of problem - one bad record silently aborting a whole batch/job - in the staged MARC import commit/revert code paths). Test plan: 1. Configure an OAI-PMH server under Administration > OAI-PMH harvesting servers, with a record type of biblio. 2. Arrange for one harvested record to have metadata that cannot be decoded as MARCXML (e.g. an empty <datafield> element, or any malformed MARC). 3. Run: misc/cronjobs/harvest_oai.pl -r <server id> 4. Before this patch: the cron job dies partway through, with no harvest report and no indication of which record caused it. 5. After this patch: the harvest completes. The bad record is counted as in_error in the harvest report/email, its identifier and decoding error are logged, and every other record in the batch is still processed normally. 6. prove t/db_dependent/Koha/OAIHarvester.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 7

[Bug 40164] New: Add Template::Plugin::JSON to handle JSON in Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40164 Bug ID: 40164 Summary: Add Template::Plugin::JSON to handle JSON in Template Toolkit Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: tomascohen(a)gmail.com Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Prior to Bug 39184, some libraries have been using PERL in their notices to parse JSON data. With PERL disallowed in notices, we need a way to handle JSON using Template Toolkit. https://metacpan.org/pod/Template::Plugin::JSON -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 39504] New: Batch record modification 'doesn't exist' condition not checking every matching tag
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39504 Bug ID: 39504 Summary: Batch record modification 'doesn't exist' condition not checking every matching tag Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org I feel like this MARC modification template isn't behaving as I expect it to. I have a biblio record with the following MARC: 700 $a John Smith $e Editor 700 $a Sally Smith I want a template that will add a value in 700$e if 700$e doesn't exist. My MARC modification template action looks like: - Add new field 700$e with value test if 700$e does not exist It doesn't work, probably because the earlier 700 tag does have the $e subfield, so the condition is false and it moves on. I've tried with other variations for the template action, for example - Add new field 700$e with value test2 if 700$e does not match RegEx m/(.*)/ Still doesn't apply, and I think it should be normal to expect that the MARC modification template will look at all 700 tags to apply this action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 38712] New: Order My Lists options alphabetically
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38712 Bug ID: 38712 Summary: Order My Lists options alphabetically Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: chloe.zermatten(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In the top header navigation menu on the Koha OPAC, sets the order of the 'My Lists' dropdown to be sorted alphabetically instead of by modification date. -- You are receiving this mail because: You are watching all bug changes.

1 30