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

[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

[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 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 42590] New: bundle_items_not_lost+count is not sortable on the API
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42590 Bug ID: 42590 Summary: bundle_items_not_lost+count is not sortable on the API 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 Depends on: 41950 The bundle_items_not_lost+count embed on the biblio items endpoint cannot be sorted because the bundle_items_not_lost DBIC relationship does not exist on the Item result class. Same approach as bundle_items_lost+count (bug 42589) but filtering on itemlost = 0. The generated subquery would be: (SELECT COUNT(*) FROM items WHERE items.itemnumber IN (SELECT item FROM item_bundles WHERE host = me.itemnumber) AND items.itemlost = 0) Performance note: Same correlated IN subquery concern as bundle_items_lost+count. The trade-off should be evaluated. Test plan: prove t/Koha/REST/Plugin/Query.t t/db_dependent/api/v1/biblios.t t/db_dependent/Koha/Item.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42589] New: bundle_items_lost+count is not sortable on the API
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42589 Bug ID: 42589 Summary: bundle_items_lost+count is not sortable on the API 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 Depends on: 41950 The bundle_items_lost+count embed on the biblio items endpoint cannot be sorted because the bundle_items_lost DBIC relationship does not exist on the Item result class. The Koha::Item->bundle_items_lost method currently uses a many_to_many accessor with a Perl-side filter (itemlost != 0). To make it sortable, we need: 1. A DBIC coderef relationship on Item pointing to Koha::Schema::Result::Item with an -in subquery through the item_bundles bridge table and a filter on itemlost != 0 2. Support for -in with scalar ref (literal SQL) in _build_count_subquery 3. Update Koha::Item->bundle_items_lost to delegate to the DBIC relationship 4. Unit tests proving the sort works The generated subquery would be: (SELECT COUNT(*) FROM items WHERE items.itemnumber IN (SELECT item FROM item_bundles WHERE host = me.itemnumber) AND items.itemlost != 0) Performance note: This uses a correlated IN subquery. For large catalogs with many bundles, this could be slow. An alternative would be a JOIN-based COUNT, but that requires more complex changes to _build_count_subquery. The trade-off should be evaluated. Test plan: prove t/Koha/REST/Plugin/Query.t t/db_dependent/api/v1/biblios.t t/db_dependent/Koha/Item.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 40932] New: Automated trigger for invoice closure
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40932 Bug ID: 40932 Summary: Automated trigger for invoice closure Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org We would like to see the ability to set a trigger for a series of actions that would close an invoice automatically without us manually going into the invoice and ticking close and saving. We want to see a workflow whereby once all items associated to an invoice, when they are all returned for the first time this would trigger a cron job to close the invoice. This would help us to automate our acquisitions checking processes. Currently a staff member has to run a report and check in with staff to make sure they have returned items and then they spend a considerable time checking through for each invoice to make sure items have been physically received and then closing the invoice. If we can automate this last step so that when all items are checked in for the first time, the invoice will automatically close. It would also be useful to have this automatic action as a cron job so that if something goes wrong we could interrupt the next run and correct. Also, the ability to reopen the invoice is also the other failsafe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 41557] New: LoginFirstname, LoginSurname and emailaddress sent to template but never used
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41557 Bug ID: 41557 Summary: LoginFirstname, LoginSurname and emailaddress sent to template but never used 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: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bel Inconnu is actually no longer used 488 LoginFirstname => ( C4::Context->userenv ? C4::Context->userenv->{"firstname"} : "Bel" ), 489 LoginSurname => C4::Context->userenv ? C4::Context->userenv->{"surname"} : "Inconnu", 490 emailaddress => C4::Context->userenv ? C4::Context->userenv->{"emailaddress"} : undef, -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 35423] New: AuthoritiesMarc: Warnings substr outside of string and Use of uninitialized value $type in string eq
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35423 Bug ID: 35423 Summary: AuthoritiesMarc: Warnings substr outside of string and Use of uninitialized value $type in string eq Change sponsored?: --- Product: Koha Version: master 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 In full: substr outside of string at /usr/share/koha/C4/AuthoritiesMarc.pm line 1041. Use of uninitialized value $type in string eq at /usr/share/koha/C4/AuthoritiesMarc.pm line 1044. May be found in your logs (depending on data) when calling SearchAuthorities. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 42647] New: Search by patron attribute using "starts with" fails if attribute value has a space
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42647 Bug ID: 42647 Summary: Search by patron attribute using "starts with" fails if attribute value has a space Initiative type: --- Sponsorship --- status: 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The patron search by attribute fails if the attribute value contains a space. This is specific to a "Starts with" search which is the default in patron searches. If you switch to "contains" the patron attribute search works correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 40619] New: Remove OverDrive star ratings from OPAC JS
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40619 Bug ID: 40619 Summary: Remove OverDrive star ratings from OPAC JS Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org OverDrive no longer supplies star ratings via their API: https://developer.overdrive.com/blog/16-may-2025-coming-soon-adding-content… We can remove the code in opac-overdrive-search.tt which used to show those star ratings. -- You are receiving this mail because: You are watching all bug changes.

1 15