SIP2: add setting to specify overriding certain flag fields

[Galen Charlton]

The e-content service Hoopla has announced that as of December 2019, the following flag fields in the Patron Status Response and Patron Information Response messages will be taken into consideration when deciding whether a patron can authenticate into their service or perform certain operations:

* charge privileges denied
* renewal privileges denied
* card reported lost or stolen

Evergreen currently sets those flag fields as follows:

* charge privileges denied: set if the patron has expired, is barred, is not active, their primary barcode is not active, or the patron has a standing penalty blocking loans.
* renewal privileges denied: set if the patron has expired, is barred, is not active, their primary barcode is not active, or the patron has a standing penalty blocking renewals.
* card lost: set if the patron's primary barcode is not active

It is my understanding that once this change is implemented, Hoopla libraries will not have a way to turn off the additional checks on Hoopla's end. It is also my understanding that some or more Evergreen libraries do not wish their patrons to be unable to access Hoopla because one of those flag fields is set.

To address the conflicting requirements, I propose to add an account and institution setting to the SIPServer configuration for Evergreen called patron_status_always_permit_loans that, when set to a true value, will ensure that the three flag fields listed above are not set.

It is acknowledged that the proposed change is a workaround.

[Michele Morgan (mmorgan)]

Adding a link to more info:

http://go.midwesttape.com/support/SIP2/

[Galen Charlton (gmc)]

A patch is available:

working/user/gmcharlt/lp1853363_sip_patron_status_always_permit_loans
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1853363_sip_patron_status_always_permit_loans

[Martha Driscoll (mjdriscoll)]

I installed this code on a test system and found that this code will not send a block in fields 0, 1, and 4 but will send a block in fields 0 and 1 if the primary barcode is not active.

Here is SIP message 64 Patron Information Response after the code was implemented. I'm only showing a partial message:

Patron with a block due to too many fines and long overdue items
64 YY YY 00020191204

Patron in good standing
64 Y 00020191204

Patron with expired privileges
64 YY 00020191204

Patron with inactive primary barcode (lost or stolen)
64YYYY 00120191204

I then installed this code on my production system and had Hoopla test. They concluded that the first three cards authenticate as TRUE in the upcoming code. The last one authenticates as FALSE.

Libraries can still choose to block access to Hoopla based on field AF which Evergreen will return as 'blocked' if the patron record reaches block thresholds or is expired. Libraries can also block on field BV which contains the amount owed.

Half of my libraries who subscribe to Hoopla want to permit access even if a card is blocked in Evergreen so I have implemented this code. Libraries who want to continue to block can do so with restrictions on fields AF and BV.

With this code in place and the option set for Hoopla's sip login, I have not seen any issues with self-check machines, PC reservation systems, an automated materials handler, Overdrive, or any other service that uses SIP2 for authentication.

[Jason Boyer (jboyer)]

I've tested this branch and it does what it says as expected, with the 1 exception of users retrieved with lost cards, as mentioned by Martha above. Personally, however, I consider that to be the correct way to implement this change, because allowing lost cards to be used in addition has not set well with me in this discussion.

So, here's my signoff for Galen's branch as-is: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1853363_signoff / working/user/jboyer/lp1853363_signoff

But, in the interest of giving admins enough rope to shoot themselves in the foot, here is a followup that also allows inactive cards to be used: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1853363_followup / working/user/jboyer/lp1853363_followup

It contains Galen's original commit in addition to the followup so it can be tested as a single branch if desired. I don't, and would recommend the whole followup just be dumped in the bit bucket. Discuss.

[Martha Driscoll (mjdriscoll)]

I agree that blocking lost cards is the appropriate behavior and have added a signedoff tag.

[Terran McCanna (tmccanna)]

Martha, did you test Jason's follow up, or are you just signing off on Galen's original patch?

[Martha Driscoll (mjdriscoll)]

I did not test Jason's follow-up. Jason signed off on Galen's branch which I did test and agree is the way to resolve this issue.

[Terran McCanna (tmccanna)]

Jason, do you want to start a new launchpad for your follow-up?

[Jason Boyer (jboyer)]

Nope.

:)

I only made it available in case discussion showed that there was a desire to allow the use of lost cards. I'm happy to throw it away.

[Terran McCanna (tmccanna)]

Thanks Jason and Martha! Martha, for the sake of posterity, can you please add your sign off text in this format?

"I have tested this code and consent to signing off on it with my name, [enter name or consistent alias] and my email address, [enter email address]."

[Martha Driscoll (mjdriscoll)]

Here is my signoff for Galen's original branch:

I have tested this code and consent to signing off on it with my name,
Martha Driscoll and my email address, <email address hidden>.

[Jeff Davis (jdavis-sitka)]

I've committed Galen's original fix. This means "lost" cards (i.e. inactive primary cards) will continue to be blocked, per the consensus above.

As Martha noted, the AF field is still set to "blocked" even when patron_status_always_permit_loans is true. This seems to be desirable or at least acceptable behavior, so libraries will need to take that into account.