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

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 34223] New: ILL status filter does not load immediately after selecting a backend filter
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34223 Bug ID: 34223 Summary: ILL status filter does not load immediately after selecting a backend filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com CC: pedro.amorim(a)ptfs-europe.com Selecting a backend filter in ILL is required in order for the status filter to become enabled. Once a provider is chosen in the backend filter, it takes the status filter around 7s to populate instead of populating immediately. This is confusing to staff members and can also disrupt the workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34058] New: ILL - Left filters not considering all terms in input
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34058 Bug ID: 34058 Summary: ILL - Left filters not considering all terms in input Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce, on k-t-d: 1) Run bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Create a FreeForm ILL request and input 23529000035676 in the cardnumber, that's "Henry Acevedo". 3) Go back to the ILL list table, input "henry" in the bottom "Patron" filter input and press the "Search" button, notice it fetches the request correctly. 4) Now do the the same search but with "henry acevedo", notice the request is not retrieved. The same issue also happens in the "keyword" filter input. Info: patron-search.inc is already doing what we need, but for patrons left side filters, it's handling all the patterns present in the #search_patron_filter input and adding each of those to the query, we need something similar here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 23988] New: When replace record with z39.50, give option on what gets pre-populated
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23988 Bug ID: 23988 Summary: When replace record with z39.50, give option on what gets pre-populated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently in Koha, when a user chooses to replace an existing record with another record using z39.50, Koha will prepopulate the z39.50 search with Title, Author and ISBN. This search is very constrictive and it would be nice to have the option of what fields get prepopulated instead of having to manually remove the fields that the user doesn't want. Specifically, an ISBN pre-population would be ideal for a library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 41572] New: Tidy kohaTable block - members
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41572 Bug ID: 41572 Summary: Tidy kohaTable block - members Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 41566] New: Tidy kohaTable block - catalogue
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41566 Bug ID: 41566 Summary: Tidy kohaTable block - catalogue Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 41560] New: Useless (and confusing) id attribute on a couple of script tag
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41560 Bug ID: 41560 Summary: Useless (and confusing) id attribute on a couple of script tag Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/issuehistory.tt koha-tmpl/intranet-tmpl/prog/en/modules/members/readingrec.tt have <script id="js"> That's not needed, useless, and confusing. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41950] New: Make +count embeds sortable by using SQL-level COUNT subqueries
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 Bug ID: 41950 Summary: Make +count embeds sortable by using SQL-level COUNT subqueries Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Currently, +count embeds (e.g., claims+count, checkouts+count) are computed in Perl via $object->$relation->count during to_api serialization. This means: 1. They cannot be used in _order_by — attempting to sort by a _count field (e.g., _order_by=-me.claims_count) causes a 500 error because DBIC cannot find the column in the database. 2. Each count triggers a separate SQL query per row (N+1 problem). This patch makes dbic_merge_prefetch detect +count embeds and, when a matching DBIC relationship exists, inject a correlated COUNT subquery via +select/+as instead of adding a prefetch. For example, claims+count on orders generates: sql (SELECT COUNT(*) FROM aqorders_claims WHERE aqorders_claims.ordernumber = me.ordernumber) AS claims_count The order_by entries referencing count aliases are fixed up to strip the me. prefix, since +as aliases are virtual columns not bound to a table. In to_api, the is_count handler now checks for the pre-computed column via get_column before falling back to the Perl-level ->count call. This preserves backward compatibility for Koha-level methods that don't have a corresponding DBIC relationship. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69

[Bug 41685] New: MARC21: Sort 4xx/5xx in BuildSummary alphabetic within hierarchy ($w: g or h)
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41685 Bug ID: 41685 Summary: MARC21: Sort 4xx/5xx in BuildSummary alphabetic within hierarchy ($w: g or h) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Currently, the list of seefrom/seealso is sorted in the order of the MARC fields. We would like to sort the Broader terms first and the Narrower terms last, with other terms in the middle. All groups should be sorted alphabetically on $a. This summary is mainly used in the authority search results on OPAC and intranet. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 41471] New: Deprecate IndependentBranches system preference in favor of library group enhancements
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41471 Bug ID: 41471 Summary: Deprecate IndependentBranches system preference in favor of library group enhancements Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I suggest to add a deprecation note to the system preference and maybe a coding guideline as well to start phasing out the IndependentBranches system preference in favor of pushing the development for library groups and related features instead. The IndependentBranches have a lot of known holes and problems, see bug 12599. I think if we can agree to start removing it, we could tackle the features it brings separately and improve them to be better, more flexible and more granular in configuration - not being an all or nothing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5