wishlist: allow libraries to define automatically-applied custom penalties

I have pushed a branch to https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2006971-custom-system-penalties that embodies the above. It includes Bill Erickson's script from bug 1944986 that allows on-demand recalculation of penalties for patrons on the server side, with some additions to support the new custom penalty org settings, and to allow using the patron's home library as the context for penalty calculation rather than the home location of the staff user supplied to the script.

Was testing the workflow on butternut for today, and I'm not seeing the custom penalties in the library settings.

Hi Elizabeth - do you mean you're not seeing the settings themselves (Custom PATRON_EXCEEDS_CHECKOUT_COUNT penalty, etc.) or that you're not seeing values?

I can confirm I am seeing the settings as expected on butternut but I won't have a chance this morning to test more.

Hi Elizabeth, you're right; only the backend half of that fix was applied. I've added the missing bits to butternut and it's ready for another try.

My bad! I must've tested in the few moments between when Jason updated the server & when he updated LP :)

Apologies, Elizabeth!

Is this issue blocked by the discussion in bug 1944986? https://bugs.launchpad.net/evergreen/+bug/1944986/comments/5

Or does the addition of allowing the script to target specific penalties resolve that somewhat?

Josh

Thanks! I see the custom penalties listing in the library settings now. I set a new standing penalty, ID 101 and set it in Group Penalty Threshold ID 5 for org unit BR1. In the library settings, I assigned it to
Custom PATRON_EXCEEDS_OVERDUE_COUNT penalty.

I'm logged in as admin at BR1. Patron, 99999313973, has 4 items overdue. I refreshed the penalties and nothing triggered. I paid a bill and it didn't trigger the penalty either. Everything worked when we did our individual testing so I'm wondering if I missed a step.

Josh- yes, this development still needs the resolution to the bug 1944986 for it to be fully functioning.

Hi Josh,

Bill's concern exists in the current, regardless of the batch penalty script.

As you note, the script as extended allows us to avoid the problem in a couple ways: first, by specifying which penalties to recalculate (i.e., don't record the calculation the collections warning in batch) and, second, by accepting an arbitrary list of users to regenerate penalties against. That allows us to target collections warning batch generation to those users that, say, are not already fully in collections and have not had the warning penalty "recently".

Hi Elizabeth,

It looks like the reason you're not seeing the penalties recalculate is that the circulations for that patron that are overdue are all at BR3, but the group penalty threshold is configured for just BR1. IOW, the circs are out of scope since BR3 isn't included in the full-path org list for the threshold owner (BR1).

If you want BR1 to have Fine_Free_Blocks_Circ_Renew applied for circs that occur anywhere, just make CONS the group penalty threshold owner ("Org Unit").

Here's some docs to help with this. Files are in asciidoc so you'll probably want to use a viewer to read them (I like https://asciidoclive.com).

Custom Penalty info is throughout both docs, but primarily after line 127 in the lsa-standing_penalties file.

Custom penalties info on lines 163-169

Thanks Mike. I knew it had to be something simple. That fixed it for my testing.

I have tested this code and consent to signing off on it with my name, elizabeth davis,
and my email address, <email address hidden>.

Speaking for PaILS, we're comfortable with combining this with the work on 1944986 (we tested it both on Butternut and previously on another Equinox server) -- we should add the fact that staff-archived penalties can be re-instated to the documentation; I don't think that the reverse (that a recalculation script would NOT apply penalties that had been manually archived if the conditions still existed) would be a desirable behavior.
(cross-posted on 1944986 and 2006971)

For anyone currently testing, I've force-pushed an update to the branch that protects it against bugs in older versions of the library settings editor, which quoted numbers stored in the value that come from the pkey of linked object settings.

No behavior is changed, it's just the addition of BTRIM() calls to remove the double-quotes.

Are the commits from the patron penalty batch updater script in this branch necessary, or can they be removed for review?

The additional of --include-penalty flag greatly reduces my concerns noted in bug #1944986.

Patches reviewed with some additional light testing. Sign-offs added. Merged to EG master for 3.11.

Thanks All!