Enforcing max circ rule loan periods on bookings (37354), cuts into the circ period of a booking when post-processing days are added. To replicate: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5.
I think this is a problem in the mouseover function AFTER selecting a startDate where it is incorrectly using hoverDate instead of startDate
Created attachment 181312 [details] [review] Bug 39584: Use startDate instead of hoverDate when calculating loan period on mouseover To test: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5. 4. APPLY PATCH 5. Try the booking again, this time you should be able to select the full loan period for that item.
I looked at this in a sandbox. While I am able to add 2 days of post-processing and get the full 7-day circ period, it looks like the date picker is marking the post-processing days within the booking now. That is, if I pick a booking for a 7-day circ period between May 5-12, the calendar is marking May 6 and 7 as the post-processing days, not May 13-14. Please see the attached screenshot.
Created attachment 181394 [details] BookingPostProcessing_39584 Shows booking post-processing days assigned within the booking period instead of after.
Created attachment 182448 [details] [review] Bug 39584: Include trailDays when calculating maxDate When enforcing the max booking period from the circulation rules, we should not include booking post processing days. Our pre and post processing days handling looks for 'flatpickr-disabled' and ensure processing days cannot overlap. When setting maxDate, flatpickr will apply the flatpickr-disabled class to the next day to prevent selection past the max date and as such our post-processing acts in an inclusive manor. This patch updates our maxDate handler to increase then maximum target by the trailDays setting to allow a full loan period. To test: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5. 4. APPLY PATCH 5. Try the booking again, this time you should be able to select the full loan period for that item.
I've got a slightly cleaner approach.. but I'm still refining a bit as I don't like that because the maxDate is extended in my version it appears later than it really is due to the ungreyed out dates.
Created attachment 182451 [details] [review] Bug 39584: Include trailDays when calculating maxDate When enforcing the max booking period from the circulation rules, we should not include booking post processing days. Our pre and post processing days handling looks for 'flatpickr-disabled' and ensure processing days cannot overlap. When setting maxDate, flatpickr will apply the flatpickr-disabled class to the next day to prevent selection past the max date and as such our post-processing acts in an inclusive manor. This patch updates our maxDate handler to increase then maximum target by the trailDays setting to allow a full loan period and includes styling to match flatpickr-disabled for the exclusive trailDays. To test: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5. 4. APPLY PATCH 5. Try the booking again, this time you should be able to select the full loan period for that item.
OK.. I'm done.. could someone please try out my alternative patch.. I believe it more accurately allows for all the existing cases. So.. the basic test plan just checks that the bug in question is resolved.. but what would be even better is to add a set of bookings in and ensure end date handling is still properly handled for those bookings with a start date before one and around the expected maximum date. Many thanks,
I looked at this in a sandbox with a 7-day circ period and no renewals allowed. I got the full circ period with the 2 post-processing factored in at the end (39584_20250520.png) That addresses the bug as described, post-processing cutting into the circ period. If there are renewals allowed, the post-processing also does not cut into the circ peiod (39584_WithRenewals_20250520.png) It does look like it adds another day on the end date in this case though. A booking for 7 days with 2 renewals starting on 6/02 would end on 6/23 in the date picker, but it ends on 6/24 when booked (39584_Bookings.PNG) I'm not sure I fully understand "what would be even better is to add a set of bookings in and ensure end date handling is still properly handled for those bookings with a start date before one and around the expected maximum date." Happy to discuss that further. Otherwise, the patch addresses the problem as described "Enforcing max circ rule loan periods on bookings (37354), cuts into the circ period of a booking when post-processing days are added."
Created attachment 182678 [details] BookingWithPostProcessing_NoRenewals
Created attachment 182679 [details] BookingWithPostProcessing_WithRenewals
Created attachment 182680 [details] BookingsWithDayAddedInBooking
Thanks for testing Kristi, it's very much appreciated. (In reply to Kristi from comment #9) > If there are renewals allowed, the post-processing also does not cut into > the circ peiod (39584_WithRenewals_20250520.png) It does look like it adds > another day on the end date in this case though. A booking for 7 days with 2 > renewals starting on 6/02 would end on 6/23 in the date picker, but it ends > on 6/24 when booked (39584_Bookings.PNG) As discussed, I think this is pre-existing and it's actually a day "added" at to the initial issue if I'm understanding it correctly. We count the first day of the booking as the "pickup day" and under normal circulation we would set the due date to today at midnight + issue period.. so if I booked from the first, the due date would be midnight on the 8th.. 1st + 7 days = 8th. For renewals, we currently add a renewal period for each renewal allowed, so it's exclusive of the 'renewal' day.. it presumed you would be returning the item on the last day of your issue and adds renewal period to that day. > I'm not sure I fully understand "what would be even better is to add a set > of bookings in and ensure end date handling is still properly handled for > those bookings with a start date before one and around the expected maximum > date." Happy to discuss that further. So what I meant by that was that I just wanted to verify that we're still handling bookings clashes as expected. i.e that the lead and trail periods still interact with other bookings, ensuring one cannot overlap with another booking (I know I also have another bug to work on to ensure we don't overlap lead/trail periods with each other too)
Thanks for the explanations on both points. Bookings do still overlap with pre- and post-processing time. I set circ rules for 2 days of post-processing and a 7-day circ period, no renewals. I placed a booking for 6/9-6/16, which would have the 2 post-processing days on 6/17 and 6/18. I was able to place a booking for 6/18- 6/25. That is, I was allowed to place a booking that started on one of the post-processing days for the first booking. This is bib 194 in the PTFS-hosted sandbox for this bug if it helps. Would this issue be a new bug report?
Created attachment 182910 [details] [review] Bug 39584: Include trailDays when calculating maxDate When enforcing the max booking period from the circulation rules, we should not include booking post processing days. Our pre and post processing days handling looks for 'flatpickr-disabled' and ensure processing days cannot overlap. When setting maxDate, flatpickr will apply the flatpickr-disabled class to the next day to prevent selection past the max date and as such our post-processing acts in an inclusive manor. This patch updates our maxDate handler to increase then maximum target by the trailDays setting to allow a full loan period and includes styling to match flatpickr-disabled for the exclusive trailDays. To test: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5. 4. APPLY PATCH 5. Try the booking again, this time you should be able to select the full loan period for that item. Signed-off-by: Eric Garcia <cubingguy714@gmail.com>
Blocked currently by 39916
Created attachment 190822 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with existing bookings - Lead period conflict prevention with past dates - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Trail period should NOT limit max date when clear (BUG FIX TEST) - Full max range selection when trail period has no conflicts The critical bug being tested: Trail period should ONLY prevent selection when it conflicts with an existing booking. It should NOT subtract from the max date allowed by circulation rules. Currently, the trail period incorrectly reduces the max selectable end date even when no conflicts exist. Test setup: - Lead period: 2 days - Trail period: 3 days - Issue length: 14 days with 2 renewals of 7 days each - Max period: 28 days - Booking A (Days 5-7): Tests lead period conflicts - Booking B (Days 45-50): Tests trail period conflicts The test at line 977-1045 (TEST 4) specifically validates that the max end date (Day 37) is selectable when the trail period (Days 38-40) is clear, proving the trail period doesn't incorrectly reduce max date. These tests currently expose the bug and will pass once the JavaScript implementation is fixed.
Created attachment 190823 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date. Test Updates: ============= Updated the Cypress test to correctly calculate the expected max date consistent with existing tests (startDate + maxPeriod, not -1). The test now properly validates that Day 38 (max date with 28-day period from Day 10) is selectable when the trail period (Days 39-41) has no booking conflicts.
Created attachment 190824 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with existing bookings - Lead period conflict prevention with past dates - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Trail period should NOT limit max date when clear (BUG FIX TEST) - Full max range selection when trail period has no conflicts The critical bug being tested: Trail period should ONLY prevent selection when it conflicts with an existing booking. It should NOT subtract from the max date allowed by circulation rules. Currently, the trail period incorrectly reduces the max selectable end date even when no conflicts exist. Test setup: - Lead period: 2 days - Trail period: 3 days - Issue length: 14 days with 2 renewals of 7 days each - Max period: 28 days - Booking A (Days 5-7): Tests lead period conflicts - Booking B (Days 45-50): Tests trail period conflicts The test at line 977-1045 (TEST 4) specifically validates that the max end date (Day 37) is selectable when the trail period (Days 38-40) is clear, proving the trail period doesn't incorrectly reduce max date. These tests currently expose the bug and will pass once the JavaScript implementation is fixed.
Created attachment 190825 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date.
Created attachment 190898 [details] [review] Bug 39584: Correct spelling in comment QA tools caught the spelling "caluclate" in a comment within the cypress test code.
Created attachment 190931 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with existing bookings - Lead period conflict prevention with past dates - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Trail period should NOT limit max date when clear (BUG FIX TEST) - Full max range selection when trail period has no conflicts The critical bug being tested: Trail period should ONLY prevent selection when it conflicts with an existing booking. It should NOT subtract from the max date allowed by circulation rules. Currently, the trail period incorrectly reduces the max selectable end date even when no conflicts exist. Test setup: - Lead period: 2 days - Trail period: 3 days - Issue length: 14 days with 2 renewals of 7 days each - Max period: 28 days - Booking A (Days 5-7): Tests lead period conflicts - Booking B (Days 45-50): Tests trail period conflicts The test at line 977-1045 (TEST 4) specifically validates that the max end date (Day 37) is selectable when the trail period (Days 38-40) is clear, proving the trail period doesn't incorrectly reduce max date. These tests currently expose the bug and will pass once the JavaScript implementation is fixed. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 190932 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 190933 [details] [review] Bug 39584: Correct spelling in comment QA tools caught the spelling "caluclate" in a comment within the cypress test code. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191765 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. The tests use cy.clock() to fix "today" to June 10, 2026, enabling deterministic testing without date arithmetic complications. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with past dates - Lead period conflict prevention with existing bookings - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Max date selection when trail period is clear (no false restrictions) Test setup: - Fixed date: June 10, 2026 - Lead period: 2 days - Trail period: 3 days - Issue length: 3 days with 2 renewals of 2 days each - Max booking period: 7 days - Blocker booking: June 25-27 (tests both lead and trail conflicts) Test phases: 1. Hover June 13 - lead period (June 11-12) is clear, no leadDisable 2. Select June 13, hover June 16 - trail period (June 17-19) is clear 3a. Hover June 11 - lead period includes past date (June 9), leadDisable 3b. Hover June 29 - lead period overlaps blocker (June 27), leadDisable 4. Select June 20, hover June 23 - trail overlaps blocker, trailDisable 5. Select June 13, hover June 20 (max) - trail is clear, selectable Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191766 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191767 [details] [review] Bug 39584: Fix end date disable to check selected item, not all items When a specific item is selected in the booking modal, the end date disable logic was incorrectly checking if ALL bookable items were unavailable before disabling a date. This meant dates with existing bookings for the selected item remained selectable if other items were available. Now when a specific item is selected (booking_item_id != 0), the logic checks if that specific item is in the unavailable_items list. The "all items unavailable" check is only used when "Any item" is selected. This aligns the end date selection behavior with the start date selection behavior, which already correctly checks only the selected item. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191768 [details] [review] Bug 39584: Correct spelling in comment QA tools caught the spelling "caluclate" in a comment within the cypress test code. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191855 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. The tests use cy.clock() to fix "today" to June 10, 2026, enabling deterministic testing without date arithmetic complications. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with past dates - Lead period conflict prevention with existing bookings - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Max date selection when trail period is clear (no false restrictions) Test setup: - Fixed date: June 10, 2026 - Lead period: 2 days - Trail period: 3 days - Issue length: 3 days with 2 renewals of 2 days each - Max booking period: 7 days - Blocker booking: June 25-27 (tests both lead and trail conflicts) Test phases: 1. Hover June 13 - lead period (June 11-12) is clear, no leadDisable 2. Select June 13, hover June 16 - trail period (June 17-19) is clear 3a. Hover June 11 - lead period includes past date (June 9), leadDisable 3b. Hover June 29 - lead period overlaps blocker (June 27), leadDisable 4. Select June 20, hover June 23 - trail overlaps blocker, trailDisable 5. Select June 13, hover June 20 (max) - trail is clear, selectable Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191856 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Created attachment 191857 [details] [review] Bug 39584: Fix end date disable to check selected item, not all items When a specific item is selected in the booking modal, the end date disable logic was incorrectly checking if ALL bookable items were unavailable before disabling a date. This meant dates with existing bookings for the selected item remained selectable if other items were available. Now when a specific item is selected (booking_item_id != 0), the logic checks if that specific item is in the unavailable_items list. The "all items unavailable" check is only used when "Any item" is selected. This aligns the end date selection behavior with the start date selection behavior, which already correctly checks only the selected item. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Had to obsolete the type correction patch since it needs to be resolved in Bug 39916 as this bug depends on it.
Created attachment 191941 [details] [review] Bug 39584: Add Cypress tests for bookings lead and trail period behavior This commit adds comprehensive Cypress tests for the lead and trail period functionality in the bookings modal date picker. These tests validate the hover effects, conflict detection, and date selection constraints. The tests use cy.clock() to fix "today" to June 10, 2026, enabling deterministic testing without date arithmetic complications. Test coverage includes: - Lead period visual hints (CSS classes on hover) - Lead period conflict prevention with past dates - Lead period conflict prevention with existing bookings - Trail period visual hints (CSS classes on hover) - Trail period conflict prevention with existing bookings - Max date selection when trail period is clear (no false restrictions) Test setup: - Fixed date: June 10, 2026 - Lead period: 2 days - Trail period: 3 days - Issue length: 3 days with 2 renewals of 2 days each - Max booking period: 7 days - Blocker booking: June 25-27 (tests both lead and trail conflicts) Test phases: 1. Hover June 13 - lead period (June 11-12) is clear, no leadDisable 2. Select June 13, hover June 16 - trail period (June 17-19) is clear 3a. Hover June 11 - lead period includes past date (June 9), leadDisable 3b. Hover June 29 - lead period overlaps blocker (June 27), leadDisable 4. Select June 20, hover June 23 - trail overlaps blocker, trailDisable 5. Select June 13, hover June 20 (max) - trail is clear, selectable Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Created attachment 191942 [details] [review] Bug 39584: Fix trail period incorrectly limiting max booking date This commit fixes a bug where the trail period was preventing selection of the maximum end date allowed by circulation rules, even when there were no booking conflicts in the trail period. The Problem: ============ The hover logic in place_booking.js checked if ANY disabled date fell within the trail period and would prevent selection. However, dates can be disabled for multiple reasons: 1. They conflict with an existing booking (correct reason to disable) 2. They are beyond the maxDate set by circulation rules (incorrect!) 3. They are in the past When hovering over the max selectable end date, the trail period would extend beyond the maxDate. Those dates were disabled by flatpickr automatically, and the code incorrectly interpreted this as a booking conflict, preventing selection of the otherwise valid max date. The Fix: ======== Modified the trail period conflict check (lines 995-1005) to only consider dates that are within the max date range. Disabled dates beyond the maxDate are now ignored when checking for trail conflicts. Before: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { trailDisable = true; } After: if (elemDate.isAfter(trailStart) && elemDate.isSameOrBefore(trailEnd)) { const maxDate = periodPicker.config.maxDate ? dayjs(periodPicker.config.maxDate) : null; if (!maxDate || elemDate.isSameOrBefore(maxDate)) { trailDisable = true; } } This ensures trail periods only prevent selection when they conflict with actual bookings, not when they extend beyond the circulation rules' maximum date. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Created attachment 191943 [details] [review] Bug 39584: Fix end date disable to check selected item, not all items When a specific item is selected in the booking modal, the end date disable logic was incorrectly checking if ALL bookable items were unavailable before disabling a date. This meant dates with existing bookings for the selected item remained selectable if other items were available. Now when a specific item is selected (booking_item_id != 0), the logic checks if that specific item is in the unavailable_items list. The "all items unavailable" check is only used when "Any item" is selected. This aligns the end date selection behavior with the start date selection behavior, which already correctly checks only the selected item. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Nice work everyone! Pushed to main for 26.05