Hold ratio template that includes descendants ignores some copies

[Mike Rylander]

The relatively new report template "Hold/Copy Ratio per Bib and Pickup Library (and Descendants)" only includes copies that are at locations that are actually pickup libraries of holds. For instance, if you have two branches (A and B) in a system, each with 10 copies attached to a bib, but a hold only at branch A, the ratio calculated at the system level sees 10 copies rather than twenty. This has the effect of inflating the hold side of the hold/copy ratio.

Forthcoming is a branch to correct this issue by adjusting the SQL used as a source.

[Mike Rylander (mrylander)]

Branch available here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1664715-hold-ratio-fix

This is in use in production at one site currently, after going through testing for several days.

[Josh Stompro (u-launchpad-stompro-org)]

Mike, I think this partially resolves my bug about this issue - https://bugs.launchpad.net/evergreen/+bug/1627231

Does this address how meta holds are handled at all? I can create a separate bug for the meta hold issue so my duplicate bug can be resolved.

Josh

[Mike Rylander (mrylander)]

Josh,

I didn't see your bug when I entered this, sorry. It does address the "title and smaller" issue of missing copies. It does not address the M-type hold issue, however. That will probably take some trickery ... probably an alternate definition for rhrr that holds an array of bibs instead of a pointer to exactly one bib.

IMO, that's separate from the "missing copies at pickup libs with no hold" issue. If you want, I think it would be fine to trim the description on your bug to just the M-type hold issue and work on that over there.

Thanks!

[Kathy Lussier (klussier)]

I had trouble replicating the problem reported in this bug. I'm removing myself as the assignee to allow somebody else to take a look at the branch. Or, if Mike or Josh provides a test plan, I can take another crack at it.

I basically had a record with two holds with a pickup location of BR1. There were 6 copies attached to the record, 1 belonging to BR1, 1 belonging to BR2, and four belonging to SL1. The report for this record showed 6 active copies and a ratio of .333, which is what I expected. This initial testing was done on a system without the patch.

[Josh Stompro (u-launchpad-stompro-org)]

Kathy, I just tried this on a fresh master install and I can see the issue.

Using the Concerto data - place two holds on bib id 210 (Harry potter and the goblet of fire) with a pickup location of BR1 for both of them.

Create a report for the Hold/Copy Ratio per bib and pickup library (and Descendants). Set the Pickup Library to SYS1 for the constraint.

The report shows that the holdable copy count at pickup lib and its descendants is zero, resulting in an infinite ratio.

There are two copies at BR2 that are holdable, but because there are no holds there, they don't get counted. If I add one hold with a pickup location of br2 then they show up when I re-run the report.

When you were testing, were you looking at the "* at pickup library and its descendants" fields instead of the "* everwhere" fields?

Josh

[Josh Stompro (u-launchpad-stompro-org)]

I tested this change and can confirm that this fixes the issue for me. After this fix was installed I see the results I would expect in the test mentioned in my previous comment.

I found out something that I hadn't realized before, that the SQL from the changed field mapper definition is stored in the reporter template. So after this change is made, all templates/reports based on this data source need to be re-created for the change to take place. I wonder if that warrants a changelog entry? When I was trying to test this I was trying to just re-run the report after the FM change was applied, but I kept getting the same results as before the patch. I tried cloning the template, but that also resulted in the same bad output. Only after I completely started again with a new template did I see the correct results.

I'm wondering if I need to check our production system for report templates that contain old queries now.

Signoff Branch -
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1664715-hold-ratio-fix-signoff

[Kathy Lussier (klussier)]

Thank you Mike and Josh! I've merged the branch to master, release 2.12 and release 2.11.

I added an upgrade note to the commit message that addresses the need to re-create templates. I'll also add that note to the point release notes.