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

[Bug 42881] New: Improve Elasticsearch Indexing performance
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42881 Bug ID: 42881 Summary: Improve Elasticsearch Indexing performance Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- An epic bug to collect elasticsearch (re)indexing performance improvements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 43123] New: Hold placement workflow: Vue modernisation (epic)
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43123 Bug ID: 43123 Summary: Hold placement workflow: Vue modernisation (epic) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- This is a tracking bug for a project to replace the staff interface hold placement workflow (reserve/request.pl, reserve/request.tt, js/holds.js) with a set of REST API endpoints and a Vue 3 single page application, addressing severe performance problems in the current implementation. Problem reserve/request.pl (roughly 820 lines) pre-computes holdability for every item on a record, across every policy dimension, in a single synchronous request, then renders the results through a 1600 line Template Toolkit page with jQuery interactivity (js/holds.js, roughly 1300 lines). For a 100 item biblio this produces on the order of 1800 to 2700 SQL queries in a single page load. Confirmed cost centres include: - The same item set is fetched independently by CanBookBeReserved, GetMaxPatronHoldsForRecord, request.pl's own item loop, and (when onshelfholds=2) ItemsAnyAvailableAndNotRestricted. - FixPriority (C4::Reserves) issues one UPDATE per queued hold on every create, cancel or fill. A title with 50 queued holds means 50 UPDATE statements per state change. - Club holds check each enrolled patron's hold count and balance individually, with no batching. - Pickup location computation (Koha::Biblio::pickup_locations) iterates every item and resolves branch and transfer limit rules per item. Some mitigation already exists (CanItemBeReserved and get_effective_rule_value now cache via Koha::Cache::Memory::Lite, and Koha::Biblio::pickup_locations has a per-item-shape cache), but these reduce repeat lookups within a request rather than changing the underlying O(N) shape of the computation. Proposed direction - New availability classes, Koha::Item::Availability::Hold and Koha::Biblio::Availability::Hold, load context for a (patron, biblio) pair once, then evaluate holdability for every item from memory. These follow the pattern already established by bug 41728 (Koha::Item::Availability::Checkin) and its shared Koha::Result::Availability base class, rather than inventing a bespoke schema. - Patron level pre-flight eligibility reuses the existing Koha::Patron->can_place_holds method (already in main), exposed via a new GET endpoint rather than new backend logic. - New REST endpoints expose holdability at the biblio, item, batch and patron level, so the UI asks only for what the current screen needs instead of pre-computing everything up front. - A new Vue 3 single page application replaces reserve/request.tt and js/holds.js, following the existing ERM / Preservation / Acquisitions module pattern, gated behind a new UseNewHoldsInterface system preference (default off) until feature parity is confirmed. - reserve/request.pl remains the default and fully functional throughout the migration. - Separately, Koha's Circulation Holds queue picking list report (circ/view_holdsqueue.pl) is being made API driven by bug 42503. That bug is not a Vue conversion. Once it lands, this epic includes a small follow on to render that page with Vue against the endpoint it introduces, without duplicating its REST work. This bug tracks the overall initiative. Individual patches are delivered against the bugs it depends on, listed below, each independently testable and each landing without changing default behaviour until the bug that flips the feature flag. This bug is not expected to carry a patch itself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 42509] New: Use API to retrieve and update patrons via Batch patron deletion and anonymization tool
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42509 Bug ID: 42509 Summary: Use API to retrieve and update patrons via Batch patron deletion and anonymization tool Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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 The Batch patron deletion and anonymization tool (cleanborrowers.pl) can be slow for larger systems. It should be updated to use the API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 41903] New: Overdues reports in circulation module are too resource intensive
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41903 Bug ID: 41903 Summary: Overdues reports in circulation module are too resource intensive Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The circ module includes reports "Overdues" and "Overdues with fines." Both are sufficiently resources intensive as to cause noticeable slowdowns on large systems when used during business hours. They should be rewritten using APIs and VUE to improve performance. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 112

