July 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 42591] New: current_item_level_holds+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=42591 Bug ID: 42591 Summary: current_item_level_holds+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 current_item_level_holds+count embed on the acquisitions orders endpoint cannot be sorted because the underlying query is too complex for a single DBIC relationship. Koha::Acquisition::Order->current_item_level_holds requires: 1. Getting item numbers from aqorders_items for the order 2. Getting the biblio for the order 3. Querying holds on that biblio filtered by reservedate <= NOW() + ConfirmFutureHolds AND itemnumber IN (those items) This involves a syspref-dependent date calculation and a multi-table correlation that cannot be expressed as a DBIC relationship coderef. A possible approach would be a raw SQL subquery override mechanism in _build_count_subquery, or accepting that this embed remains display-only (not sortable). Test plan: prove t/db_dependent/api/v1/acquisitions_orders.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 43042] 500 error when receiving an order in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43042 Bug 43042 depends on bug 41950, which changed state. Bug 41950 Summary: Make +count embeds sortable by using SQL-level COUNT subqueries https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 Kyle M Hall (khall) <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle(a)bywatersolutions.com, | |nick(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 43042] 500 error when receiving an order in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43042 --- Comment #1 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- git bisect blames Bug 41950 and when I revert that patchset, no 500 error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43048] Prevent users from completely removing fields from cataloging frameworks that break Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43048 Phil Ringnalda <phil(a)chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil(a)chetcolibrary.org See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42948 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42565] New: GetIssuingCharges returns undef when rentalcharge is NULL
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42565 Bug ID: 42565 Summary: GetIssuingCharges returns undef when rentalcharge is NULL Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com GetIssuingCharges initializes $charge = 0 but then overwrites it with the raw value from itemtypes.rentalcharge. When no rental charge is configured (NULL in the database, which is the default), the function returns undef instead of 0. This causes 'Use of uninitialized value' warnings in every caller that does $charge > 0, notably during automatic renewals (cron), SIP checkout/renew, and the OPAC user page. The fix is trivial: normalize NULL to 0 at the assignment point in GetIssuingCharges. All callers already treat the return as numeric and only act on positive values, so this is safe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13