Hourly due dates and fines ignore library closings

[Michele Morgan]

Evergreen 2.2.2

Users of hourly reserves are being assigned due times when the library is closed and are being charged hourly overdue fines when the library is closed.

Hours of Operation are set as follows:

M-Th 7:45AM - 12:00PM
F 7:45AM - 9:00PM
S 10:00AM - 9:00PM
Su 1:00PM - 12:00AM

Duration rule is set to 02:00:00 or 04:00:00

Examples of action.circulation.xact_start, due_date are:

2012-10-04 23:58:53.570663-04, 2012-10-05 00:03:01-04
2012-10-04 23:40:49.106283-04, 2012-10-05 00:03:23-04
2012-10-07 21:48:10.382301-04, 2012-10-08 00:01:19-04
2012-10-07 23:54:17-04, 2012-10-08 01:54:17-04

Examples of money.billing_ts are:

2012-10-08 02:54:17-04
2012-10-08 03:54:17-04
2012-10-08 04:54:17-04
2012-10-08 05:54:17-04
2012-10-08 06:54:17-04
2012-10-08 07:54:17-04
2012-10-08 08:54:17-04
2012-10-08 09:54:17-04
2012-10-08 10:54:17-04
2012-10-08 11:54:17-04

We have "Charge fines on overdue circulations when closed" set to FALSE

So it does appear that hourly loans and fines are ignoring closings.

[Ben Shum (bshum)]

Marking as confirmed since there have been previous reports of this bug. See bug 741070 for earlier report.

[Dan Wells (dbw2)]

We've been frustrated by this issue since coming to Evergreen, and finally have some working code to address it. I am assigning myself now, as our goal is to have the code in local production next week, and a branch should follow shortly after that.

[Galen Charlton (gmc)]

Dan, checking to see if you have a branch ready.

[Dan Wells (dbw2)]

Galen, thanks for the kick. I do have a branch for this, though it is not without issues. Known to-dos are:

1. Proper handling of hourly (i.e. not day-granular) grace periods which overlap into closed periods when those closed periods are configured to not count against grace.
2. Proper handling of hourly (i.e. not day-granular) fine intervals/grace periods whenever those periods are (potentially) long enough to cover two (or more) distinct open periods.
3. General optimization. Short fine periods can be extremely repetitive when doing the "are we open" check, so there's a lot or room for improvement when generating multiple fines for a single circulation. (If you are already generating fines at a rate matching your library's shortest fine interval, though, this optimization is moot.)

#1 exists in our environment, while #2 is purely an edge case I encountered in testing, as it is simplest to trigger with a fine interval which is longer than a day but also not day-granular (an uncommon requirement, I imagine). I'd like to get #1 sorted before putting out a pullrequest.

I'm not attending the Hack-a-way, but I do have some of that time set aside for hacking, so I'll try to get a working branch posted then.

[Michele Morgan (mmorgan)]

Just noting that, should a branch be forthcoming, I'd be more than willing to test it.

[Dan Wells (dbw2)]

Any chance of extending that testing offer to bug #1422379? The work in progress for this bug builds on the changes in that branch, and that branch has been waiting for a while now.

[Dan Wells (dbw2)]

Wow, two months ago already? Just reporting back that progress continues on this bug. My previous branch contained way too much spaghetti, so I've essentially started anew for a bit chunk of it with lessons learned. So far the new code passes my test suite while being much cleaner and easier to understand. Might even be faster, too, but I could be dreaming ;)

[Christine Burns (christine-burns)]

This issue persists in Evergreen 3.1

[Ruth Frasur Davis (redavis)]

Pinging this ticket and noting that if there's something to test, I'm available.

[Shannon Dineen (sdineen)]

Still an issue for our Sitka libraries; we are currently on 3.5, upgrading to 3.7 this year.

Commenting on this bug for Feedback Fest because we are interested in a resolution and we would be happy to test if something becomes available.

[Jennifer Pringle (jpringle-u)]

continues to be an issue in 3.9