[Bug 42444] New: Update waitingreserves.pl to use API to fetch data
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42444 Bug ID: 42444 Summary: Update waitingreserves.pl to use API to fetch data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The Holds Awaiting Pickup page is a pain point for larger systems with many holds. We should update how it fetches, displays, and interacts with data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 86

[Bug 42443] New: Update transferstoreceive.pl to use the API to fetch transfer information
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42443 Bug ID: 42443 Summary: Update transferstoreceive.pl to use the API to fetch transfer information Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The Transfers to Receive page is a pain point for larger systems with many transfers. We should update it to fetch data via API. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 43016] New: [OMNIBUS] Server resource protection
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43016 Bug ID: 43016 Summary: [OMNIBUS] Server resource protection Initiative type: Meta Sponsorship --- status: 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34632, 39164, 40896, 40898, 41040, 41048, 41918, 41919, 41920, 41921, 42108, 42373, 42404, 42405, 42585, 42593 Target Milestone: --- An omnibus of enhancements meant to prevent user actions that can create an undue strain on server resources. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34632 [Bug 34632] Patron Importing should be a background job https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39164 [Bug 39164] Add max_statement_time to SQL report queries https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40896 [Bug 40896] Run report button should be disabled after click https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40898 [Bug 40898] Add ability to limit the number of columns a patron search api request can sort by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41040 [Bug 41040] Empty patron search from the header should not trigger a patron search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41048 [Bug 41048] Add ability to disallow empty patron searches https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41918 [Bug 41918] Prevent users from running the same report multiple times concurrently https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41919 [Bug 41919] Limit number of current reports a single user can run simultaneously https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41920 [Bug 41920] Limit number of concurrent reports that can be run simultaneously for an instance of Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41921 [Bug 41921] Add ability to run reports as background jobs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 [Bug 42108] Add ability to specify that a report can only be run as a foreground or background report https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42373 [Bug 42373] Add ability to disallow unbounded patron API searches https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42404 [Bug 42404] Add a batch cover images upload endpoint https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42405 [Bug 42405] Add single cover image upload path https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42585 [Bug 42585] Add ability for Koha to analyze reports and warn for potentially dangerous reports https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42593 [Bug 42593] Add ability for background reports ( and saved reports ) output to be stored on the filesystem instead of the database -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42404] New: Add a batch cover images upload endpoint
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42404 Bug ID: 42404 Summary: Add a batch cover images upload endpoint 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63

[Bug 41852] New: Modernize EDI support in Koha
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41852 Bug ID: 41852 Summary: Modernize EDI support in Koha Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org A collector bug for all the modernization and maintenance work we've been undertaking in EDIfact support for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43291] New: SIP2 responses hardcode currency to USD regardless of library configuration
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43291 Bug ID: 43291 Summary: SIP2 responses hardcode currency to USD regardless of library configuration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- C4::SIP::ILS::Transaction's sip_currency field (used for FID_CURRENCY in patron status and fee-related SIP2 responses) is hardcoded to 'USD' with a "FIXME: why hardcoded?" comment, regardless of the library's actual currency. Any library using a self-check/SIP2 integration outside the US gets an incorrect currency code in every fee-related SIP2 response. This patch uses Koha::Acquisition::Currencies->get_active's isocode when one is configured, falling back to 'USD' (the previous, and still sensible default, behaviour) when no active currency exists. Every C4::SIP::ILS::Transaction subclass calls SUPER::new() first and none of them override sip_currency in their own %fields, so this applies uniformly across checkout, checkin, renew, hold, and fee payment SIP responses. Test plan: 1. prove t/db_dependent/SIP/Transaction.t 2. With no active currency configured, confirm a SIP2 patron status response still reports USD (AY field / currency) 3. Mark a currency (e.g. GBP) as active in Administration > Currencies 4. Repeat step 2 and confirm the response now reports GBP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7