Hold ratio template that includes descendants ignores some copies

Bug #1664715 reported by Mike Rylander
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.11
Fix Released
Medium
Unassigned

Bug Description

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.

Revision history for this message
Mike Rylander (mrylander) wrote :

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.

tags: added: pullrequest
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

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

Revision history for this message
Mike Rylander (mrylander) wrote :

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!

Changed in evergreen:
milestone: 2.12-beta → 2.12-rc
Galen Charlton (gmc)
Changed in evergreen:
milestone: 2.12-rc → 2.11.4
milestone: 2.11.4 → 2.12.1
Changed in evergreen:
milestone: 2.12.1 → 2.12.2
Kathy Lussier (klussier)
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Revision history for this message
Kathy Lussier (klussier) wrote :

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.

Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Changed in evergreen:
milestone: 2.12.2 → 2.12.3
Changed in evergreen:
milestone: 2.12.3 → 2.12.4
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

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

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

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

tags: added: signedoff
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kathy Lussier (klussier) wrote :

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.

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.