Emergency Closing Handler Should Adjust "All" Associated Fines

Bug #1818917 reported by John Amundson
124
This bug affects 25 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

Evergreen 3.2.4.

I'm reporting this bug after a lot of testing and trial & error on my part. The release notes for the Emergency Closing Handler are a little vague when it comes to fines adjustment, so I don't know if this observation is a bug or perhaps desired future development, (though I'm leaning towards the former).

NOTE: I have tested this with the library setting "Charge fines on overdue circulations when closed" set to FALSE and left empty; (it is generally left empty on our system, which allows items to NOT accrue fines when the checkout library is closed).

When an emergency closing is entered, items due during the period will have their due dates updated to the next open day. Fines accrued during the closing will also be voided IF, (and only if?), the associated due date was updated by the closing.

For example, if an item was due 2/21, and on 2/28, library staff puts in an emergency closing for 2/21 to 2/25, the item's due date will be updated to 2/26, and the fines accrued from 2/21 to 2/25 will be voided.

Alternatively, if an item was due 2/20, and on 2/28, library staff puts in an emergency closing for 2/21 to 2/25, the fines accrued on those days will not be adjusted because the item was not due during the period. As the library was closed for these these days, the fines should be reversed regardless of due date.

This distinction seems arbitrary, and fines should be reversed, (as long as settings dictate), regardless of if the item's due date was affected by the closing.

Revision history for this message
Mike Rylander (mrylander) wrote :

Hi John,

That behavior is intentional. In order to keep the development targeted and avoid getting stuck in extreme edge cases with fines, the code only looks at circs due within the closing window and holds with a shelf expire time within the window.

The prescribed method for making sure that fines are addressed during an unexpected closing has always been to use backdated (amnesty mode) check-in set to the beginning of the closure. That remains the case even with the emergency closing handler.

I think possibly voiding fines during the closing might be a good enhancement, though.

Revision history for this message
Jeremiah Miller (jeremym-t) wrote :

FWIW, relying on backdating/amnesty mode checkins doesn't work so well if one has an automated return system.

Especially if the drop hasn't been closed/locked, patrons happen to return things while the library is still closed.

Revision history for this message
Diane Disbro (ddisbro) wrote :

We closed for Covid-19 on March 18. Items due in February are now six weeks overdue, the status is changing to LOST, and patrons have bills that prevent them from using our online resources. This is a big problem. We will be closed for six more weeks.

Revision history for this message
Terran McCanna (tmccanna) wrote :

Diane - is your library system doing the change to Lost via an action trigger? If so, you can temporarily disable it through Local Admin > Notification / Action Triggers. (We have two related action triggers that we temporarily disabled - one for the action of changing the item status / creating the bill, and one that sends a message to the patron when that happens.) We'll re-enable it after we are able to reopen.

Revision history for this message
Diane Disbro (ddisbro) wrote :

Terran - I don't know what is controlling the behavior. Our org unit isn't listed for anything in Notification / Action Triggers. Equinox had to turn off our courtesy notices.

Revision history for this message
Diane Disbro (ddisbro) wrote :

Never mind! I figured it out with some help from my friends.

Revision history for this message
Terran McCanna (tmccanna) wrote :

This is causing problems with our libraries. The documentation does not match the actual behavior and even if the documentation were updated to match the behavior, having it void only some of the fines doesn't make any practical sense to patrons or to library staff.

*****************

In 3.4 and 3.6:

The current Emergency Closing Handler documentation says "Overdue fines will be automatically voided for the day(s) the library is marked closed" and "By selecting the Emergency checkbox, the system will void any overdue fines incurred for that emergency closed day or days," but that is misleading.

It is only actually voiding fines on items that were due on a closed day, but it does not void fines on items that were due *before* the first closed day.

For example, John Doe has two overdue items - one that was due on January 7 and another that was due on January 12. Both are getting daily fines on every day that the library is open, but not on days the library is closed. On January 15, an emergency closure is entered for January 10-14. This changes the due date on the second item and voids the overdue fines for the 10th-14th, but it skips over the item that was due on January 7 and leaves the fines for the 10th-14th.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
tags: added: admin-pages
tags: removed: webstaffclient
tags: added: circ-billing
removed: billing
Steven Mayo (stmayo)
Changed in evergreen:
assignee: nobody → Steven Mayo (stmayo)
Revision history for this message
Steven Mayo (stmayo) wrote :

I've taken a swing at this, and think I've gotten something working.
Branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/smayo/lp1818917-emergency_closing_adjust_all_fines

I've added to the handler a second query for circs (and reservations) that looks for all circs at the closed org that have bills during the closing.
To my understanding, the hesitancy about doing this is that money.billing and action.circulation are both massive tables, and joining between them without tight constraints tends to be super slow.
Hopefully, by running this query after the first so it has to do that fewer times (and a few other tricks) the additional slowdown is as small as possible.
In my own testing on a mirror of the PINES database, this took 10~15 seconds to process a single-day closing that touched 250 circulations. Seems roughly similar to the old behavior, I think.

Steps to Test:
[1] Find a few patrons who have overdue items with fines on them. They should have more than one item due at the same time for comparison. NOTE: Manually setting an item to be due in the past will not work properly because the patron will not have been fined for them yet. They should have been fined naturally.
[2] Check one of the patron's items in. Note the amount of fines they are charged.
[3] In another tab, go to Administration -> Local Admin -> Closed Dates Editor
[4] Create an emergency closing for the library where the patron checked out their items AFTER their item was due but BEFORE today. (Should also be before the items hit max fines)
[5] Process that closing. Make sure it finishes.
[6] Refresh the first tab. Ensure that the due date of the patron's items was not affected.
[7] Check another one of the patrons items in. Note the amount of fines they are charged - it should be less than the amount they were charged in step [2].
[8] In the second tab, create an emergency closing at the library where the patron checked out their items BEFORE the item was due. Process that closing.
[9] Check another one of the patron's items in. They should be charged the same amount as step [7].
[10] Create and process an emergency closing that INCLUDES the due date of the patron's items.
[11] Refresh the first tab. Ensure the due date of the patron's items has updated.
[12] Check one of the patron's items in. They should be charged even less than steps [7] and [9].

Changed in evergreen:
assignee: Steven Mayo (stmayo) → nobody
Steven Mayo (stmayo)
tags: added: pullrequest
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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