Hi Aleksey, Your expectations are correct. It should allow the transaction to continue.
The setting works by calling the ".override" versions of the checkout or renewal API call when it receives one of the configured responses. In order for this to work, though, the staff account logged in to drive the self-check UI must have the related .override permission (e.g. PATRON_EXCEEDS_CHECKOUT_COUNT.override) for every permission that may get overridden. Also, beware the setting is not a silver bullet. For example, PERM_FAILURE is a red light... it cannot be overridden. -b On Fri, Aug 22, 2014 at 6:22 PM, Lazar, Alexey Vladimirovich < [email protected]> wrote: > Hello. > > There is a self-checkout setting called "Selfcheck override events list” > described as “List of checkout/renewal events that the selfcheck interface > should automatically override instead instead of alerting and stopping the > transaction”. > > Events are PERM_FAILURE, PATRON_EXCEEDS_OVERDUE_COUNT, PATRON_BARRED, > CIRC_EXCEEDS_COPY_RANGE, PATRON_ACCOUNT_EXPIRED, ITEM_DEPOSIT_REQUIRED, > ITEM_RENTAL_FEE_REQUIRED, ITEM_DEPOSIT_PAID, PATRON_EXCEEDS_LOST_COUNT, > ACTION_CIRCULATION_NOT_FOUND, PATRON_EXCEEDS_CHECKOUT_COUNT, > COPY_CIRC_NOT_ALLOWED, COPY_NOT_AVAILABLE, COPY_IS_REFERENCE, > COPY_NEEDED_FOR_HOLD, MAX_RENEWALS_REACHED, CIRC_CLAIMS_RETURNED, > COPY_ALERT_MESSAGE, PATRON_EXCEEDS_FINES and maybe others. > > The last bit of the description “… instead of alerting and stopping the > transaction” makes it sound like the setting would allow the transaction to > proceed if the event was added to the “Selfcheck override event list”. In > testing, however, only the alert message was suppressed, but the > transaction still failed due to the said event. I am curious if somebody > could clarify if this was the intended behavior? Or what am I missing? > > Thanks. > > Aleksey Lazar > IS Developer and Integrator - PALS > http://www.mnpals.org/ > >
