[OPEN-ILS-DEV] Selfcheck override events list

[Bill Erickson]

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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140827/9c4eb1c2/attachment-0001.htm>