[OPEN-ILS-DEV] Hold Overrides

[Bill Erickson]

On Thu, Oct 20, 2011 at 04:29:07PM -0400, Thomas Berezansky wrote:
> Quoting Bill Erickson <erickson at esilibrary.com>:
> 
> >>When placing a hold the backend should keep track of sets of failure
> >>codes from copies. Preferably such that each complete set is unique,
> >>perhaps by ordering them in a specific way and turning the full list
> >>into a hash key. This key should probably contain the item's owning
> >>or circ library for a point to check the permission at, or perhaps
> >>the hash value could be an array of org units for the set. Either
> >>way the permissions should be checked based on the item's owning or
> >>circ library, not the user's home or workstation OU.
> >
> >What determines which "set" a given failure code is put into?
> >
> 
> Each set is "the full set of failure codes from a single copy", but
> filtered on dupes.
> 
> So you have a test that hits 4 copies:
> 
> Copy 1, owned by OU 4:
> Fails on ITEM_AGE_PROTECTED and ITEM_NOT_HOLDABLE
> 
> Copy 2, owned by OU 5:
> Fails on ITEM_AGE_PROTECTED and MAX_HOLDS
> 
> Copy 3, owned by OU 4:
> Fails on NO_POLICY_MATCHPOINT
> 
> Copy 4, owned by OU 5:
> Fails on ITEM_AGE_PROTECTED and ITEM_NOT_HOLDABLE
> 
> You have three sets:
> 
> Set 1, from copies 1 and 4:
> ITEM_AGE_PROTECTED, ITEM_NOT_HOLDABLE - At OU 4 and 5 (perms might differ)
> 
> Set 2, from copy 2:
> ITEM_AGE_PROTECTED, MAX_HOLDS - At OU 5
> 
> Set 3, from copy 3:
> NO_POLICY_MATCHPOINT - at OU 4

Ah, ok.  When I first read this, I was picturing sets at a higher level.  
I was imagining categories of failure events or, to put it another way,
event severities.  In the UI, when the user is presented with the fact
that the hold failed, instead of picking from a list of override-able
event sets, they would pick from a much smaller set of severities.  

For example, ITEM_AGE_PROTECTED and ITEM_NOT_HOLDABLE have a severity of
1 and NO_POLICY_MATCHPOINT has a severity of 2.  If I have permission to
override events that map to severity 1, then the UI gives me 1 choice
and, if I opt to override, it overrides all event types within that
severity level.  It's really just a way to simplify the choice.

If we wanted to go that route, I think it could lay right on top of what
you're describing...

> 
> Take note that in the process of doing this I think that some of the
> legacy mappings need to be reconsidered. You may want to allow
> overriding transit range individually from the circ matrix saying
> not holdable and individually from the copy/status/location not
> holdable, but all of those return ITEM_NOT_HOLDABLE right now. Also,
> if we want to allow overrides on the copy/status/location holdable
> flags we would need to remove some of the hard-coded "skip these"
> checks that currently exist in the system (hold targeter, list of
> copies a title hold attempts, etc).
> 
> I think the same legacy mapping reconsidering needs to happen for
> circ rules too, for the record.

+1  If the general plan is to deprecate script-based rules, then the 
legacy mappings can probably just go away.

-b

-- 
Bill Erickson
| Senior Software Developer
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com