Bug 39584

Summary: Booking post-processing time cuts into circulation period
Product: Koha Reporter: Kristi Krueger <kkrueger>
Component: CirculationAssignee: Martin Renvoize (ashimema) <martin.renvoize>
Status: Pushed to main --- QA Contact: Paul Derscheid <me>
Severity: major    
Priority: P5 - low CC: gmcharlt, kkrueger, kyle, lucas, m.de.rooy, martin.renvoize, paul.derscheid
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39916
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
26.05.00
Circulation function: Bookings
Bug Depends on: 39916    
Bug Blocks: 40134    
Attachments: Bug 39584: Use startDate instead of hoverDate when calculating loan period on mouseover
BookingPostProcessing_39584
Bug 39584: Include trailDays when calculating maxDate
Bug 39584: Include trailDays when calculating maxDate
BookingWithPostProcessing_NoRenewals
BookingWithPostProcessing_WithRenewals
BookingsWithDayAddedInBooking
Bug 39584: Include trailDays when calculating maxDate
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Correct spelling in comment
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Correct spelling in comment
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Fix end date disable to check selected item, not all items
Bug 39584: Correct spelling in comment
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Fix end date disable to check selected item, not all items
Bug 39584: Add Cypress tests for bookings lead and trail period behavior
Bug 39584: Fix trail period incorrectly limiting max booking date
Bug 39584: Fix end date disable to check selected item, not all items

Description Kristi Krueger 2025-04-08 17:38:22 UTC
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.
Comment 1 Lucas Gass (lukeg) 2025-04-22 20:29:59 UTC
I think this is a problem in the mouseover function AFTER selecting a startDate where it is incorrectly using hoverDate instead of startDate
Comment 2 Lucas Gass (lukeg) 2025-04-22 20:32:57 UTC Comment hidden (obsolete)
Comment 3 Kristi Krueger 2025-04-23 16:57:07 UTC
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.
Comment 4 Kristi Krueger 2025-04-23 16:58:04 UTC Comment hidden (obsolete)
Comment 5 Martin Renvoize (ashimema) 2025-05-14 13:37:21 UTC Comment hidden (obsolete)
Comment 6 Martin Renvoize (ashimema) 2025-05-14 13:38:22 UTC
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.
Comment 7 Martin Renvoize (ashimema) 2025-05-14 14:36:39 UTC Comment hidden (obsolete)
Comment 8 Martin Renvoize (ashimema) 2025-05-14 14:39:20 UTC
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,
Comment 9 Kristi Krueger 2025-05-20 15:19:13 UTC
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."
Comment 10 Kristi Krueger 2025-05-20 15:19:45 UTC Comment hidden (obsolete)
Comment 11 Kristi Krueger 2025-05-20 15:20:11 UTC Comment hidden (obsolete)
Comment 12 Kristi Krueger 2025-05-20 15:20:45 UTC
Created attachment 182680 [details]
BookingsWithDayAddedInBooking
Comment 13 Martin Renvoize (ashimema) 2025-05-21 06:58:55 UTC
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)
Comment 14 Kristi Krueger 2025-05-21 13:25:14 UTC
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?
Comment 15 Eric Garcia 2025-06-02 16:14:54 UTC
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>
Comment 16 Marcel de Rooy 2025-06-06 06:59:20 UTC
Blocked currently by 39916
Comment 17 Martin Renvoize (ashimema) 2026-01-02 11:32:19 UTC
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.
Comment 18 Martin Renvoize (ashimema) 2026-01-02 11:32:21 UTC
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.
Comment 19 Martin Renvoize (ashimema) 2026-01-02 11:37:52 UTC
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.
Comment 20 Martin Renvoize (ashimema) 2026-01-02 11:37:53 UTC
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.
Comment 21 Andrew Fuerste-Henry 2026-01-05 17:38:54 UTC
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.
Comment 22 Andrew Fuerste-Henry 2026-01-06 12:56:58 UTC
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>
Comment 23 Andrew Fuerste-Henry 2026-01-06 12:57:01 UTC
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>
Comment 24 Andrew Fuerste-Henry 2026-01-06 12:57:04 UTC
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>
Comment 25 Martin Renvoize (ashimema) 2026-01-21 10:56:55 UTC
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>
Comment 26 Martin Renvoize (ashimema) 2026-01-21 10:56:57 UTC
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>
Comment 27 Martin Renvoize (ashimema) 2026-01-21 10:56:58 UTC
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>
Comment 28 Martin Renvoize (ashimema) 2026-01-21 10:57:00 UTC
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>
Comment 29 Paul Derscheid 2026-01-22 12:08:07 UTC
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>
Comment 30 Paul Derscheid 2026-01-22 12:08:09 UTC
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>
Comment 31 Paul Derscheid 2026-01-22 12:08:11 UTC
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>
Comment 32 Paul Derscheid 2026-01-22 12:11:16 UTC
Had to obsolete the type correction patch since it needs to be resolved in Bug 39916 as this bug depends on it.
Comment 33 Martin Renvoize (ashimema) 2026-01-23 14:32:55 UTC
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>
Comment 34 Martin Renvoize (ashimema) 2026-01-23 14:32:56 UTC
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>
Comment 35 Martin Renvoize (ashimema) 2026-01-23 14:32:58 UTC
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>
Comment 36 Lucas Gass (lukeg) 2026-01-30 17:55:55 UTC
Nice work everyone!

Pushed to main for 26.05