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

[Bug 41739] New: Improve the authority merge warning
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41739 Bug ID: 41739 Summary: Improve the authority merge warning Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 192261 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192261&action=e… Authority merge warning Bug 25387 introduced a warning when attempting to merge different authority types. The message is below the comparison boxes in yellow. The warning is not a strong enough visual cue to warn the user. It would be helpful to move the warning above the comparison boxes and change the warning to red text in bold or something much visually stronger. It also might be worth considering blocking the ability to merge different authorities types since proceeding with the merge results in data loss. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 17485] New: Add Marc modification templates to z39.50 import
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17485 Bug ID: 17485 Summary: Add Marc modification templates to z39.50 import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, It would be great to have possibility using marc modification templates on Z39.50 search. Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 38368] New: Background jobs: Batch item record deletion to list failed/succeeded items
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38368 Bug ID: 38368 Summary: Background jobs: Batch item record deletion to list failed/succeeded items Change sponsored?: --- 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: hanna.ikonen(a)sivistys.mikkeli.fi QA Contact: testopia(a)bugs.koha-community.org Currently background jobs do not list on visible record the items which have been handled. This causes issues especially when the background job fails, for example in batch item record deletion. Trying to solve which items have been worked with, you need to use several different reports. That means a lot of work hours, especially if, for example, the failed background job contains a lot of deleted items. My proposition is, that the background job -list would show which items were handled in the background whether it has failed or not. It would also be helpful if it showed information why it has failed/which item has caused the failure. It would standardize the information/notification system with the other batch processing jobs which list the things that have been worked on. To test: 1. Go to Administration and click Manage Jobs. 2. Select Status as "Failed" and Type "Batch item record deletion". 3. Open a failed background job. 4. Report only lists the job as failed, while "Detailed messages" is empty”. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39637] New: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39637 Bug ID: 39637 Summary: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Continuation of bug 31104 which did not solve the problem completely. Steps to reproduce: 1. Log in to staff interface 2. In the top search bar, select "Patrons search" and type "a b c d e f g h i j k l m" and submit the form 3. The patrons table should fail to load with a message like this: "Something went wrong when loading the table. 414: Request-URI Too Long.". If the table loads successfully, try adding a few more letters (separated by space) to the search. Another error that can happen is a 5XX error caused by the length of Link headers. Here is the (decoded) URL generated for "a b c d e": http://koha-dev-main/api/v1/patrons?_page=1&_per_page=20&q=[{"-and":[[{"me.firstname":{"like":"a%"}},{"me.preferred_name":{"like":"a%"}},{"me.middle_name":{"like":"a%"}},{"me.surname":{"like":"a%"}},{"me.othernames":{"like":"a%"}},{"me.cardnumber":{"like":"a%"}},{"me.userid":{"like":"a%"}}],[{"me.firstname":{"like":"b%"}},{"me.preferred_name":{"like":"b%"}},{"me.middle_name":{"like":"b%"}},{"me.surname":{"like":"b%"}},{"me.othernames":{"like":"b%"}},{"me.cardnumber":{"like":"b%"}},{"me.userid":{"like":"b%"}}],[{"me.firstname":{"like":"c%"}},{"me.preferred_name":{"like":"c%"}},{"me.middle_name":{"like":"c%"}},{"me.surname":{"like":"c%"}},{"me.othernames":{"like":"c%"}},{"me.cardnumber":{"like":"c%"}},{"me.userid":{"like":"c%"}}],[{"me.firstname":{"like":"d%"}},{"me.preferred_name":{"like":"d%"}},{"me.middle_name":{"like":"d%"}},{"me.surname":{"like":"d%"}},{"me.othernames":{"like":"d%"}},{"me.cardnumber":{"like":"d%"}},{"me.userid":{"like":"d%"}}],[{"me.firstname":{"like":"e%"}},{"me.preferred_name":{"like":"e%"}},{"me.middle_name":{"like":"e%"}},{"me.surname":{"like":"e%"}},{"me.othernames":{"like":"e%"}},{"me.cardnumber":{"like":"e%"}},{"me.userid":{"like":"e%"}}]]},{"-or":[{"me.firstname":{"like":"a+b+c+d+e%"}},{"me.preferred_name":{"like":"a+b+c+d+e%"}},{"me.middle_name":{"like":"a+b+c+d+e%"}},{"me.surname":{"like":"a+b+c+d+e%"}},{"me.othernames":{"like":"a+b+c+d+e%"}},{"me.cardnumber":{"like":"a+b+c+d+e%"}},{"me.userid":{"like":"a+b+c+d+e%"}}]},{"-and":[[{"extended_attributes.value":{"like":"a%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"b%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"c%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"d%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"e%"},"extended_attributes.code":[["Nickname","PAT_1"]]}]]}]&_match=contains&_order_by=+me.surname,+me.preferred_name,+me.firstname,+me.middle_name,+me.othernames,+me.street_number,+me.address,+me.address2,+me.city,+me.state,+me.postal_code,+me.country (Ignore the extended_attributes.* params that are not the main issue here, even though they contribute to the problem) If I'm counting correctly, for each word searched, the URL length is increased by (216 + 7 * <word length>) characters (before encoding, which also increases the URI length by a lot). For me, with Apache, the problem happens around 8k characters (after encoding). IMO it would be better to send only parameters like 'search', 'search_type' and 'search_field' to the API and translate this to DBIC dialect on the backend. This would make it a lot harder to reach the limit (and would make the URI far more readable, which is always nice :)) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 17500] New: Use Elasticsearch to search for patrons
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17500 Bug ID: 17500 Summary: Use Elasticsearch to search for patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Adding and keeping up to date a new Elasticsearch index for patrons will allow us to use it to search for patrons. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 23873] New: Allow marc modification templates to use capturing groups in substitutions
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23873 Bug ID: 23873 Summary: Allow marc modification templates to use capturing groups in substitutions Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: - Find/create a bib record with a date formatted as YYYYMMDD - Create a marc modification template to Copy and Replace your field with this regex: s/(\d{4})(\d{2})(\d{2})/\1\-\2\-\3/ -- this should reformat your date as "YYYY-MM-DD" - Apply your template to your bib - Observe that the match worked, but the substitution failed -- the value "\1\-\2\-\3" is treated literally Apparently this fails due to some aspect of how regex works within perl? It'd be hugely useful if we could get it working. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 15836] New: Labels: Offer configuration option for splitting call number in layout definition
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15836 Bug ID: 15836 Summary: Labels: Offer configuration option for splitting call number in layout definition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in Germany and possibly other countries. A lot of our libraries use their own custom classification schemes so the call number splitting is something that should be individually configurable. One option would be using a regex expression, that can be set in the layout additional to the standard splitting offered by the checkbox. (see bug 2500 for some discussion about the splitting algorithms implemented atm) -- You are receiving this mail because: You are watching all bug changes.

1 132

[Bug 40589] New: Add table settings to recalls pages
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40589 Bug ID: 40589 Summary: Add table settings to recalls pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I propose to add table settings to these pages: - Recalls queue - Recalls to pull - Overdue recalls - Recalls awaiting pickup - Old recalls -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 40567] New: Correct eslint errors in recalls.js
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40567 Bug ID: 40567 Summary: Correct eslint errors in recalls.js Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 23833 Following coding guideline JS8: "Follow guidelines set by ESLint," some errors should be corrected in recalls.js Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23833 [Bug 23833] [Omnibus] JavaScript should conform to coding guidelines recommended by ESLint -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 23833] New: [Omnibus] JavaScript should conform to coding guidelines recommended by ESLint
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23833 Bug ID: 23833 Summary: [Omnibus] JavaScript should conform to coding guidelines recommended by ESLint Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org An updated version of Bug 9284. ESLint can be used to check JavaScript for errors and potential problems. It can be installed on a variety of platforms and integrated into various editors: https://eslint.org/docs/user-guide/integrations This bug will serve as an omnibus for any bug devoted to ESLint-related cleanup. -- You are receiving this mail because: You are watching all bug changes.

1 14