TPAC option to automatically override patron hold failure events

[Bill Erickson]

In some cases, systems may not want their patrons to be required to manually override a failed hold that the patron has permission to override. The solution is an org unit setting that forces an alway-override mode for hold placement for patrons in the catalog. To be clear, only events the patron has permission to override will be overridden. Regular blocks and non-overridable hold events will still result in hold placement failure.

Code pushed to user/berick/tpac-auto-override-checked-out-hold @ working

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/tpac-auto-override-checked-out-hold

* Don't let the branch name mislead you, the code is not specific to one type of event.

See also for reference #1003129.

[Thomas Berezansky (tsbere)]

As a side effect this branch would ensure that patrons are never subject to hold rules at hold placement while the option is turned on, as open-ils.circ.holds.test_and_create.batch doesn't check if the hold is possible when in override mode. Thus patrons could place a lot of holds that they shouldn't be allowed to, and that will likely never fill.

[Bill Erickson (berick)]

I believe this is actually an oversight / bug in circ.holds.test_and_create.batch (which is a fairly new API call). Traditionally, the hold-is-possible checks have no notion of an override and overrides only occur (from the client) after the is-possible checks have successfully completed and the user received an override-able event. My hunch is that the code is skipping the is-possible checks in override mode under the assumption that the caller has already called test_and_create.batch once w/ the same arguments and received an override-able event, in which case re-running the is_possible checks is practically always redundant/unnecessary.

IMO, we should avoid this assumption and remove the if(!$override) check before calling open-ils.circ.title_hold.is_possible in test_and_create.

[Mike Rylander (mrylander)]

Bill, should we add that to this branch, so it covers all the outstanding (known) issues in this area?

[Bill Erickson (berick)]

Thomas' code posted at user/tsbere/overrides @ working resolves this problem. (Thomas, was your plan to post it here or open a new LP bug?). I've verified that it works (for holds) and repairs the bypass-possibility-checks-during-override problem.

[Thomas Berezansky (tsbere)]

My plan was to do more than just the backend in one larger commit (haven't worked out the staff client chunks yet), but if the other changes on this bug are going to need that then I am comfortable with that particular chunk going in alone.

[Mike Rylander (mrylander)]

With our reduced dev time for this release cycle, and Thomas' blessing to get this chunk in before some other upcoming work, I've pushed both of these in. Thanks, guys!