https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- 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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|34440 |39584 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34440 [Bug 34440] Add warm-up and cool-down periods to bookings https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39584 [Bug 39584] Booking post-processing time cuts into circulation period -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 182718 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182718&action=edit Bug 37707: First draft This patch adds calculation of pre and post booking days into the disableDate function. I'm not sure I like it for display yet, but functionally it works -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I can confirm this works as described -- bookings cannot be created such that the trailing time of one booking intersects with the leading time of the next. The interface grays out dates that cannot be selected and changes the mouse icon to a crossed-out-circle. Martin, what do you still feel is missing in the display here? Our libraries would love to see this functionality in Koha sooner rather than later. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #4 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- We are eager to see this one move forward. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|39584 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39584 [Bug 39584] Booking post-processing time cuts into circulation period -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40134 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40134 [Bug 40134] Fix and optimise 'Any item' functionality of bookings -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182718|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=37707 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 190860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=190860&action=edit Bug 37707: Improve lead/trail period conflict detection This implements the full "protected period" concept for bookings, where each existing booking reserves: lead period + actual dates + trail period. Previously, we only checked: - New booking lead vs existing booking actual dates - New booking trail vs existing booking actual dates Now we ALSO check: - New booking lead vs existing booking trail periods - New booking trail vs existing booking lead periods This ensures librarians cannot create bookings too close together, respecting both item preparation time (lead) and processing time (trail). Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods 3. Create booking A: January 5-9 - This reserves Jan 3-4 (lead), Jan 5-9 (actual), Jan 10-12 (trail) 4. Attempt to create booking B: January 12-15 with 2-day lead - Lead would be Jan 10-11, which conflicts with booking A's trail 5. Verify days 10-11 are visually disabled with striped pattern 6. Verify hovering shows "conflicts with existing booking's trail period" 7. Verify you cannot select January 12 as start date 8. Verify January 13 IS selectable (no conflict) 9. Run Cypress tests to confirm: npx cypress run --spec "t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 190862 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=190862&action=edit Bug 37707: (follow-up) Add textual feedback for booking lead/trail period conflicts This patch adds a feedback message container below the calendar that provides contextual information about lead/trail period requirements and conflicts improving accessibility. The feedback updates dynamically on hover, showing: - Info messages when hovering selectable dates - Error messages when hovering dates disabled due to conflicts - Specific explanations distinguishing between conflict types (e.g., new lead vs existing trail, new trail vs existing lead) This complements the visual color indicators by providing explicit textual explanations, improving accessibility and user understanding. Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail 3. Create an existing booking for January 10-15 (protected: Jan 8-18) 4. Open the booking calendar and observe feedback area below calendar 5. Hover over Jan 12 (part of existing booking) - Verify message: "This date is part of an existing booking" 6. Hover over Jan 8 (existing booking's lead period) - Verify message explains it's part of the lead period 7. Try to select Jan 19-20 as booking dates (2-day lead = Jan 17-18) - Hover over Jan 19 when it appears disabled - Verify error message: "conflicts with existing booking's trail period" 8. Hover over Jan 21 (no conflicts) - Verify info message about lead/trail requirements 9. Verify all feedback messages are clear and helpful for librarians -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #10 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- Is this something that could be tested in a sandbox? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190860|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190862|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=37707 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191001 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191001&action=edit Bug 37707: Improve lead/trail period conflict detection This implements the full "protected period" concept for bookings, where each existing booking reserves: lead period + actual dates + trail period. Previously, we only checked: - New booking lead vs existing booking actual dates - New booking trail vs existing booking actual dates Now we ALSO check: - New booking lead vs existing booking trail periods - New booking trail vs existing booking lead periods This ensures librarians cannot create bookings too close together, respecting both item preparation time (lead) and processing time (trail). Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods 3. Create booking A: January 5-9 - This reserves Jan 3-4 (lead), Jan 5-9 (actual), Jan 10-12 (trail) 4. Attempt to create booking B: January 12-15 with 2-day lead - Lead would be Jan 10-11, which conflicts with booking A's trail 5. Verify days 10-11 are visually disabled with striped pattern 6. Verify hovering shows "conflicts with existing booking's trail period" 7. Verify you cannot select January 12 as start date 8. Verify January 13 IS selectable (no conflict) 9. Run Cypress tests to confirm: npx cypress run --spec "t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191003 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191003&action=edit Bug 37707: (follow-up) Add textual feedback for booking lead/trail period conflicts This patch adds a feedback message container below the calendar that provides contextual information about lead/trail period requirements and conflicts, improving accessibility and user understanding. The feedback updates dynamically on hover, showing: - Info messages when hovering selectable dates - Error messages when hovering dates disabled due to conflicts - Specific explanations distinguishing between conflict types (e.g., new lead vs existing trail, new trail vs existing lead) - Multiple conflict messages when both lead and trail periods conflict - Specific messages for past dates and insufficient lead time Key improvements: - Standardized terminology consistently uses "lead period" and "trail period" - Proper internationalization using __() for all user-facing strings - DRY code with detectPeriodConflict() helper function - Styling moved from inline JavaScript to SCSS using Bootstrap alert classes - Empty/zero periods are handled gracefully (not mentioned in messages) - Accurate conflict detection prioritizes what the hovered date IS over what it conflicts with This complements the visual color indicators by providing explicit textual explanations, improving accessibility and user understanding. Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods 3. Create an existing booking for January 10-15 (protected: Jan 8-18) 4. Open the booking calendar and observe feedback area below calendar 5. Test past date and insufficient lead time messages: - Hover on today's date * Verify message: "Cannot select: Date is in the past" - Hover on tomorrow (with 2-day lead period) * Verify message: "Cannot select: Insufficient lead time (2 days required before start)" - Hover on the day after tomorrow * Verify message: "Cannot select: Insufficient lead time (2 days required before start)" * Should NOT show "conflicts with existing booking" if no booking exists 6. Test existing booking conflict messages: - Hover over Jan 12 (part of existing booking) * Verify message: "Cannot select: This date is part of an existing booking" - Hover over Jan 8 (existing booking's lead period) * Verify message: "Cannot select: This date is part of an existing booking's lead period" - Hover over Jan 16 (existing booking's trail period) * Verify message: "Cannot select: This date is part of an existing booking's trail period" 7. Test lead/trail period conflict messages: - Try to select Jan 19-20 as booking dates (2-day lead = Jan 17-18) - Hover over Jan 19 when it appears disabled * Verify error message: "Cannot select: Lead period (2 days before start) conflicts with existing booking's trail period" 8. Test info messages for valid dates: - Hover over Jan 21 (no conflicts, with lead period configured) * Verify info message: "Selecting start date. Lead period: 2 days before start" - Configure booking with NO lead period (0 or blank) - Hover over a valid date * Verify message: "Selecting start date" (no mention of lead period) 9. Test multiple conflict messages: - Position calendar to hover between two bookings where both lead and trail conflict * Verify message shows both conflicts separated by semicolon * Example: "Cannot select: lead period conflicts with existing booking's trail period; trail period conflicts with existing booking's lead period" 10. Verify all feedback messages: - Are properly translated (check .po files if applicable) - Use consistent "lead period" and "trail period" terminology - Are clear and helpful for librarians - Update color coding (red for errors, blue for info) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #17 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Following the test plan in comment 15, I've run into some issues. I've got a bib with just 1 item on it. That item is bookable. After creating a booking for January 10-15, the calendar to create a new booking has January 10-16 greyed out, as if my booking were 10-16. In the calendar, mousing over days in the past gives error messages as if all past dates are part of an existing booking. When mousing over a date to select the start of a booking, the system gives feedback about the potential booking's trail period. I would suggest we should only give feedback about the potential booking's trail period when selecting the end of the potential booking. Until the user is proposing a booking end date, we cannot know what that booking's trail will conflict with. The datepicker and message area generally appeared above the Booking Dates input field. However, sometimes the datepicker and message area appeared below the input field instead. When this happened, the bottom of the message field pushed out of my window and could not be seen without zooming my browswer out. I was not able to scroll down to see the rest of the message. The messages contain inconsistent capitalization. Errors all start "Cannot select:" but the first word following that colon is sometimes capitalized and sometimes not. (In reply to Martin Renvoize (ashimema) from comment #15)

