Wishlist: Ability to create circulation policies to make items due at closing

Bug #1533424 reported by Jane Sandberg
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Wishlist
Unassigned

Bug Description

Evergreen will only allow duration by hours, days, months, rather than "End of business day" or "End of day". We currently have to set a duration of 2 hours with a very generous grace period, and the receipt reflects this misleading 2-hour duration. We have many of these materials, so using the "Specific due date" for each of these transactions is much too laborious for our library. Thanks for looking in to this!

We currently use EG 2.9.1.

Tags: admin-pages
Revision history for this message
Thomas Berezansky (tsbere) wrote :

Probably too much of a pain to set up by hand, but possibly workable may be the "hard due date" functionality. A script to populate the dates ahead of time could be used.

Dunno if it supports times or just dates, though. I think the staff client interface doesn't allow times, but the database doesn't seem to be date restricted, so script-population should work. So long as the duration rule from the circ matchpoint result isn't divisible by 24 hours I think the time component from the database would be retained.

Note that I haven't actually tested this idea.

Revision history for this message
Jane Sandberg (sandbergja) wrote :

Thanks for the idea, Thomas! After testing, it looks like setting config.hard_due_date.ceiling_date = '2016-01-29 17:00:00-8', with 2016-01-29 being the current day and 17:00:00-8 being any time between 00:00 and 23:59, it will make the items due at 23:59 that day, which totally works for us!

Note that just making it due 2016-01-29 00:00:00-8 doesn't do this, nor does 2016-01-30 00:00:00-8. It seems like the hard due dates only allow the final due time to be 23:59, even if we can trick them into making things due on the current day.

Revision history for this message
Thomas Berezansky (tsbere) wrote :

Jane, as I mentioned before the 23:59 bit should only happen if the duration rule is a multiple of 24 hours. If you set the duration rule to, say, only 12 hours, or to 24 hours and 1 second even, the system shouldn't mess with the time component of the hard due date rule.

Revision history for this message
Jane Sandberg (sandbergja) wrote :

Thanks for your help! I just tried duration rules of 23 hours and 24 hours+1 second. Both ended up giving me a 23:59 due time.

tags: added: admin-pages
Changed in evergreen:
importance: Undecided → Wishlist
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

In 3.11.1, setting a duration rule of 00:00:00 also results in the due date being set to 23:59:59 for the current day.

We have laptops we checkout for the day for in library use. It would be great if the due date could be set to the circulation lib closing time.

Having them due that night at 23:59:59 works ok, but it would be better if it was the closing time for communication with the customer. It would make it a little easier to send out a notice of some sort immediately if wanted. (So far our only overdue's have been because staff don't check them in at closing though... cannot really solve that in Evergreen.)

What if the duration rule had an extra flag for due at close, or truncate to close time to handle this?

The duration part of the duration rule gets stored in the action.circulation object. Looks like we could adjust the circ->duration so it works out to being due at closing. Or adjust the due date afterwards to set it to closing. Adjusting the circ->duration might mess up renewals though... so probably it would be best to check after the due date has been generated?

=====
Notes on how the due date logic works and where the code is at.

* sub build_checkout_circ_object in Circulate.pm builds the circulation object.

* sub create_due_date in Circulate.pm performs the initial setting of the due date based on the duration rule and hard due date.
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Circulate.pm;hb=HEAD#l2459

* sub apply_modified_due_date in Circulate.pm seems like it handles adjusting due dates for closed days.
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Circulate.pm;hb=HEAD#l2349

* The trigger push_due_date_trg runs action.push_circ_due_time to push the due dates to the end of the day.
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/090.schema.action.sql;hb=HEAD#l188

Related to Thomas's possible work around, bug #1178802 , forces ceiling dates for hard due dates to be set to end of day in the admin interface. Not sure if this was moved to the Angular interface if it exists or not. But that seems to rule out manually setting hard due dates with a specific hour... unless you bypass the interface.

Revision history for this message
Galen Charlton (gmc) wrote :

Yeah, I think that if we add a set-to-closing-time flag to config.rule_circ_duration, also adding that flag to action.circulation would simplify changes to push_due_date_trg.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Thanks that makes sense.

I need to think about how this would work with renewals. Would renewals be expected to also adjust to closing time. Or would a renewal just make use of the duration. Our use case for this doesn't allow renewals.

Would the logic be that the due date gets adjusted to the library closing on the previously calculated due date? Or maybe the logic is that if the due date goes past closing, it gets adjusted to the closing time.

So a duration of 1 day with this flag set would mean the closing time of the next open day? If you wanted it to be the current day you would select a short duration.

Or maybe the flag causes the duration to be ignored, and it just means closing time of the current day? But that wouldn't allow hourly checkouts that just shouldn't go past closing...

Use Case 1: In Library Use Laptop that should be due when the library closes that day, no matter when it is checked out. Duration should be set to less than 24 hours but greater than the length the library is open so the initial due date is after closing.

Use Case 2: In Library Use Laptop that gets checked out for 2 hours at a time, but a checkout less than 2 hours before the library closes should be due when the library closes. Renewals might be allowed, but shouldn't go past closing.

Use Case 3: Item with a 1 day checkout that should be due at the end of the next days open hours. Duration should be set to >= 1 day.

Corner Cases:

Checkout happens on a day marked closed in HOO or closed dates.

Checkout happens after location is closed for the day.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.