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.
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.