[OPEN-ILS-DEV] Selfcheck override events list

[Lazar, Alexey Vladimirovich]

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 <berickxx at gmail.com> 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 <alexey.lazar at mnsu.edu> 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 <berickxx at gmail.com> 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 <alexey.lazar at mnsu.edu> 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/