[OPEN-ILS-DEV] Hold Overrides

[Bill Erickson]

On Wed, Oct 19, 2011 at 03:36:23PM -0400, Thomas Berezansky wrote:
> Currently there are apparently override permissions for some hold
> failure codes, but very few places that use them.
> 
> As it stands, the only place I know of to override a failed hold
> placement is the Template Toolkit OPAC. There the rule is to look at
> the error code the backend provides and check if you have permission
> to override it. If you do, enable overriding.
> 
> The backend, when overriding, just places the hold without looking.
> The backend's version of the why you couldn't place the hold error
> message is "provide a single error from the last copy we looked at
> for seeing if this hold can be placed". The problem with that is
> that there may be hundreds of copies, and each of them may have had
> one or more errors. The last copy's errors may have nothing to do
> with any of the others.
> 
> In addition, even if you place the hold with the override
> permission, that doesn't mean that the hold will ever fill. The rest
> of the hold targeting system ignores the overrides you may have.
> 
> One way to fix this is to define how permission-based hold
> overriding should work so that we can put effort towards getting
> there. To that end, I propose the following system:
> 
> 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?

> 
> In the event no potential copies are found the list of failure codes
> should be looked at, as sets. If the requestor has permission to
> override the entire set then the set (sans org unit) should be
> flagged as a potential override permission set. Preferably skipping
> the rest of the org units that the same set showed up in previously
> for checking, as that no longer matters for that set. All potential
> sets are returned to the front end.
> 
> In the front end (Template Toolkit OPAC only for now, most likely)
> the hold is reported as failed. If any sets of override permissions
> are returned then a prompt for each possible set is generated. This
> could be as simple as one permission here or there. The user would
> then have the opportunity to select zero or more override sets to
> apply to the hold to override.
> 
> The backend would be given the set of overrides. For sanity reasons
> re-checking the list of override permissions should be done, to
> ensure the requestor has them, failing due to permission failure
> even in override mode if they do not have one of the permissions.
> Possibly re-run permit tests, but have the tests told what
> permissions to override (and where the requestor has them) as
> success. When creating the hold a mapping of "activated" override
> permissions would be tied to the hold (via a mapping table?). When
> the hold is being considered for filling the list of active override
> permissions would be passed to the permit test, and those failure
> reasons would be stripped out (to potentially leave a success, if
> all failure reasons are overridden). I personally am not sure if
> permissions should be double-checked before permit tests are run, or
> if we should go with "you had permission when you placed the hold"
> instead. If the latter we may need to store the org units they had
> the permissions at when the hold was placed, in addition to the
> permissions themselves.
> 
> This would ensure that an override is, in fact, an override for the
> hold, not just an "allow you to place a hold that can never, ever
> fill" routine. It would also ensure that if you can override a hold
> you find out about it, and don't have it hidden by the last copy the
> system found being one that you can't override.
> 
> This would *not* be suitable for "allow patrons to place holds on
> age protected items" because the override code would bypass the age
> protection. In fact, this entire system likely isn't suitable for
> patrons at all, and should probably be restricted to staff use.

Agreed.  I could see it resulting in serious information overload.

> 
> There are probably major issues with the above, but I am sick of
> staring at it for now. ;)

The UI will take some thought, but I think the basic concept makes
sense.

-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