https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43108 Bug ID: 43108 Summary: Add a REST API endpoint for a biblio's booking availability over a date range Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: paul.derscheid@lmscloud.de QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Target Milestone: --- Booking availability (which of a record's bookable items can be booked on which dates, given the lead/trail circulation rules, existing bookings, current checkouts, and the pickup library's closed days) is computed server-side as the single source of truth and exposed over REST. One implementation backs both display and enforcement so they cannot drift; the server returns a compact per-date map rather than making each consumer fetch and process all of a record's bookings and checkouts; and any consumer, whether the Vue booking modal (Bug 41129), another UI, or a third-party integration building its own booking flow, can query it without re-implementing the rules. GET /biblios/{biblio_id}/booking_availability ?from_date=YYYY-MM-DD&to_date=YYYY-MM-DD (required, inclusive, <= 366 days) [&pickup_library_id=...] [&patron_id=...] [&item_type_id=...] [&item_id=...] [&excluded_booking_id=...] (rule/context + edit-exclude) It returns the bookable item ids and a sparse per-(date, item) map. Each cell is an availability result: { "item_ids": [101, 102], "availability": { "2026-08-10": { "101": { "blockers": { "booking": 1 }, "confirms": {}, "warnings": {} }, "102": { "blockers": { "lead": 1 }, "confirms": {}, "warnings": { "holiday": 1 } } } } } - blockers prevent a new booking (booking, checkout, lead, trail); an item with no blockers on a date is bookable, so its available dates are the complement. - warnings are advisory display context only (holiday, lead_floor, lead_theoretical). - confirms is always empty for bookings but present so each cell is a complete availability result. The response shape follows the availability-class pattern currently being established: Bug 41728 (Koha::Result::Availability, to_hashref, where each cell is that shape); Bug 42386 (Koha::{Patron,Item,Biblio}::Availability::Hold, which sets the namespace and snake_case reasons; the class here is Koha::Biblio::Availability::Booking); Bug 42385 and Bug 42387. To stay more or less independent of that series, the class returns a plain hashref rather than subclassing the not-yet-merged Koha::Result::Availability; the shape is compatible, so switching to the real object later is a drop-in change. Booking and checkout day boundaries are attributed to the library timezone (consistent with Bug 42868), matching how bookings are stored and enforced. When item_id names a single item, its own effective item type governs the lead/trail rules (the type enforcement will use), overriding any item_type_id passed alongside it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.