best-hold selection sort order labels inaccurate

Bug #1261531 reported by Angela Kilsdonk
26
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Triaged
Medium
Unassigned

Bug Description

Admin -> Server Administration -> Best-Hold Selection Sort Order

As of 2.5, it's my understanding that the staff client labels for pprox and hprox do not match the code behind these these options.

In the staff client, pprox is labeled as "Capture Lib to Pickup Lib Proximity". pprox should be labeled as "Circ Lib to Pickup Lib Proximity".

In the staff client, hprox is labeled as "Circ Lib to Request Lib Proximity". hprox should be labeled as "Home Lib to Pickup Lib Proximity".

Ben Shum (bshum)
Changed in evergreen:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

If this gets updated then the docs need to get updated also. There is a screenshot at

http://docs.evergreen-ils.org/2.7/_create_a_new_best_hold_selection_sort_order.html

That would need to be re-created.

Josh

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

The commit that changes the behavior from what is documented is at
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=036232ce17a3ff957cd33e77f664e02f61f2c80d

I'm going to try to clean this up.
Josh

Changed in evergreen:
assignee: nobody → Josh Stompro (u-launchpad-stompro-org)
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Angela, I cannot see that the pprox definition is as you describe.

"In the staff client, pprox is labeled as "Capture Lib to Pickup Lib Proximity". pprox should be labeled as "Circ Lib to Pickup Lib Proximity"."

It looks to me like the pprox is based off of actor.org_unit_proximity where a.oup.from_org = $here (Checking Location). Can you show me what your statement is based off of?

 553 my $ids = action::hold_request->db_Main->selectcol_arrayref(<<" SQL", {}, $cp_circ_lib, $here, $cp->id, $age);
 554 WITH go_home_interval AS (
 555 SELECT OILS_JSON_TO_TEXT(
 556 (SELECT value FROM actor.org_unit_ancestor_setting(
 557 'circ.hold_go_home_interval', ?
 558 )
 559 ))::INTERVAL AS value
 560 )
 561 $addl_cte
 562 SELECT h.id
 563 FROM action.hold_request h
 564 JOIN actor.org_unit_proximity p ON (p.from_org = ? AND p.to_org = h.pickup_lib)

http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm;hb=HEAD#l553

Revision history for this message
Kathy Lussier (klussier) wrote :

I can't speak to the pprox behavior, but I can confirm that the hprox behavior uses pickup lib instead of request lib based on the testing I did when the feature was added to Evergreen. Josh, you described hprox as "Home Lib to Pickup Lib Proximity" above, but shouldn't it be "Owning Lib to Pickup Lib Proximity"?

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

Kathy, I agree with you, just want to point out that the part you quoted wasn't written by me.

I think it might be nice to expand the labels to make it extremely clear like
"[hprox]Copy Owning Lib to Hold Pickup Lib Proximity"
"[pprox]Copy Capture Lib to Hold Pickup Lib Proximity"

I've got an in-progress gist for this bug (and two others that are related)
https://gist.github.com/stompro/42eb6cbe2c1db5f12324

Josh

no longer affects: evergreen/2.4
no longer affects: evergreen/2.5
tags: added: documentation
Revision history for this message
Gina Monti (gmonti90) wrote :

Bumping this bug since it's docs related.

When I go to the latest 3.11 test server, Best-Hold Sort Order Configuration still lists 'Capture Lib to Pickup Lib Proximity' and 'Circ Lib to Request Lib Proximity'.

Is this changing? If so, then the GUI needs to for the docs to replicate it.

I will make one change to this page though since there's an outdated screenshot, but that will be in a separate bug ticket.

Changed in evergreen:
assignee: Josh Stompro (u-launchpad-stompro-org) → nobody
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.