Holds Ratio Reports should more accurately report available copies and include a "By Home Library" source

Bug #1925028 reported by Jason Boyer
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

There are multiple holds ratio reporting sources defined in fm_IDL.xml, some using only the holdable flags on items and locations (and therefore doesn't consult hold policies) and those that use the target_copy field of action.hold_copy_map (which do consult policies). These should be normalized so that all of them agree on what items are holdable for a bib.

Additionally, the ahcm sources currently include items pulled in from metarecord holds and holds that are frozen or captured. The trouble with including MR hold targeted items is that large numbers of items can be added to the total from different records causing sometimes wide fluctuations in the total number of items. Using frozen or captured holds in the ahcm calculation can cause problems because those holds are no longer updated, leaving stale counts when large numbers of items have been changed from holdable to not-holdable through a flag or policy change.

Finally, in addition to the existing Hold/Copy Ratio per Bib, Hold/Copy Ratio per Bib and Pickup Library, and Hold/Copy Ratio per Bib and Pickup Library (and Descendants), it has been suggested that a Hold/Copy Ratio per Bib and Home Library reporting source would be useful.

Branch coming soon with these changes.

Revision history for this message
Jason Boyer (jboyer) wrote :

Branch is here:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1925028_hcr_sources / working/user/jboyer/lp1925028_hcr_sources

Testing Notes:
If you have any existing report templates using these sources they will need to be recreated in order to see the changes. This does mean that you could potentially run the new and old reports side-by-side but that is an easy way to cause confusion, so beware if you want to try that.

Pre-patch:
1. Create a variety of holds on a single record. Freeze some, capture some, leave some alone.
2. Build a report template using one of the Hold/Copy Ratio sources that displays at least the Record Id and the number of holdable copies.
3. Run your report and make note of the number of holdable copies available for your test bib.
4. Make some of the holdable items on your test bib non-holdable and force the hold targeter to run for those holds (either set the prev_check_time back a day or more or just wait 24-25 hours).
5. Run your report again and compare the numbers for holds and holdable copies. Neither will have changed.

Post-patch:
Repeat steps 1-5 above, at step 5 the number of holds will be the same and the number of holdable copies in the output should drop by the number of items changed from holdable to not-holdable. If you created any metarecord holds in step 1 they will still be included in the number of holds for a record but no copies from any other bibs will be included in the number of holdable copies. The number of holdable copies for a bib should never be higher than the total number of copies attached to that bib. There are comments in fm_IDL.xml explaining how to change this if desired.

This work was sponsored by the Westchester Library System.

Jason Boyer (jboyer)
tags: added: pullrequest
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.8-beta
Andrea Neiman (aneiman)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Wishlist
Changed in evergreen:
assignee: nobody → Rogan Hamby (rogan-hamby)
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

worked for me, sign off pushed to user/rogan/lp1925028_hcr_sources

Changed in evergreen:
assignee: Rogan Hamby (rogan-hamby) → nobody
tags: added: signedoff
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Pushed to master. Thanks, Jason and Rogan!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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