6. Test existing booking conflict messages: - Hover over Jan 12 (part of existing booking) * Verify message: "Cannot select: This date is part of an existing booking"

This gives me the message "lead period conflicts with existing booking; trail period conflicts with an existing booking." The first statement will be true if I select 1/12 as the start of my booking. The second statement will be true if I select 1/12 as the end of my booking. In either case, the proposed message of "This date is part of an existing booking" would be more clear.

- Hover over Jan 8 (existing booking's lead period) * Verify message: "Cannot select: This date is part of an existing booking's lead period"

This gives me the message "lead period conflicts with existing booking; trail period conflicts with existing booking's lead period." The first statement is *not* true, the lead period for a booking starting 1/8 would need to start 1/6, which is in the past and does not have a booking.

- Hover over Jan 16 (existing booking's trail period) * Verify message: "Cannot select: This date is part of an existing booking's trail period"

This gives me the message "This date is part of an exiting booking." This is *not* true, 1/16 is part of the trail period of my existing booking. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #19 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- Created attachment 191232 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191232&action=edit BookingBLeadConflic.png -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #21 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191350 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191350&action=edit Bug 37707: Add Cypress tests for bidirectional lead/trail period conflicts This enhances the bookings lead/trail period tests to validate that: - New booking's lead period respects existing bookings' trail periods - New booking's trail period respects existing bookings' lead periods Previously, we only checked: - New booking lead vs existing booking actual dates - New booking trail vs existing booking actual dates Now we also validate the full "protected period" concept where each existing booking reserves: lead + actual + trail period. Test timeline updated: - Booking A: Days 20-25 (protected: 18-28) - Booking B: Days 60-65 (protected: 58-68) New test coverage: - TEST 2B: New lead conflicts with existing trail (Days 27-30) - TEST 6B: New trail conflicts with existing lead (Days 55-56) - TEST 7: Valid booking window (Days 31-54) respecting both Current status: Tests FAIL as expected, revealing the bug that bidirectional checking is not yet implemented. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #23 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191352 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191352&action=edit Bug 37707: (follow-up) Add visual refinements for existing booking lead/trail periods This patch enhances the visual presentation of existing bookings' protected periods (lead/trail) to match the polished appearance of new booking lead/trail period indicators. Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 2-day trail 3. Create an existing booking for January 10-15 4. Open the booking calendar for that item 5. Verify visual styling of protected periods: - Jan 8-9 (lead period): diagonal striped pattern, rounded left edge on Jan 8 - Jan 10-15 (booking): solid color fill - Jan 16-17 (trail period): diagonal striped pattern, rounded right edge on Jan 17 6. Verify no visual gaps between consecutive protected period dates 7. Verify the striped pattern is clearly distinguishable from solid booking dates 8. Hover over different date ranges and verify lead/trail styling updates correctly -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #25 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191354 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191354&action=edit Bug 37707: Fix timezone handling in place_booking modal This patch fixes timezone inconsistencies in the place_booking modal that caused dates to shift when the server and browser are in different timezones. Issues Fixed: 1. Date index creation used .toISOString().split("T")[0] which converted to UTC, causing western timezone dates to appear on wrong calendar days 2. Date comparisons mixed flatpickr.parseDate() and dayjs() without normalizing to start-of-day 3. Booking overlap detection had inconsistent timezone handling Changes: - Replace .toISOString().split("T")[0] with dayjs().format('YYYY-MM-DD') to maintain browser timezone consistency - Normalize all date comparisons to start-of-day using dayjs().startOf('day') - Use dayjs() consistently for parsing RFC3339 datetime strings from API - Add explicit .startOf('day') and .endOf('day') for API submission clarity These changes ensure: - Bookings display on correct calendar days regardless of browser timezone - Multi-day bookings span the correct number of days - Conflict detection works consistently across all timezones - Item availability calculations are accurate - Future hourly booking support is preserved (time components maintained) Test plan: 1. Set browser to PST (UTC-8), server to UTC 2. Create a booking for January 15 3. Verify booking displays on Jan 15 only (not Jan 15-16) 4. Create a 3-day booking (Jan 15-17) 5. Verify displays on exactly 3 days 6. Test conflict detection with overlapping bookings 7. Repeat tests with browser in HST (UTC-10) and NZDT (UTC+13) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|Small patch |Medium patch Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191001|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191003|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191351|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191353|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191355|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=37707 --- Comment #28 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191357 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191357&action=edit Bug 37707: Improve lead/trail period conflict detection This implements the full "protected period" concept for bookings, where each existing booking reserves: lead period + actual dates + trail period. Previously, we only checked: - New booking lead vs existing booking actual dates - New booking trail vs existing booking actual dates Now we ALSO check: - New booking lead vs existing booking trail periods - New booking trail vs existing booking lead periods This ensures librarians cannot create bookings too close together, respecting both item preparation time (lead) and processing time (trail). Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods 3. Create booking A: January 5-9 - This reserves Jan 3-4 (lead), Jan 5-9 (actual), Jan 10-12 (trail) 4. Attempt to create booking B: January 12-15 with 2-day lead - Lead would be Jan 10-11, which conflicts with booking A's trail 5. Verify days 10-11 are visually disabled with striped pattern 6. Verify hovering shows "conflicts with existing booking's trail period" 7. Verify you cannot select January 12 as start date 8. Verify January 13 IS selectable (no conflict) 9. Run Cypress tests to confirm: npx cypress run --spec "t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #30 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191359 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191359&action=edit Bug 37707: (follow-up) Add textual feedback for booking lead/trail period conflicts This patch adds a feedback message container below the calendar that provides contextual information about lead/trail period requirements and conflicts, improving accessibility and user understanding. The feedback updates dynamically on hover, showing: - Info messages when hovering selectable dates - Error messages when hovering dates disabled due to conflicts - Specific explanations distinguishing between conflict types (e.g., new lead vs existing trail, new trail vs existing lead) - Multiple conflict messages when both lead and trail periods conflict - Specific messages for past dates and insufficient lead time Key improvements: - Standardized terminology consistently uses "lead period" and "trail period" - Proper internationalization using __() for all user-facing strings - Structured conflict reason tracking using leadConflictReason/trailConflictReason objects - Fixed off-by-one errors in lead/trail period range calculations - Corrected boundary condition checks throughout (isSameOrBefore/isSameOrAfter) - Added safeguards for direct hovering on existing booking periods - Styling moved from inline JavaScript to SCSS using Bootstrap alert classes - Empty/zero periods are handled gracefully (not mentioned in messages) - Accurate conflict detection prioritizes what the hovered date IS over what it conflicts with This complements the visual color indicators by providing explicit textual explanations, improving accessibility and user understanding. Test plan: 1. Apply all patches and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods 3. Create an existing booking for January 10-15 (protected: Jan 8-18) 4. Open the booking calendar and observe feedback area below calendar 5. Test past date and insufficient lead time messages: - Hover on today's date * Verify message: "Cannot select: Date is in the past" - Hover on tomorrow (with 2-day lead period) * Verify message: "Cannot select: Insufficient lead time (2 days required before start)" - Hover on the day after tomorrow * Verify message: "Cannot select: Insufficient lead time (2 days required before start)" * Should NOT show "conflicts with existing booking" if no booking exists 6. Test existing booking conflict messages: - Hover over Jan 12 (part of existing booking) * Verify message: "Cannot select: This date is part of an existing booking" - Hover over Jan 8 (existing booking's lead period) * Verify message: "Cannot select: This date is part of an existing booking's lead period" - Hover over Jan 16 (existing booking's trail period) * Verify message: "Cannot select: This date is part of an existing booking's trail period" 7. Test lead/trail period conflict messages: - Try to select Jan 19-20 as booking dates (2-day lead = Jan 17-18) - Hover over Jan 19 when it appears disabled * Verify error message: "Cannot select: Lead period (2 days before start) conflicts with existing booking's trail period" 8. Test info messages for valid dates: - Hover over Jan 21 (no conflicts, with lead period configured) * Verify info message: "Selecting start date. Lead period: 2 days before start" - Configure booking with NO lead period (0 or blank) - Hover over a valid date * Verify message: "Selecting start date" (no mention of lead period) 9. Test multiple conflict messages: - Position calendar to hover between two bookings where both lead and trail conflict * Verify message shows both conflicts separated by semicolon * Example: "Cannot select: lead period conflicts with existing booking's trail period; trail period conflicts with existing booking's lead period" 10. Verify all feedback messages: - Are properly translated (check .po files if applicable) - Use consistent "lead period" and "trail period" terminology - Are clear and helpful for librarians - Update color coding (red for errors, blue for info) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #32 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 191361 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191361&action=edit Bug 37707: Add Cypress tests for timezone handling in place_booking modal This patch adds comprehensive timezone tests to validate that the place_booking modal handles dates correctly regardless of browser timezone differences from the server. Test Coverage: 1. Date Index Creation Consistency - Validates bookings display on correct calendar dates - Tests the dayjs().format('YYYY-MM-DD') fix 2. Multi-Day Booking Span - Ensures 3-day bookings span exactly 3 days - Prevents UTC conversion from adding extra days 3. Date Comparison Consistency - Verifies conflict detection works across timezones - Tests normalized start-of-day comparisons 4. API Submission Round-Trip - Validates dates survive browser → API → database flow - Checks RFC3339 handling and timezone offset preservation 5. Cross-Month Boundary - Tests bookings spanning month boundaries - Validates no date shifts at month transitions These tests validate the timezone fixes in place_booking.js and ensure bookings work correctly for users in any timezone. Test plan: Run inside KTD container: docker exec --user kohadev-koha --workdir /kohadevbox/koha -i \ kohadev-koha-1 bash -c 'npx cypress run --spec \ "t/cypress/integration/Circulation/bookingsModalTimezone_spec.ts"' Expected result: All 5 tests should pass -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #34 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Everything I did in the UI worked great! Messages clear and accurate. But I've got a failing Cypress test: 1) Booking Modal Date Picker Tests should handle date range validation correctly: AssertionError: Timed out retrying after 10000ms: expected '<span.flatpickr-day.leadDisable>' to have class 'selected' at cy.get.should.timeout (webpack://koha/./t/cypress/support/flatpickr.js:337:58) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #36 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- Created attachment 191394 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191394&action=edit BookingEnddates.png -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #38 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- Created attachment 191395 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191395&action=edit 39999000000634Booking.png -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de --- Comment #40 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Hi folks, started QA on this bug yesterday. Problem: implicit timezones - The timezone issues stem from the code being implicitly timezone-aware without declaring which timezone is authoritative. - When code uses .toISOString() or .toDate(), it performs timezone conversions as side effects rather than intentional operations. This works when browser and server timezones happen to match, but breaks otherwise. The QA failures demonstrate this: - PST browser: end date shifts +1 day - NZDT browser: end date shifts +2 days - The shift correlates directly with UTC offset Potential fix for this: the library timezone is authoritative I dug up some examples to check how other booking systems handle this, since they have the same problem: - Airbnb: Check-in/checkout times are in "local time" (property timezone)(www.airbnb.com/help/article/41) - Booking.com: "All timestamps returned by Booking.com's Demand API are in UTC... convert from UTC dynamically based on user or property location" and "Timing is based on the property's local timezone" (developers.booking.com/demand/docs/development-guide/code-conventions, developers.booking.com/connectivity/docs/reporting-api/b_xml-reporting) My understanding is that booking dates should be interpreted in the library's timezone, not the patron's. This makes sense because: - The item is physically (for common use cases right now) at the library - Pickup/return happens during library hours - Lead/trail periods align with library operations How I implemented this: - Form submission - Extract the DATE value the user selected (just YYYY-MM-DD), then send as explicit UTC boundaries using dayjs.utc() to ensure startOf/endOf operate in UTC, not browser timezone: dayjs.utc(startDate).startOf("day").toISOString() // "2026-01-20T00:00:00.000Z" dayjs.utc(endDate).endOf("day").toISOString() // "2026-01-20T23:59:59.999Z" - This preserves the date regardless of browser timezone. - Timeline display - Convert stored UTC back to library timezone using $timezone(), then use $toDisplayDate() helper to create Date objects that render consistently: const startServerTz = dayjs(data.start_date).tz($timezone()); start: $toDisplayDate(startServerTz) - This ensures staff see dates in library time, not their browser's time. - Conflict detection - All date comparisons normalized to start-of-day to avoid time-component interference. The fix works, but the timezone handling should be made more explicit: 1. UI indicator - Show "(Library time)" near the date picker so patrons in different timezones understand (conditionally, only show if needed due to tz differences) 2. API contract - Document that booking dates represent library-local days, stored as UTC 3. Future-proofing - When hourly bookings are added, the same principle applies: times are in library timezone, converted to UTC for storage This approach eliminates timezone bugs by design. I have a follow-up patch to validate the idea and to retest what surfaced in QA. What do we think? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #41 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 191746 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191746&action=edit Bug 37707: (follow-up) Fix timezone handling for cross-timezone bookings This patch fixes timezone issues that caused booking dates to shift when the browser and server are in different timezones. The code used implicit timezone conversions via .toISOString() and .toDate(), which work when browser and server timezones match but fail otherwise. QA testing showed: - PST browser: end date shifts +1 day - NZDT browser: end date shifts +2 days Make timezone handling explicit by establishing that booking dates are interpreted in the library's timezone. - Form submission: Extract date value (YYYY-MM-DD) and send as explicit UTC day boundaries using dayjs.utc().startOf/endOf('day') - Timeline display: Convert UTC to library timezone using $timezone() and new $toDisplayDate() helper for consistent rendering - Added $timezone() to expose server timezone to JavaScript - Added $toDisplayDate() to create display-ready Date objects that render correctly regardless of browser timezone To test: 1. Apply patch and run: yarn build 2. Configure a bookable item with 2-day lead and 3-day trail periods Timezone handling (PST): 3. Set browser timezone to PST (America/Los_Angeles), for example with Chrome Devtools -> Ctrl/Cmd + Shift + P -> sensors -> Location 4. Create a single-day booking for Jan 20 5. Verify the booking table shows start: Jan 20, end: Jan 20 (not Jan 21) 6. Verify the timeline shows the booking on Jan 20 only 7. Create a 3-day booking (Jan 22-24) 8. Verify the table shows start: Jan 22, end: Jan 24 9. Verify the timeline spans exactly 3 days Timezone handling (NZDT): 10. Set browser timezone to NZDT (Pacific/Auckland) 11. Repeat steps 4-9 12. Verify dates do not shift by +2 days as previously reported Test lead/trail conflict detection: 13. With existing booking on Jan 20 (trail period: Jan 21-23) 14. Attempt to create new booking starting Jan 24 (lead: Jan 22-23) 15. Verify conflict is detected (lead overlaps with trail) 16. Verify booking starting Jan 26 (lead: Jan 24-25) is allowed Test multi-item filtering: 17. On a bib with multiple bookable items 18. Create booking on item A for Jan 20 19. Open booking modal, select item B 20. Verify calendar does NOT show conflicts from item A's booking -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|39584 |40134 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39584 [Bug 39584] Booking post-processing time cuts into circulation period https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40134 [Bug 40134] Fix and optimise 'Any item' functionality of bookings -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191356|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191358|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191360|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=37707 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #191746|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=37707 --- Comment #43 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 192007 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192007&action=edit Bug 37707: (follow-up) Support lead/trail periods for 'any item' bookings When booking "any item of type X", lead/trail period handling must consider that multiple items may be available: - Track per-item conflicts instead of global conflicts - Only disable dates when ALL items of the type have conflicts - Find closest "all items booked" dates for visual feedback - Use mathematical search (180 days) to detect conflicts across month boundaries Visual feedback for 'any item' mode: - Show lead/trail periods around "all items booked" dates - These represent dates where no item of the type is available Skip redundant class-based conflict checks since mathematical detection already handles cross-month boundary cases. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #45 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 192009 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192009&action=edit Bug 37707: (follow-up) Refactor place_booking.js for maintainability Extract utility functions and reduce code duplication: - Add toInt(), startOfDay(), datesOverlap(), isDateInRange() helpers - Simplify containsAny() using Set and Array.some() - Refactor isItemAvailableForPeriod() to use new utilities - Refactor getAvailableItemsOnDate() and isDateDisabledForSpecificItem() - Extract submit handler helpers: getAvailableItemsForPeriod(), buildBookingPayload(), createTimelineItem(), showBookingError(), showBookingSuccess(), refreshBookingsTable(), setPickerDates() - Replace parseInt() calls with toInt() for consistency - Simplify modal reset handler with jQuery method chaining No functional changes - prepares codebase for future Vue conversion. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192007|0 |1 is obsolete| | --- Comment #48 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 192801 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192801&action=edit Bug 37707: (follow-up) Support lead/trail periods for 'any item' bookings When booking "any item of type X", lead/trail period handling must consider that multiple items may be available: - Track per-item conflicts instead of global conflicts - Only disable dates when ALL items of the type have conflicts - Find closest "all items booked" dates for visual feedback - Use mathematical search (180 days) to detect conflicts across month boundaries Visual feedback for 'any item' mode: - Show lead/trail periods around "all items booked" dates - These represent dates where no item of the type is available Skip redundant class-based conflict checks since mathematical detection already handles cross-month boundary cases. 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=37707 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192009|0 |1 is obsolete| | --- Comment #50 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 192803 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192803&action=edit Bug 37707: (follow-up) Refactor place_booking.js for maintainability Extract utility functions and reduce code duplication: - Add toInt(), startOfDay(), datesOverlap(), isDateInRange() helpers - Simplify containsAny() using Set and Array.some() - Refactor isItemAvailableForPeriod() to use new utilities - Refactor getAvailableItemsOnDate() and isDateDisabledForSpecificItem() - Extract submit handler helpers: getAvailableItemsForPeriod(), buildBookingPayload(), createTimelineItem(), showBookingError(), showBookingSuccess(), refreshBookingsTable(), setPickerDates() - Replace parseInt() calls with toInt() for consistency - Simplify modal reset handler with jQuery method chaining No functional changes - prepares codebase for future Vue conversion. 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=37707 --- Comment #52 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 192805 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192805&action=edit Bug 37707: (QA follow-up) Fix typo in comment 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=37707 --- Comment #54 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 192807 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192807&action=edit Bug 37707: (QA follow-up) Fix incorrect bold date expectations in Cypress test - The test for circulation rules date calculations did not account for the start date being bold, only the period endpoint dates - place_booking.js explicitly adds the selected start date to boldDates (boldDates = [new Date(startDate)]), giving it the "title" class - The verification loop checking for unexpected bold dates then failed when it encountered the start date, which was bold but not expected - Add clearZoneStart to expectedBoldDates to match actual behavior To test: - yarn cypress run --spec t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts - Verify that the "should handle circulation rules date calculations and visual feedback" test now passes 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=37707 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192800|0 |1 is obsolete| | Attachment #192801|0 |1 is obsolete| | Attachment #192802|0 |1 is obsolete| | Attachment #192803|0 |1 is obsolete| | Attachment #192804|0 |1 is obsolete| | Attachment #192805|0 |1 is obsolete| | Attachment #192806|0 |1 is obsolete| | Attachment #192807|0 |1 is obsolete| | --- Comment #55 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 192863 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192863&action=edit Bug 37707: Add bidirectional lead/trail period conflict detection Enhance the booking modal to detect and prevent lead/trail period conflicts in both directions: - New booking's lead period vs existing booking's trail period - New booking's trail period vs existing booking's lead period Visual feedback: - Highlight existing booking's lead periods (before booking starts) - Highlight existing booking's trail periods (after booking ends) - Add CSS classes for start/end boundaries with rounded corners User feedback: - Show contextual messages explaining why dates are blocked - Differentiate between lead period, trail period, and booking conflicts - Display informational messages when hovering available dates The conflict detection uses mathematical date range comparisons that work across month boundaries, not just visible calendar dates. Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #57 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 192865 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192865&action=edit Bug 37707: (follow-up) Fix timezone handling for bookings Fix date handling issues that caused bookings to shift by a day when the browser timezone differs from the server timezone: - Normalize dates to browser timezone for calendar display - Use dayjs without UTC conversion for bookingsByDate keys - Extract local date and send as explicit UTC day boundaries - Preserve user's selected DATE regardless of browser timezone Timeline display: - Convert server dates to library timezone for display - Add $timezone() and $toDisplayDate() helper functions This ensures that a booking for "June 15" displays and saves as June 15 regardless of the user's timezone offset. Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #59 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 192867 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192867&action=edit Bug 37707: (follow-up) Add comprehensive Cypress tests for bookings modal Reorganize and expand Cypress tests into three focused spec files: bookingsModalBasic_spec.ts: - Modal initialization and field interactions - Form validation and submission - Edit booking functionality - 'Any item' booking with server-side item selection bookingsModalDatePicker_spec.ts: - Flatpickr initialization and constraints - Date range validation - Circulation rules (issue length, renewals) - Lead/trail period conflict detection - 'Any item' mode date availability - Event dots for existing bookings bookingsModalTimezone_spec.ts: - Cross-timezone date display - Multi-day booking spans - Conflict detection with timezone awareness - API round-trip date preservation - Month boundary handling Add shared test utilities to e2e.js for date helpers. Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #61 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 192869 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192869&action=edit Bug 37707: (QA follow-up) Fix grammatical error Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com Keywords| |rel_25_11_candidate, | |release-notes-needed --- Comment #64 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- In my opinion this is a bugfix, not an enhancement, and should be backported at least to 25.11.x -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #66 from Kristi Krueger <kkrueger@cuyahogalibrary.org> --- We would love to see this backported. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #67 from Jacob O'Mara <jacob.omara@openfifth.co.uk> --- Thanks all, pushed to 25.11.x -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com --- Comment #69 from Jonathan Druart <jonathan.druart@gmail.com> --- t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts is badly written, obviously by AI (not advertised...) 1. 11 sql: "UPDATE systempreferences SET value = '1' WHERE variable = 'RESTBasicAuth'", not needed 2. 30 sql: "UPDATE items SET bookable = 1, itype = 'BK', homebranch = 'CPL', enumchron = 'A', dateaccessioned = '2024-12-03' WHERE itemnumber = ?", We should not do that, but build the library instead. 3. 1316 return cy.task("buildSampleObject", { 1329 return cy.task("query", { 1330 sql: `INSERT INTO borrowers (borrowernumber, firstname, surname, cardnumber, categorycode, branchcode, dateofbirth) 1331 VALUES (?, ?, ?, ?, ?, ?, ?)`, There is insertSamplePatron. Or insertObject, but the INSERT query here is not the way we write Cypress tests. 4. 1348 sql: `INSERT INTO bookings (biblio_id, patron_id, item_id, pickup_library_id, start_date, end_date, status) Added several times: then you need to write the code to generate bookings from mockData -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 --- Comment #70 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #69)

t/cypress/integration/Circulation/bookingsModalDatePicker_spec.ts is badly written, obviously by AI (not advertised...)

1. 11 sql: "UPDATE systempreferences SET value = '1' WHERE variable = 'RESTBasicAuth'",

not needed

2. 30 sql: "UPDATE items SET bookable = 1, itype = 'BK', homebranch = 'CPL', enumchron = 'A', dateaccessioned = '2024-12-03' WHERE itemnumber = ?",

We should not do that, but build the library instead.

3. 1316 return cy.task("buildSampleObject", { 1329 return cy.task("query", { 1330 sql: `INSERT INTO borrowers (borrowernumber, firstname, surname, cardnumber, categorycode, branchcode, dateofbirth) 1331 VALUES (?, ?, ?, ?, ?, ?, ?)`,

There is insertSamplePatron. Or insertObject, but the INSERT query here is not the way we write Cypress tests.

4. 1348 sql: `INSERT INTO bookings (biblio_id, patron_id, item_id, pickup_library_id, start_date, end_date, status)

Added several times: then you need to write the code to generate bookings from mockData

Do we need a follow-up bug to address this? bookingsModalDatePicker_spec.ts is currently failing in 26.05.x -- You are receiving this mail because: You are watching all bug changes.