hold targeter sorts proximities alphabetically, not numerically
Bug #1511828 reported by
Galen Charlton
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.7 |
Fix Released
|
Medium
|
Unassigned | ||
2.8 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
When the hold targeter calculates the list of proximities of eligible copies from the hold's pickup library, it then looks for capturable copies that are closest by sorting by ascending proximity...
ASCIIbetically.
This can lead to exactly the wrong outcome, especially if org unit proximity adjustments are in use. For example, if a proximity ends up being adjusted up to (say) 15 or 100 to discourage associated copies from being targeted, since "15" < "2" (or "4", etc.), those copies end up being preferred over ones whose proximity value is numerically lower.
Evergreen 2.7+
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
assignee: | nobody → Josh Stompro (u-launchpad-stompro-org) |
Changed in evergreen: | |
importance: | Undecided → Medium |
assignee: | nobody → Galen Charlton (gmc) |
milestone: | none → 2.9.1 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I can confirm that we are seeing this problem on 2.8.4.
We wanted a hard priority order for all our branches in two system, and we were using a 100 point bump for cross system hold proximity.
The targeter was first targeting copies at 100+ level proximity.
Josh - Lake Agassiz Regional Library