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

[Bug 29473] New: Documentation tasks for 21.11
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29473 Bug ID: 29473 Summary: Documentation tasks for 21.11 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org We are now using Bugzilla to manage documentation tasks. This is a placeholder for reviewing all the bugs in 21.11 and determining which ones require documentation updates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 41024] New: Inconsistent spelling of Borrower(s)Logs
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41024 Bug ID: 41024 Summary: Inconsistent spelling of Borrower(s)Logs Change sponsored?: --- Product: Koha Version: Main 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 git grep BorrowerLogs git grep BorrowersLogs -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 32288] New: Capitalization: RDA Carrier, etc.
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32288 Bug ID: 32288 Summary: Capitalization: RDA Carrier, etc. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org RDA Carrier koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:17 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:19 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:17 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:19 ... RDA Content koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:23 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:25 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:23 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:25 ... RDA Media koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:29 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_181-2.tt:31 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:29 koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/unimarc_field_182-2.tt:31 ... -- You are receiving this mail because: You are watching all bug changes.

1 18

[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