[Bug 42997] New: Keep booking end dates in sync with checkout due dates at issue and renewal
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Bug ID: 42997 Summary: Keep booking end dates in sync with checkout due dates at issue and renewal 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: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Target Milestone: --- Depends on bug 41898 (booking status lifecycle). With the 'issued' booking status in place, the booking and its linked checkout can drift apart whenever the due date differs from the booking end date - at issue time (staff due date overrides) and at renewal. This patchset makes the checkout due date authoritative and keeps the booking in step with it: - AddIssue syncs any due date override back to booking.end_date the moment the booking transitions to 'issued'; if the override would clash with a subsequent booking the checkout proceeds with the booking's original end date - CanBookBeIssued raises a new BOOKED_DUE_DATE_CLASH confirmation on the checkout screen when an explicitly requested due date runs into the next booking for the item, so staff are warned before continuing - circulation.pl now honours an explicit due date override for booked items instead of silently clamping it to the booking end date - CanBookBeRenewed no longer allows a renewal to run straight through the start of the next booking: the patron's own booking previously hid subsequent bookings from the clash lookup. Requested due dates (checkouts screen renewal date, circ/renew.pl hard due date) are now validated against bookings too - AddRenewal pulls the linked booking's end_date along with the renewed due date, mirroring the AddIssue behaviour Test plan: 1. Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2. Create two consecutive bookings on one item for two patrons; check the item out to the first patron with a due date beyond the second booking's start; confirm the warning appears and, on confirming, the checkout uses the requested date whilst the booking keeps its original end date 3. Check out a booked item with a non-clashing due date override and confirm the booking end date follows it 4. Renew a booked checkout and confirm the booking end date follows the new due date; attempt to renew past the next booking's start and confirm the renewal is refused -- 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=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |41898 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41898 [Bug 41898] Expired bookings do not display when expired filter is used in patron record -- 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=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42998 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42998 [Bug 42998] Allow a requested due date when renewing a checkout via the REST API -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- 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=42997 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=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|--- |Unsponsored Status|ASSIGNED |Needs Signoff Patch complexity|--- |Medium patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201542&action=edit Bug 42997: Sync booking end_date with due date override at checkout When a booked item is checked out, the due date defaults to the booking end_date. Staff may override the due date at checkout time, which previously left the booking end_date out of sync with the checkout, blocking the booked period for longer or shorter than the actual loan. This patch updates C4::Circulation::AddIssue to sync any due date override back to booking.end_date the moment the booking transitions to 'issued', keeping the booking and the checkout aligned from the point of issue. The existing Koha::Booking->store clash detection is used to guard the update: if the overridden due date would clash with a subsequent booking for the same item, the checkout proceeds with the booking's original end_date instead. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddIssue | booking end_date sync with due date override' subtest passes 2) Create a booking for a patron on a specific item 3) Check the item out to the patron, overriding the suggested due date 4) Confirm the booking's end_date now matches the overridden due date -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201543 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201543&action=edit Bug 42997: Don't let a booking's own checkout block it in check_booking Koha::Item->check_booking refuses any booking period that starts before the item's current checkout is due back. That is correct when assessing a new booking against someone else's loan, but it also fired when the checkout in question is the booking's own linked loan - making it impossible to ever move an issued booking's end_date, as any update would 'clash' with its own checkout. This patch skips the checkout guard when the checkout's booking_id matches the booking_id passed for exclusion, i.e. when the checkout belongs to the very booking being updated. This is a prerequisite for keeping booking end dates in sync with checkout due dates in this patchset, and for the booking extension pathway on bug 42790. Test plan: 1) Run t/db_dependent/Koha/Item.t and confirm the check_booking subtest passes, including the two new checkout-related tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201544 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201544&action=edit Bug 42997: Warn staff when a due date override runs into the next booking When checking out a booked item, staff may override the suggested due date. If that override runs into the next booking for the item, the previous patch would silently keep the booking's original end date - staff had no way of knowing their override crossed another booking. This patch adds an exclude_booking_id option to Koha::Item->find_booking so a lookup can skip a specific booking (here: the patron's own booking being collected), and uses it in CanBookBeIssued to detect when an explicitly requested due date would run into the next booking for the item. When it would, a new BOOKED_DUE_DATE_CLASH confirmation is raised and displayed on the checkout screen, telling staff the linked booking will keep its original end date if they continue. Only explicitly requested due dates trigger the confirmation - calculated due dates are clamped to the booking end date later in the staff checkout flow, so checking them would produce false positives. SIP is unaffected as it never passes a requested due date. Test plan: 1) Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2) Create two consecutive bookings on the same item for two patrons 3) Check the item out to the first patron specifying a due date beyond the second booking's start date; confirm the new confirmation message appears and checkout only proceeds once confirmed -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201545 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201545&action=edit Bug 42997: Prevent renewals running into the next booking CanBookBeRenewed checked bookings by asking Koha::Item->find_booking for the first booking that clashes with the renewal period. When the renewing patron's own booking satisfies this checkout, that booking is returned first and renewal is allowed - subsequent bookings for the item were never considered. A patron could therefore renew a booked item straight through the start of the next patron's booking. Additionally, when staff renew with an explicit due date (the renewal due date input on the checkouts screen, or the hard due date on circ/renew.pl), CanBookBeRenewed validated a *calculated* due date whilst AddRenewal then applied the *requested* one, so the requested date was never checked against bookings at all. This patch: * repeats the booking lookup with the patron's own booking excluded, refusing the renewal ('booked') when it would run into the next booking for the item * adds an optional $date_due parameter to CanBookBeRenewed, used in place of the calculated due date for the bookings check, and threads the requested date through from svc/renew and circ/renew.pl Test plan: 1) Run t/db_dependent/Circulation.t - the extended 'CanBookBeRenewed | bookings' subtest covers both the calculated and requested due date cases 2) Check out a booked item to its patron, add a subsequent booking for another patron, and attempt to renew past the second booking's start date from the checkouts screen; confirm the renewal is refused as 'booked' -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201546 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201546&action=edit Bug 42997: Sync booking end_date with the due date at renewal When a checkout satisfying a booking is renewed, the booking previously kept its original end_date, blocking the booked period from other patrons for the wrong window and leaving the two records out of sync. This patch updates C4::Circulation::AddRenewal to pull the linked booking's end_date along with the renewed due date, mirroring the behaviour introduced for AddIssue earlier in this patchset. As at issue time, if the new due date would clash with a subsequent booking (possible when the renewal was explicitly allowed past a clash), the booking keeps its original end_date. Together with the previous patch this makes a renewal the natural way to extend an issued booking: CanBookBeRenewed refuses renewals that would run into the next booking, and AddRenewal keeps the booking in step with the loan. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddRenewal | booking end_date sync' subtest passes 2) Check out a booked item, renew it from the checkouts screen and confirm the booking end date follows the new due date -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201547 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201547&action=edit Bug 42997: Honour explicit due date overrides for booked items at checkout When checking out a booked item, circulation.pl unconditionally replaced the due date with the booking end date, silently discarding any due date staff had explicitly specified - even after they had just confirmed the BOOKED_DUE_DATE_CLASH warning saying they wanted it. The booking end date remains the default when no due date is specified; an explicit override (with SpecifyDueDate enabled) is now passed through to AddIssue, which syncs the booking end_date with it where possible and keeps the original end date when the override would clash with a subsequent booking (as warned). Test plan: 1) Create a booking and check the item out without specifying a due date; confirm the due date defaults to the booking end date 2) Return the item, book it again, and check out specifying an explicit due date; confirm the checkout uses that date and the booking end date follows it -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Comma delimited| |OpenFifth list of Sponsors| |<https://openfifth.co.uk/\> | |, Westminster City Council | |<https://www.westminster.go | |v.uk/\> Sponsorship status|Unsponsored |Sponsored -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201542|0 |1 is obsolete| | Attachment #201543|0 |1 is obsolete| | Attachment #201544|0 |1 is obsolete| | Attachment #201545|0 |1 is obsolete| | Attachment #201546|0 |1 is obsolete| | Attachment #201547|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=42997 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202365 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202365&action=edit Bug 42997: Sync booking end_date with due date override at checkout When a booked item is checked out, the due date defaults to the booking end_date. Staff may override the due date at checkout time, which previously left the booking end_date out of sync with the checkout, blocking the booked period for longer or shorter than the actual loan. This patch updates C4::Circulation::AddIssue to sync any due date override back to booking.end_date the moment the booking transitions to 'issued', keeping the booking and the checkout aligned from the point of issue. The existing Koha::Booking->store clash detection is used to guard the update: if the overridden due date would clash with a subsequent booking for the same item, the checkout proceeds with the booking's original end_date instead. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddIssue | booking end_date sync with due date override' subtest passes 2) Create a booking for a patron on a specific item 3) Check the item out to the patron, overriding the suggested due date 4) Confirm the booking's end_date now matches the overridden due date Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202366 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202366&action=edit Bug 42997: Don't let a booking's own checkout block it in check_booking Koha::Item->check_booking refuses any booking period that starts before the item's current checkout is due back. That is correct when assessing a new booking against someone else's loan, but it also fired when the checkout in question is the booking's own linked loan - making it impossible to ever move an issued booking's end_date, as any update would 'clash' with its own checkout. This patch skips the checkout guard when the checkout's booking_id matches the booking_id passed for exclusion, i.e. when the checkout belongs to the very booking being updated. This is a prerequisite for keeping booking end dates in sync with checkout due dates in this patchset, and for the booking extension pathway on bug 42790. Test plan: 1) Run t/db_dependent/Koha/Item.t and confirm the check_booking subtest passes, including the two new checkout-related tests Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202367 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202367&action=edit Bug 42997: Warn staff when a due date override runs into the next booking When checking out a booked item, staff may override the suggested due date. If that override runs into the next booking for the item, the previous patch would silently keep the booking's original end date - staff had no way of knowing their override crossed another booking. This patch adds an exclude_booking_id option to Koha::Item->find_booking so a lookup can skip a specific booking (here: the patron's own booking being collected), and uses it in CanBookBeIssued to detect when an explicitly requested due date would run into the next booking for the item. When it would, a new BOOKED_DUE_DATE_CLASH confirmation is raised and displayed on the checkout screen, telling staff the linked booking will keep its original end date if they continue. Only explicitly requested due dates trigger the confirmation - calculated due dates are clamped to the booking end date later in the staff checkout flow, so checking them would produce false positives. SIP is unaffected as it never passes a requested due date. Test plan: 1) Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2) Create two consecutive bookings on the same item for two patrons 3) Check the item out to the first patron specifying a due date beyond the second booking's start date; confirm the new confirmation message appears and checkout only proceeds once confirmed Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202368 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202368&action=edit Bug 42997: Prevent renewals running into the next booking CanBookBeRenewed checked bookings by asking Koha::Item->find_booking for the first booking that clashes with the renewal period. When the renewing patron's own booking satisfies this checkout, that booking is returned first and renewal is allowed - subsequent bookings for the item were never considered. A patron could therefore renew a booked item straight through the start of the next patron's booking. Additionally, when staff renew with an explicit due date (the renewal due date input on the checkouts screen, or the hard due date on circ/renew.pl), CanBookBeRenewed validated a *calculated* due date whilst AddRenewal then applied the *requested* one, so the requested date was never checked against bookings at all. This patch: * repeats the booking lookup with the patron's own booking excluded, refusing the renewal ('booked') when it would run into the next booking for the item * adds an optional $date_due parameter to CanBookBeRenewed, used in place of the calculated due date for the bookings check, and threads the requested date through from svc/renew and circ/renew.pl Test plan: 1) Run t/db_dependent/Circulation.t - the extended 'CanBookBeRenewed | bookings' subtest covers both the calculated and requested due date cases 2) Check out a booked item to its patron, add a subsequent booking for another patron, and attempt to renew past the second booking's start date from the checkouts screen; confirm the renewal is refused as 'booked' Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202369 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202369&action=edit Bug 42997: Sync booking end_date with the due date at renewal When a checkout satisfying a booking is renewed, the booking previously kept its original end_date, blocking the booked period from other patrons for the wrong window and leaving the two records out of sync. This patch updates C4::Circulation::AddRenewal to pull the linked booking's end_date along with the renewed due date, mirroring the behaviour introduced for AddIssue earlier in this patchset. As at issue time, if the new due date would clash with a subsequent booking (possible when the renewal was explicitly allowed past a clash), the booking keeps its original end_date. Together with the previous patch this makes a renewal the natural way to extend an issued booking: CanBookBeRenewed refuses renewals that would run into the next booking, and AddRenewal keeps the booking in step with the loan. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddRenewal | booking end_date sync' subtest passes 2) Check out a booked item, renew it from the checkouts screen and confirm the booking end date follows the new due date Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202370 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202370&action=edit Bug 42997: Honour explicit due date overrides for booked items at checkout When checking out a booked item, circulation.pl unconditionally replaced the due date with the booking end date, silently discarding any due date staff had explicitly specified - even after they had just confirmed the BOOKED_DUE_DATE_CLASH warning saying they wanted it. The booking end date remains the default when no due date is specified; an explicit override (with SpecifyDueDate enabled) is now passed through to AddIssue, which syncs the booking end_date with it where possible and keeps the original end date when the override would clash with a subsequent booking (as warned). Test plan: 1) Create a booking and check the item out without specifying a due date; confirm the due date defaults to the booking end date 2) Return the item, book it again, and check out specifying an explicit due date; confirm the checkout uses that date and the booking end date follows it Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |paul.derscheid@lmscloud.de |y.org | Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #202365|0 |1 is obsolete| | Attachment #202366|0 |1 is obsolete| | Attachment #202367|0 |1 is obsolete| | Attachment #202368|0 |1 is obsolete| | Attachment #202369|0 |1 is obsolete| | Attachment #202370|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=42997 --- Comment #13 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202488 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202488&action=edit Bug 42997: Sync booking end_date with due date override at checkout When a booked item is checked out, the due date defaults to the booking end_date. Staff may override the due date at checkout time, which previously left the booking end_date out of sync with the checkout, blocking the booked period for longer or shorter than the actual loan. This patch updates C4::Circulation::AddIssue to sync any due date override back to booking.end_date the moment the booking transitions to 'issued', keeping the booking and the checkout aligned from the point of issue. The existing Koha::Booking->store clash detection is used to guard the update: if the overridden due date would clash with a subsequent booking for the same item, the checkout proceeds with the booking's original end_date instead. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddIssue | booking end_date sync with due date override' subtest passes 2) Create a booking for a patron on a specific item 3) Check the item out to the patron, overriding the suggested due date 4) Confirm the booking's end_date now matches the overridden due date Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #14 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202489 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202489&action=edit Bug 42997: Don't let a booking's own checkout block it in check_booking Koha::Item->check_booking refuses any booking period that starts before the item's current checkout is due back. That is correct when assessing a new booking against someone else's loan, but it also fired when the checkout in question is the booking's own linked loan - making it impossible to ever move an issued booking's end_date, as any update would 'clash' with its own checkout. This patch skips the checkout guard when the checkout's booking_id matches the booking_id passed for exclusion, i.e. when the checkout belongs to the very booking being updated. This is a prerequisite for keeping booking end dates in sync with checkout due dates in this patchset, and for the booking extension pathway on bug 42790. Test plan: 1) Run t/db_dependent/Koha/Item.t and confirm the check_booking subtest passes, including the two new checkout-related tests Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #15 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202490 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202490&action=edit Bug 42997: Warn staff when a due date override runs into the next booking When checking out a booked item, staff may override the suggested due date. If that override runs into the next booking for the item, the previous patch would silently keep the booking's original end date - staff had no way of knowing their override crossed another booking. This patch adds an exclude_booking_id option to Koha::Item->find_booking so a lookup can skip a specific booking (here: the patron's own booking being collected), and uses it in CanBookBeIssued to detect when an explicitly requested due date would run into the next booking for the item. When it would, a new BOOKED_DUE_DATE_CLASH confirmation is raised and displayed on the checkout screen, telling staff the linked booking will keep its original end date if they continue. Only explicitly requested due dates trigger the confirmation - calculated due dates are clamped to the booking end date later in the staff checkout flow, so checking them would produce false positives. SIP is unaffected as it never passes a requested due date. Test plan: 1) Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2) Create two consecutive bookings on the same item for two patrons 3) Check the item out to the first patron specifying a due date beyond the second booking's start date; confirm the new confirmation message appears and checkout only proceeds once confirmed Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #16 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202491 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202491&action=edit Bug 42997: Prevent renewals running into the next booking CanBookBeRenewed checked bookings by asking Koha::Item->find_booking for the first booking that clashes with the renewal period. When the renewing patron's own booking satisfies this checkout, that booking is returned first and renewal is allowed - subsequent bookings for the item were never considered. A patron could therefore renew a booked item straight through the start of the next patron's booking. Additionally, when staff renew with an explicit due date (the renewal due date input on the checkouts screen, or the hard due date on circ/renew.pl), CanBookBeRenewed validated a *calculated* due date whilst AddRenewal then applied the *requested* one, so the requested date was never checked against bookings at all. This patch: * repeats the booking lookup with the patron's own booking excluded, refusing the renewal ('booked') when it would run into the next booking for the item * adds an optional $date_due parameter to CanBookBeRenewed, used in place of the calculated due date for the bookings check, and threads the requested date through from svc/renew and circ/renew.pl Test plan: 1) Run t/db_dependent/Circulation.t - the extended 'CanBookBeRenewed | bookings' subtest covers both the calculated and requested due date cases 2) Check out a booked item to its patron, add a subsequent booking for another patron, and attempt to renew past the second booking's start date from the checkouts screen; confirm the renewal is refused as 'booked' Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #17 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202492 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202492&action=edit Bug 42997: Sync booking end_date with the due date at renewal When a checkout satisfying a booking is renewed, the booking previously kept its original end_date, blocking the booked period from other patrons for the wrong window and leaving the two records out of sync. This patch updates C4::Circulation::AddRenewal to pull the linked booking's end_date along with the renewed due date, mirroring the behaviour introduced for AddIssue earlier in this patchset. As at issue time, if the new due date would clash with a subsequent booking (possible when the renewal was explicitly allowed past a clash), the booking keeps its original end_date. Together with the previous patch this makes a renewal the natural way to extend an issued booking: CanBookBeRenewed refuses renewals that would run into the next booking, and AddRenewal keeps the booking in step with the loan. Test plan: 1) Run t/db_dependent/Circulation.t and confirm the new 'AddRenewal | booking end_date sync' subtest passes 2) Check out a booked item, renew it from the checkouts screen and confirm the booking end date follows the new due date Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #18 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202493 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202493&action=edit Bug 42997: Honour explicit due date overrides for booked items at checkout When checking out a booked item, circulation.pl unconditionally replaced the due date with the booking end date, silently discarding any due date staff had explicitly specified - even after they had just confirmed the BOOKED_DUE_DATE_CLASH warning saying they wanted it. The booking end date remains the default when no due date is specified; an explicit override (with SpecifyDueDate enabled) is now passed through to AddIssue, which syncs the booking end_date with it where possible and keeps the original end date when the override would clash with a subsequent booking (as warned). Test plan: 1) Create a booking and check the item out without specifying a due date; confirm the due date defaults to the booking end date 2) Return the item, book it again, and check out specifying an explicit due date; confirm the checkout uses that date and the booking end date follows it Sponsored-by: OpenFifth <https://openfifth.co.uk/\> Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> 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=42997 --- Comment #19 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202494 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202494&action=edit Bug 42997: (QA follow-up) Don't let a booking's own checkout block it in Biblio::check_booking Koha::Biblio->check_booking counts current checkouts on bookable items against the pool of available items. Like Item::check_booking before this patchset, it made no exception for the checkout that belongs to the very booking being validated, so updating an issued booking's period could clash against its own loan whenever the new period no longer overlaps the stored one (the item_id exemption for booked items only catches bookings that overlap the window under test). This is masked in the end_date syncs earlier in this patchset because the synced window always contains the stored start_date; it surfaces as soon as a sync moves the whole period, and would equally bite the extension pathway on bug 42790. - skip checkouts whose booking_id matches the booking being validated when counting occupied bookable items, mirroring the Item::check_booking exemption - cover the blocking and non-blocking checkout cases in Biblio.t Test plan: 1. prove t/db_dependent/Koha/Biblio.t 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=42997 --- Comment #20 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202495 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202495&action=edit Bug 42997: (QA follow-up) Don't invert the booking period when syncing end dates Collecting a booking early (within the bookings lead period) with a due date override before the booking start syncs end_date to a date that precedes start_date. Koha::Booking->store has no interval validation and the clash checks' date windows never see the inverted period, so the broken row is stored silently - reproduced via AddIssue on this patchset. - pull start_date back to the checkout date whenever the synced due date precedes it, in both AddIssue and AddRenewal, so the booking window follows the loan instead of inverting - cover both paths in Circulation.t; the AddRenewal case needs the Biblio::check_booking exemption from the previous patch, as the synced window no longer overlaps the stored one Test plan: 1. prove t/db_dependent/Circulation.t 2. Set bookings_lead_period to e.g. 5 for an itemtype and enable SpecifyDueDate 3. Book an item of that itemtype for a patron starting in 3 days 4. Check it out to them today with an explicit due date of tomorrow 5. Without this patch the booking is stored with end_date before start_date; with it both dates follow the checkout period 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=42997 --- Comment #21 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 202496 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202496&action=edit Bug 42997: (QA follow-up) Keep on-site checkouts due at the end of the day circulation.pl still replaced the due date of an on-site checkout of a booked item with the booking end date: with SpecifyDueDate disabled the end-of-today due date computed for on-site checkouts was clobbered, and with it enabled the same happened whenever staff left the due date field empty. An on-site loan could therefore be due back days after the on-site session. - never stretch an on-site checkout to the booking end date; the due date behaves exactly as for a non-booked on-site checkout and AddIssue shrinks the booking end_date to the actual due date instead Test plan: 1. Enable OnSiteCheckouts, disable SpecifyDueDate 2. Book an item for a patron starting today 3. Check the item out to them with 'On-site checkout' ticked 4. Without this patch the checkout is due at the booking end date; with it the checkout is due at the end of today and the booking end date follows it 5. Repeat with SpecifyDueDate enabled and the due date field left empty; the due date follows the circulation rules instead of the booking end date 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=42997 --- Comment #22 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Testing notes On ktd (dates relative to checkout day; bookable item, two patrons; renewals allowed 2, renewal period 7). The booking picker currently allows starts from tomorrow (+1) at the earliest, so all bookings below start at +1 or later and every same-day checkout goes through the early-collection confirmation first. 1. Override sync: booking + -> +8, checked out with due +11 -> booking end followed to +11. 2. Clash warning: bookings A (patron 1, +1 -> +8) and B (patron 2, +10 -> +14), checkout to patron 1 with due +11 (inside B's window) -> BOOKED_DUE_DATE_CLASH shown; after confirming, checkout used the requested date and booking A kept its original end date. 3. Renewal, refusal: with B still active, the checkouts table refuses renewal outright ("Item booked for another patron"), the calculated renewal date runs into B. 4. Renewal, sync: after cancelling B, renewed via the checkouts table with an explicit renewal due date -> checkout and booking end both moved to the requested date, booking still issued. 5. On-site (follow-up): SpecifyDueDate off, booking +1 -> +8, bookings_lead_period 5, on-site checkout today via the early-collection confirm -> due end of today, not the booking end date. 6. Early collection with short override (follow-up): SpecifyDueDate on, booking +3 -> +10 under the same lead period, checked out today with due +1, renewed to +2 -> booking issued with start pulled back to the checkout day and end following the renewal; no inverted period. Setup note for steps 5/6: place the bookings before setting bookings_lead_period, otherwise the picker blocks the near-term start dates. The rule is evaluated live at checkout time either way. The Biblio::check_booking exemption only shows when the updated window no longer overlaps the stored one, which the UI flows above never produce once the start has been pulled back. That path is covered by the new Biblio.t and Circulation.t tests. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 --- Comment #23 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Comment on attachment 202496 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202496 Bug 42997: (QA follow-up) Keep on-site checkouts due at the end of the day Review of attachment 202496: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=42997&attachment=202496) ----------------------------------------------------------------- ::: circ/circulation.pl @@ +590,3 @@
if ( my $booked = $needsconfirmation->{BOOKED_EARLY} // $alerts->{BOOKED} ) { + $datedue = $booked->end_date + unless ( ( $duedatespec_allow && $duedatespec ) || $onsite_checkout );
This is fun... 'BOOKED_EARLY' only appears when checking out to a particular user but BOOKED will appear regardless.. so easily missed, nice catch! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org