- Booking::store runs item-level and biblio-level clash
detection unconditionally on every call
- During checkout, C4::Circulation sets the booking status to
'completed' and calls ->store(), which triggers clash checks
- Combined with false positives from Biblio::check_booking
(e.g. checkouts on non-bookable sibling items inflating the
unavailable count), this throws
Koha::Exceptions::Booking::Clash resulting in a 500 error
- Running clash detection on a terminal transition is
unnecessary regardless; skip it for cancelled/completed
- Add _is_final_status_transition() helper that inspects the
dirty columns to detect completed/cancelled transitions
- Guard both clash detection blocks with the new helper
To test:
1. Have a biblio with two items: one bookable, one not
(bookable = 0).
2. Create a booking on the bookable item.
3. Check out the non-bookable item to a patron.
4. Check out the bookable item to the booking patron (this
triggers the completed transition via C4::Circulation).
5. Without the patch: 500 error from
Koha::Exceptions::Booking::Clash.
6. Apply the patch.
7. Repeat steps 2-4.
8. Verify the checkout succeeds and the booking transitions
to completed.
9. Run: prove t/db_dependent/Koha/Booking.t
and confirm the new subtest "store() skips clash
detection on terminal status transition" passes.
Sponsored-by: Büchereizentrale Schleswig-Holstein <https://www.bz-sh.de/>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch implements an algorithm for selecting the item that would
leave the largest gap after the proposed booking to maximize the
opportunity for future bookings.
Key Changes:
Koha::Booking:
- Added set_itemtype_filter() method for transient itemtype parameter
- Added _select_optimal_item() method using single aggregated query
* Groups bookings by item_id with MIN(start_date)
* Selects items with no future bookings (optimal)
* Among items with bookings, selects one with latest next booking
* O(1) complexity - single database query with GROUP BY
- Updated _assign_item_for_booking() to use optimal selection
* Filters by itemtype when itemtype_id is provided
* Replaces previous random selection (RAND())
API Changes:
- Added itemtype_id parameter support to add() endpoint
- Added itemtype_id parameter support to update() endpoint
- Validates exactly one of item_id or itemtype_id is provided
- itemtype_id is transient - not persisted to database
- Extracted and applied via set_itemtype_filter() before store()
Architecture:
- itemtype_id is NOT a database column (transient only)
- Used as selection criterion, then discarded
Test plan:
1. Apply patch and restart services
2. Create "any item" booking via staff interface
3. Verify item with longest future availability is selected
4. Test via API with itemtype_id parameter
5. Verify itemtype_id is not persisted to database
6. Run t/db_dependent/Koha/Booking.t
7. Run t/db_dependent/api/v1/bookings.t
Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a booking_id field to the issues and old_issues tables
to create a linkage between checkouts and the bookings that generated
them. When a patron with a booking checks out the reserved item, the
checkout is linked to their booking and the booking status is updated
to 'completed'.
The booking_id is preserved during renewals and when checkouts are
moved to old_issues upon return.
Database changes:
- Add booking_id column to issues and old_issues tables
- Add foreign key constraints to maintain referential integrity
Test plan:
1. Apply the database update
2. Restart services
3. Create a booking for a patron
4. When the patron checks out the booked item:
a. Verify the checkout links to the booking (booking_id is set)
b. Verify the booking status changes to 'completed'
5. Renew the checkout
a. Verify the booking_id is preserved after renewal
b. Check the database: SELECT booking_id FROM issues WHERE issue_id = X
6. Return the item
a. Verify the checkout moves to old_issues
b. Verify the booking_id is preserved in old_issues
7. Test the new Koha::Booking methods:
a. For a booking with a checkout, verify $booking->checkout returns
the correct Koha::Checkout object
b. For a booking with an old checkout, verify $booking->old_checkout
returns the correct Koha::Old::Checkout object
8. Test the API:
a. Verify checkout endpoints include booking_id in responses
b. Verify the booking relationship can be embedded using
x-koha-embed: booking
9. Run the test suite:
prove t/db_dependent/Circulation.t
prove t/db_dependent/Koha/Booking.t
prove t/db_dependent/Koha/Checkout.t
NOTE: I also thought about the inverse: linking to a checkout from the
booking, but as Koha is a circulation centric system, this approach makes
more sense in my opinion. I also thought about bidirectional linking via
FKs but that is too much maintenance overhead (and potential error source)
that we don't need. The inverse lookups should still be performant through
the FKs.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We were repeating some code for the PATCH endpoint instead of using the
existing update handling code. This lead to two issues:
1) We weren't catching status updates on standard updates, only the
patch.
2) We were limiting the PATCH endpoint to just status updates when it
could happily be used for other fields too.
This patch removes the introduction of the 'edit' method from both the
REST controller and the corresponding object and moves the logic into
the store method of the object where it's easily testable.
We also DRY out the notice sending code a little for re-use.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If all we're doing is calling SUPER, then we don't need to wrap ;P
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
In the spirit of the current movement for more modern JS, the refactor tries to limit jQuery usage.
Test plan:
1) Create a booking on a bookable item
2) Cancel it and see that it's simply deleted
3) Apply the patch and run “restart_all”.
4) Repeat the same cancel operation and see that it's still there, albeit with a different appearance.
5) Try the filters in the table
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With the integration of the new status column for bookings, it would be preferable to keep the booking in database and simply change its status to 'cancel' when you cancel it via the action button or the timeline.
So I've added partial updating via the API with a new PATCH method to partially edit a booking. It is currently active for status changes.
Graphically, this translates into the disappearance of the action buttons if the booking has already been canceled, although it remains visible in the table and timeline (the style is a proposal for the moment, intended simply to graphically differentiate a canceled booking from others).
I've also added a filter to the filter_by_active method to exclude cancelled bookings.
Test plan:
1) Create a booking on a bookable item
2) Cancel it and see that it's simply deleted
3) Apply the patch and run “restart_all”.
4) Repeat the same cancel operation and see that it's still there, albeit with a different appearance.
5) Try the filters in the table
Sponsored by: BibLibre
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply the patch
2) Include the sample notice, e.g. run 'reset_all' on ktd
3) Create a booking
4) Look into the borrower notifications
5) Confirm the notice has been generated
6) Run t/db_dependent/Koha/Booking.t
Signed-off-by: LEBSimonsen <simonsen@bz-sh.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Büchereizentrale Schleswig-Holstein <https://www.bz-sh.de/>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We should use the notice from the library that initiated the action that
triggered the notice. This should be available to us always in the
userenv.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Büchereizentrale Schleswig-Holstein <https://www.bz-sh.de/>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Thinking about the future, some libraries may wish to use the
old_booking object details in their notice so I opt to pass it into
GetPreparedLetter here to support that.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Büchereizentrale Schleswig-Holstein <https://www.bz-sh.de/>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is a first draft. When reading your initial statement again I'm asking myself whether
a changed itemnumber is relevant to the patron.
The way I see it, the relevant fields are:
- pickup_library_id
- start_date
- end_date
But maybe I'm not seeing it.
To test:
1) Apply the patch
2) Make an item bookable
3) Add a booking for a given patron
4) Check the patron notices tab, should not contain any notices
5) Change either start date, end date or pickup library and save
6) Check the patron notices tab, should contain a notice with the updated details
7) Run the tests under t/db_dependent/Koha/Booking.t
8) Sign off
Signed-off-by: LEBSimonsen <simonsen@bz-sh.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Büchereizentrale Schleswig-Holstein <https://www.bz-sh.de/>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It makes sense not to introduce mapping code if there's no reason for it.
Accordingly the the columns are now of type DATETIME instead.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sticking to API guidelines, this adds the creation_date and
modification_date fields to the api definitions and the required
to_api_mappings for those fields to be properly populated.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
I generally push for contextual use of accessors in TT notices and try
to reduce extra lookups.
In this case we can access the pickup library branchname directly using
the pickup_library relation available to us in the booking object we
pass.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the logic to pass the object to be deleted through to
GetPreparedLetter.
This way, as we add fields and accessors to the object in the future,
they will automatically become available to the notices.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When a booking is cancelled, patron received an email based on specific
letter.
Test plan:
1) Create a letter with code "BOOKING_CANCELLATION" on "Notices and
slips" tool.
2) Add booking or go on item already booked in advance.
3) Cancel it
4) Verify in message_queue table directly or go on patron page and click
on "Notices" tab section.
Sponsored by: Association de Gestion des Œuvres Sociales d'Inria (AGOS)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sponsored-by: Cuyahoga County Public Library
Signed-off-by: Lisette Scheer <lisette.scheer@bywatersolutions.com>
Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This routine really belongs inside Koha::Booking rather than
Koha::Biblio. This patch moves it there, renames with _ to highlight
it's private nature.
Test plan
1) Confirm that t/db_dependant/Koha/Booking.t still passes, specifically
the 'store' test.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds tests for the Koha::Booking->store method.
Test plan
1) Run t/db_dependent/Koha/Booking.t and confirm they all pass
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Another method left behind from an earlier iteration.. not actually
called anywhere in the final submission in Koha.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the logic to ensure we always assign an item at the
point of booking instead of assuming we can assign the item at fulfilment time.
This makes the logic significantly simpler on the client when trying to
calculate available dates.
Test plan
1) Attempt to create a new booking using the 'Any item' option in the
modal
2) Note that upon placing your booking you are assigned an item for that
booking.
NOTE: We add a FIXME to the client code to highlight something to test
when/if someone decides to have another try and moving the item
assigment to just in time as aposed to up front.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Janet McGowan <janet.mcgowan@ptfs-europe.com>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds new Koha::Object based classes for bookings logic and
adds API controllers to expose the new bookings data via the REST API's.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Janet McGowan <janet.mcgowan@ptfs-europe.com>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Paul Derscheid
Martin Renvoize
Tomas Cohen Arazi
Koha Development Team
Martin Renvoize
Thibaud Guillot