[OPEN-ILS-DEV] Hold Overrides

[Thomas Berezansky]

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.

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.

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

Thomas Berezansky
Merrimack Valley Library Consortium