Evergreen 3.9.1
I’ve created this pull request for a tool we use frequently at NC Cardinal to answer questions that come up with how the hold targeter behaves. What this feature does is record vital information from a hold every time that it’s reset. It’s especially useful to know this in situations where a patron or staff member wants to know why a copy wasn't chosen for a hold (ex- remote copy was chosen over a local holding). In that scenario, we can use these reset entries to see whether a hold was manually retargeted by a staff member or if it naturally timed out and was retargeted. Reset entries can be viewed in the staff client by going to a patron’s profile and bringing up the “hold details” for their hold. Blake suggested that there would be a lot of value in us sharing this code with the community.
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/lew/hold_reset_reason_entries
This setting is controlled by a new global config called “circ.holds.create_reset_reason_entries”. If that flag is disabled then no reset entries will be created.
Reset entries are stored in a new table called "action.hold_request_reset_reason_entry". This is the basic schema of that table:
ID: primary key
Hold: the hold ID
Reset reason: why the hold was reset (see below)
Note: any additional information (like the cancel cause)
Previous copy: the last item that was targeted
Requestor: the user who initiated the reset (if applicable)
Requestor workstation: the workstation of that user
I’ve created an index on the hold field so it’s quicker to retrieve them in the gui.
There are ten hardcoded “reset reasons” stored in a table called action.hold_request_reset_reason
1. HOLD_TIMED_OUT
2. HOLD_MANUAL_RESET
3. HOLD_BETTER_HOLD
4. HOLD_FROZEN
5. HOLD_UNFROZEN
6. HOLD_CANCELED
7. HOLD_UNCANCELED
8. HOLD_UPDATED
9. HOLD_CHECKED_OUT
10. HOLD_CHECKED_IN
Just like copy statuses, hold reset reasons are referenced in the src\perlmods\lib\OpenILS\Const.pm file.
This looks like a valuable feature to me. I've spent hours checking logs to answer questions about why a hold wasn't filled before also.
I'll try and test it out during bug fixing week. I read through things quickly, and the one thing that seems to be missing is adding the SQL to the seed data files for new installs to get the feature.
Some other good additions would be:
1. Release notes that describe the new feature, where it can be accessed and how to activate it.
2. Testing plan. Some of the conditions are easy enough to trigger for testing, some may be harder to setup a situation for. Any guidance for a tester is appreciated. Notes for each reset reason would be good.
3. Perl live test. I've only written one of those so far, and it can be time consuming to create. But it does provide a great way to ensure that the new feature keeps working in the future when other changes take place. I believe there are a couple examples of perl live tests that place holds that maybe be useful to look at as a starting point. Maybe just extending the hold_targeter test would work. https:/
If such a thing was voted on, I would vote to just have this enabled and not need a global setting. Unless there is a performance penalty for the retargeting process that may negatively effect large sites?