Emergency closing handler

Bug #1766716 reported by Mike Rylander on 2018-04-24
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

Sometimes it's impossible to know ahead of time when a branch may need to be closed, and backdating or amnesty mode may not work well in some situations. For those situations where forcibly adjusting due dates and fines, as well as potentially alerting patrons to the changes, is required, we offer the Emergency Closing Handler. From the commit message on the forthcoming branch:

Staff are provided with interfaces and mechanisms to create library closings that, in addition to affecting future circulation and booking due dates, and hold shelf expirations, will automatically move existing circulation and booking due dates and hold shelf expiration times. This new functionality is conceptually described as Emergency Closings and business logic implementing it as the Emergency Closing Handler. It contains additions and adjustments to the user interface, business logic, and database layers. Access to this functionality is available through the Closed Dates Editor interface in the staff client which has been ported to AngularJS.


This development has created new business logic code to inspect, in real time, existing circulation, booking, and hold records, and modify such date and time stamps so that the circulation, booking, or hold will end in the same state it would have if the closing had existed at the time the circulation or booking occurred, or the hold was placed and captured. Of specific note, hourly loans will have their due date adjusted to be the end of the day following the closing.

When the Emergency Closing is saved, any fines accrued during the closing may be voided, as settings dictate, with the exception of circulations that have been marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE circulations with due dates that fall within the Emergency Closing, no fine adjustment will be applied. Emergency Closing processing is permanent, and cannot be rolled back.

This functionality is explicitly initiated by staff action. If staff do not request an Emergency Closing, existing circulations, bookings, and holds will not be processed and adjusted. However, if staff request any Closing that starts nearer in time than the length of the longest circulation duration configured for use in the Evergreen instance they will be prompted with the option to create the closing as an Emergency Closing.

Action/Trigger hooks have been created for circulations and bookings that are adjusted by the Emergency Closing Handler. These will facilitate the creation of notifications to patrons that the due date has changed and to alert them to potential changes in accrued fines.

Booking start dates are explicitly ignored in this implementation. Because an Emergency Closing is, by its nature, an unexpected event, it will be up to staff to address any bookings which intersect with a new Emergency Closings. Reports can be used to identify booking start dates that overlap with a closing and that may require staff intervention.

Staff requsting and Emergency Closing must have the new EMERGENCY_CLOSING permission.

Galen Charlton (gmc) on 2018-05-03
Changed in evergreen:
importance: Undecided → Wishlist
milestone: none → 3.2-beta
Kathy Lussier (klussier) wrote :

I loaded this branch on VM with a clean Evergreen install. When I navigate to the login page for the web client, the CSS isn't working properly. I'll add a screenshot to this comment that shows what I'm seeing.

I also see the following message in the Chrome browser console:
GET https://mlnc2.noblenet.org/js/ui/default/staff/build/css/evergreen-staff-client-deps.0.0.1.min.css net::ERR_ABORTED

Galen Charlton (gmc) on 2018-05-09
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

Kathy, it looks like the patches for bug 1739803 broke the minification of CSS, so flipping the default value of EXPAND_WEB_IMPORTS on the staff config.tt2 (as Mike's patch series does) no longer works. I'll file a separate bug for that, but for the purpose of testing emergency closing handler, please try this branch (which is also rebased against master as of today):


Jane Sandberg (sandbej) wrote :

Small question: why is the section for creating an emergency closing called "Possible Emergency Closing"? Why not just "Emergency Closing"?

Andrea Neiman (aneiman) wrote :

Hi Jane -- what I think you're seeing is an alert notifying you that the closing you are creating is potentially an emergency closing. This alert is generated if the closing date is nearer in time than the longest configured circulation duration of your EG instance. It's just to let the user know "Hey, you may have due dates within this period, do you want to create this as an Emergency Closing?"

If you set the closing date farther in the future, you should no longer see this alert.

Hope this helps!

Jane Sandberg (sandbej) wrote :

In testing this, we ran into a small usability issue. The "process immediately" checkbox shows up (but is greyed out) even for closed dates far in the future. Our circulation supervisor felt nervous about not checking this, since it's not clear that it applies only to emergency closures; she thought it might apply to the closed date as a whole. Rather than greying it out when Emergency is unchecked, can we just make it disappear? Or change the language so that it's clear that the "process immediately" checkbox only applies to emergency closure processing (e.g. "Process emergency closure immediately")?

We're also not sure of the use case for *not* checking process immediately. When would a library want an emergency closing that is not processed right away? If it is not processed right away, when is it processed?

Additionally, we were not sure what the "Circulations: 4 / 4" indicator means in the Emergency Closing Processing Summary. Does this mean that Evergreen attempted to extend 4 due dates and succeeded in all 4? Or does it mean something else?

We really like this feature so much! Thanks for all your work on it, Equinox.

Andrea Neiman (aneiman) wrote :

Hi Jane -- thanks for your comments & your thorough testing! We will be submitting documentation along with this code which explains the concerns you raised.

The idea behind making process immediately a checkbox was to allow sites to go back and process an existing closing as an emergency closing. If a closing is created without "process immediately" checked, none of the emergency closing stuff (fines voiding, due dates shifting, etc.) will occur until a staff member goes back to check the "process immediately" box and then save.

You are correct that "Circulations: 4/4" means that 4 relevant circulations were found for that emergency closing, and 4 were successfully processed (due dates moved, fines voided, etc.)

Jane Sandberg (sandbej) wrote :

Hi Andrea. Thanks for all your helpful explanations!

I created a branch with some small changes to the Add Closing modal with some small changes that address the confusions we had when testing this out:

1) I changed the "Process immediately" label to "Process emergency closing immediately".
2) I changed the "Possible emergency closing" note to a smaller label located near the date picker that says "This is a possible emergency closing".

This branch also rebased from master.


Galen Charlton (gmc) on 2018-06-18
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Bill Erickson (berick) wrote :

Eyeballed code, but was unable to install the base schema, because of PG errors in the seed data file. Error log attached.

Jane Sandberg (sandbej) wrote :

I think I messed up the seed data in my branch -- apologies. I think Galen's branch should be good.

Bill Erickson (berick) wrote :

Confirmed Galen's branch installs cleanly.

I was able to successfully apply an emergency closed date using seed data. Confirmed circ due dates were extended as expected.

Great feature!

I have pushed a new branch based on Galen's branch:

1. Contains sign-offs for existing commits.
2. Rebases to master to pick up the latest permission ID.
3. Adds a commit to fix a column name thinko in the closed dates retrieve-all API (emergency => emergency_closing). This allows the dates to appear correctly in the XUL client (FWIW).


My only question is whether we need to display the close times for "detailed" closings. They do display in the XUL client.

Otherwise, I'm ready to merge after getting one last sign-off on my commit and one more general install test, given the SQL-shuffling rebase. I tested the base install, but not the upgrade script.

Changed in evergreen:
status: New → Confirmed
Mike Rylander (mrylander) wrote :


The time display issue is addressed here:


Basically, I used one filter too deep, and the default format needed to be copied onto the item, since there's no scope access (where $root.egDateAndTimeFormat lives) in templates.

Bill Erickson (berick) on 2018-07-26
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Did some more tests, confirmed the detailed dates appear as expected in the grid. Thanks Mike and all. Pushed to master.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Bill Erickson (berick) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers