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@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@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.