[OPEN-ILS-DEV] Holds selection_depth Best sort order usage

Josh Stompro stomproj at exchange.larl.org
Fri Nov 13 12:10:42 EST 2015


Mike, thanks for the info.    I think I get it, I'll update the docs so it is clear that the sort is now ascending (shallower/broader first).

The fact that the custom-best-hold-selection.txt techref currently says that the Traditional sort for depth was (deeper/narrower first) is what made me think it was wrong.  I'll add a note that says the sort was changed.

Traditional
~~~~~~~~~~~
  . 'pprox' - Proximity of capturing location to pickup library
  . 'priority' - Group hold priority
  . 'cut' - Hold cut-in-line
  . 'depth' - Hold selection depth (deeper/narrower first)
  . 'rtime' - Hold request time

Josh Stompro - LARL IT Director

-----Original Message-----
From: Open-ils-dev [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Mike Rylander
Sent: Friday, November 13, 2015 9:00 AM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] Holds selection_depth Best sort order usage

Josh,

It's not a bug but an intended behavior.

If an installation uses hold boundaries, either hard or soft, but particularly hard, then restricted holds will be the rule and not the exception.  In those cases, where 0-depth holds are the rarity (and when hard boundaries are in use, forced by staff for specific
situations) you would want those to take precedence.  Also, filling holds from the widest pool is preferable in any case.  Thus the ascending order-by clause.

If, instead, an installation does not use hold boundaries, depth-restricted holds would be very uncommon.  Indeed, I can't think of a reason why staff would forcibly depth-restrict individual holds (though it is possible for them to do that).  While conceptually in this case a descending sort makes sense, it would also have no practical effect because there would be no depth-restricted holds.

Does that help clarify things?

--
Mike Rylander
 | President
 | Equinox Software, Inc. / The Open Source Experts  | phone:  1-877-OPEN-ILS (673-6457)  | email:  miker at esilibrary.com  | web:  http://www.esilibrary.com



On Thu, Nov 12, 2015 at 5:13 PM, Josh Stompro <stomproj at exchange.larl.org> wrote:
> Thanks Jason, I think that the ordering of the selection_depth must be a bug.  I can see how it would make sense to prioritize branch depth over system, and system over consortium if soft hold boundaries are in effect. Fill the holds that can only be filled locally first, then fill the holds that can only be filled in the same system, then any. But I don't get why doing it the opposite way (which it is currently doing) would make sense.
>
> Would someone that uses soft boundaries care to share their opinion please.  Has anyone that uses soft boundaries noticed that the holds with a selection_depth of 0 get higher priority than others?  If you have depth included in your sort order.
>
> I'll file a bug and submit a fix if someone can confirm that the sort should be descending not ascending.
>
> Josh Stompro - LARL IT Director
>
>
> -----Original Message-----
> From: Open-ils-dev 
> [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of 
> Jason Stephenson
> Sent: Thursday, November 12, 2015 8:53 AM
> To: Evergreen Development Discussion List
> Subject: Re: [OPEN-ILS-DEV] Holds selection_depth Best sort order 
> usage
>
> Josh,
>
> My understanding is that depth is mainly used with holds boundaries.
> It prevents holds from being filled from outside the current boundary.
>
> NCIPServer also uses it to place title holds that can only be filled by a specific branch.
>
> I imagine it is necessary in the best hold sort order when boundaries are in effect. When they are not in effect, then the depth is likely to be 0 and have little effect on the sort order.
>
> HtH,
> Jason
>
>
> --
> Jason Stephenson
> Assistant Director for Technology Services Merrimack Valley Library 
> Consortium
> 4 High ST, Suite 175
> North Andover, MA 01845
> Phone: 978-557-5891
> Email: jstephenson at mvlc.org
>
>


More information about the Open-ils-dev mailing list