https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37477 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37477 [Bug 37477] Add option to override warm-up/cool-down periods on bookings at booking time -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 194462 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194462&action=edit Bug 41514: Enforce lead/trail periods server-side in booking API Previously, lead and trail period validation for bookings was only enforced in the UI (place_booking.js), allowing third-party API consumers to create bookings that violated the configured buffer zones. This patch adds server-side enforcement in the two check_booking() methods and the Booking->store() call: - Koha::Item::check_booking(): accepts an optional branchcode param, fetches bookings_lead_period and bookings_trail_period circ rules for the item's effective itemtype, expands the overlap query so that effective periods (core ± lead/trail) are checked rather than just core date ranges. Also expands the checkout-due-date check so that items must be returned at least lead_days before the booking start. - Koha::Biblio::check_booking(): same expansion using the global (itemtype-agnostic) rule as an approximation for biblios that have items of mixed types. The item-level check provides the definitive per-item validation. - Koha::Booking::store(): passes pickup_library_id as branchcode to both check_booking() calls so that branch-specific rules are used. Tests added to t/db_dependent/Koha/Booking.t covering: - booking ending in existing booking's lead period → clash - booking ending before effective period → OK - booking starting in existing booking's trail period → clash - new booking's lead period overlapping existing trail period → clash - booking starting after full effective period ends → OK - checkout due within lead period → clash - checkout due before lead period → OK -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194462|0 |1 is obsolete| | --- Comment #2 from David Nind <david@davidnind.com> --- Created attachment 194476 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194476&action=edit Bug 41514: Enforce lead/trail periods server-side in booking API Previously, lead and trail period validation for bookings was only enforced in the UI (place_booking.js), allowing third-party API consumers to create bookings that violated the configured buffer zones. This patch adds server-side enforcement in the two check_booking() methods and the Booking->store() call: - Koha::Item::check_booking(): accepts an optional branchcode param, fetches bookings_lead_period and bookings_trail_period circ rules for the item's effective itemtype, expands the overlap query so that effective periods (core ± lead/trail) are checked rather than just core date ranges. Also expands the checkout-due-date check so that items must be returned at least lead_days before the booking start. - Koha::Biblio::check_booking(): same expansion using the global (itemtype-agnostic) rule as an approximation for biblios that have items of mixed types. The item-level check provides the definitive per-item validation. - Koha::Booking::store(): passes pickup_library_id as branchcode to both check_booking() calls so that branch-specific rules are used. Tests added to t/db_dependent/Koha/Booking.t covering: - booking ending in existing booking's lead period → clash - booking ending before effective period → OK - booking starting in existing booking's trail period → clash - new booking's lead period overlapping existing trail period → clash - booking starting after full effective period ends → OK - checkout due within lead period → clash - checkout due before lead period → OK Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |me@paulderscheid.xyz |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194476|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 --- Comment #5 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 204927 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204927&action=edit Bug 41514: (QA follow-up) Enforce lead/trail periods in item auto-assignment The "any item" path in Koha::Booking::store() excluded only items whose bookings overlapped the core date range, so a biblio-level booking could be stored on an item whose trail period it violates, while the same booking with an explicit item_id was rejected. _select_optimal_item() made this worse by preferring the just-vacated item. - Fetch bookings_trail_period alongside bookings_lead_period in _assign_item_for_booking() - Expand the existing bookings query by lead + trail on both sides, matching the check_booking() overlap condition This makes three copies of the rule lookup and expanded overlap query; the next follow-up consolidates them. Test plan: 1. Set bookings_lead_period=3 and bookings_trail_period=2 for a branch and itemtype 2. Create a biblio with two bookable items X and Y of that itemtype; book X for today+5..today+10 and Y for today+40..today+45 3. Via the REST API, POST a booking for that biblio without item_id for today+12..today+14 => Without this patch it is stored and assigned to X, inside X's trail period => With this patch it is assigned to Y; a second identical request is rejected with a clash 4. prove t/db_dependent/Koha/Booking.t Assisted-by: Fable 5.1 (Anthropic) Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Bug 41514 depends on bug 37707, which changed state. Bug 37707 Summary: Lead/Trail times should work in combination https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #204926|0 |1 is obsolete| | Attachment #204927|0 |1 is obsolete| | Attachment #204928|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 204953 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204953&action=edit Bug 41514: (QA follow-up) Enforce lead/trail periods in item auto-assignment The "any item" path in Koha::Booking::store() excluded only items whose bookings overlapped the core date range, so a biblio-level booking could be stored on an item whose trail period it violates, while the same booking with an explicit item_id was rejected. _select_optimal_item() made this worse by preferring the just-vacated item. - Fetch bookings_trail_period alongside bookings_lead_period in _assign_item_for_booking() - Expand the existing bookings query by lead + trail on both sides, matching the check_booking() overlap condition This makes three copies of the rule lookup and expanded overlap query; the next follow-up consolidates them. Test plan: 1. Set bookings_lead_period=3 and bookings_trail_period=2 for a branch and itemtype 2. Create a biblio with two bookable items X and Y of that itemtype; book X for today+5..today+10 and Y for today+40..today+45 3. Via the REST API, POST a booking for that biblio without item_id for today+12..today+14 => Without this patch it is stored and assigned to X, inside X's trail period => With this patch it is assigned to Y; a second identical request is rejected with a clash 4. prove t/db_dependent/Koha/Booking.t Assisted-by: Fable 5.1 (Anthropic) Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41514 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 204955 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204955&action=edit Bug 41514: (QA follow-up) Use the itemtype_id filter for auto-assignment's lead/trail rule lookup _assign_item_for_booking() always looked up the bookings_lead_period / bookings_trail_period rule using the biblio's default itemtype (biblioitem.itemtype), even when the caller requested an "any item of itemtype X" booking via set_itemtype_filter() (wired up from the REST API's itemtype_id parameter). On a biblio with mixed item-level itemtypes that have different lead/ trail rules, this meant an item could be auto-assigned to a booking that actually violates its own itemtype's configured buffer period, because the exclusion query used the wrong itemtype's rule while the item search correctly used the filter for candidate selection. Use the itemtype filter for the rule lookup when it is set, falling back to the biblio's default itemtype otherwise. Test plan: 1. prove t/db_dependent/Koha/Booking.t Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.