Bill, No luck. The BAILING OUT message block is the last thing logged, regardless of whether the COPY_ALERT_MESSAGE is in the "Selfcheck override event list” setting or not. With the COPY_ALERTS_MESSAGE there, the alerts get suppressed in the self-check interface, but the transaction does not proceed and I do not see a second call or any further errors in the log, it just stops after the BAILING OUT as I pasted previously.
Anyway, not sure what I am missing still, but thanks for the info. Aleksey On 2014-08-27, at 18:01 , Bill Erickson <[email protected]> wrote: > Hi Aleksey, > > Just to be clear, the API will get called to begin with in non-override mode, > so it's normal to see the BAILING OUT message on the first attempt. If the > failure event is in the override list, however, the client goes back to make > a secondary call with override enabled. This second call should succeed and > allow the transaction to continue. I would suggest trying to find the > secondary call to see if it's failing somewhere else. > > This event type is supported for override, as noted by the > COPY_ALERT_MESSAGE.override permission. I'm pretty sure I've seen this > successfully working in the wild as well. > > -b > > > > On Wed, Aug 27, 2014 at 2:43 PM, Lazar, Alexey Vladimirovich > <[email protected]> wrote: > Hello, Bill. > > Thanks for confirming. > > I am interested in overriding the COPY_ALERT_MESSAGE. Permissions are OK and > I set "Selfcheck override events list” to COPY_ALERT_MESSAGE. > However, circulator bails out regardless of the setting. > > open-ils.circ [INFO:2442:Circulate.pm:1377:140917491925024] circulator: > permit_copy script returned events: HASH(0x6141578) > open-ils.circ [INFO:2442:Circulate.pm:631:140917491925024] circulator: > pushing event COPY_ALERT_MESSAGE > open-ils.circ [INFO:2442:Circulate.pm:617:140917491925024] circulator: > BAILING OUT > open-ils.circ [INFO:2442:Circulate.pm:343:140917491925024] circulator: > bailing out with events: COPY_ALERT_MESSAGE > > In Circulate.pm I do not see that override_events is called at all by > check_copy_alert or inside run_copy_permit_scripts, so the override setting > does not work for COPY_ALERT_MESSAGE. Is this a feature/requirement or maybe > a bug? > > Aleksey > > > On 2014-08-23, at 08:57 , Bill Erickson <[email protected]> wrote: > > > 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/ > > > > > > Aleksey Lazar > IS Developer and Integrator - PALS > http://www.mnpals.org/ > > Aleksey Lazar IS Developer and Integrator - PALS http://www.mnpals.org/
