https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42790 Bug ID: 42790 Summary: Bookings tab: action improvements Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com This patchset improves the patron and biblio bookings tabs by unifying the available actions across both displays, syncing due dates with booking end dates at issue time, and introducing a booking-aware Extend action for issued bookings. Depends on: Bug 41898 (Booking status lifecycle: rename and extend) === 2.1 Unified action set across Patron and Biblio bookings displays === Both the Patron bookings tab and the Biblio bookings page show the same actions, gated on booking status and the logged-in user's permissions: Status | Edit | Cancel | Checkout | Extend new | manage_bookings | manage_bookings | circulate | â issued | â | â | â | circulate completed | â | â | â | â cancelled | â | â | â | â The Patron bookings tab currently shows only Cancel; it gains Edit and Checkout. The Biblio bookings page currently shows Edit, Cancel, and "Transform to checkout"; "Transform to checkout" is renamed Checkout and shortcuts to the checkout screen pre-populated with the patron and item. === 2.2 Due date sync at AddIssue === When a booked item is checked out, AddIssue uses booking.end_date as the default due date. If staff override the due date at checkout time, the override is synced back to booking.end_date server-side, keeping the booking and the checkout in sync from the moment of issue. === 2.3 Booking-aware extension for issued bookings === An Extend button appears in the Actions column for issued bookings. It opens a modal containing: - The current booking end_date - The current checkout date_due from the embedded issue record - A date picker that visually blocks dates where another new or issued booking exists for the same item - A Confirm button On confirm, a single API call handles all updates server-side: 1. Validates the new date against the maximum booking period 2. Checks for conflicting bookings for the same item 3. Updates date_due on the linked checkout 4. Updates end_date on the booking The Extend button is only visible to users with circulate permission. === 2.4 Checkout link and due date display for issued bookings === For rows with status = issued, the Item column additionally shows the checkout due date and a link to the checkout record. Staff can see at a glance when the loan is due back and navigate to it without leaving the bookings tab. === 2.5 Visual row indicators for uncollected past-window bookings === new bookings where start_date < today receive a table-info row class to highlight that the booking is awaiting collection. new bookings where end_date < today receive a table-warning row class to highlight that the collection window has passed. === Test plan === 1. Apply Bug 41898 patches first. 2. Create a booking for a patron on a specific item. 3. Confirm the Patron bookings tab shows Edit, Cancel, and Checkout actions for the new booking; Biblio bookings page shows the same. 4. Click Checkout â confirm it pre-populates the checkout screen with the patron and item; confirm the due date defaults to the booking end_date. 5. Override the due date at checkout; confirm booking.end_date is updated to match. 6. Confirm the issued booking shows the due date and a checkout link in the Item column on both tabs. 7. Click Extend on the issued booking; select a new date; confirm both date_due and booking.end_date are updated. 8. Create a subsequent booking for the same item and confirm its start_date is blocked in the Extend date picker. 9. Advance the clock past a new booking's start_date; confirm the row receives the table-info highlight. 10. Advance past end_date; confirm the row receives the table-warning highlight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.