Fees/Fines (UXPROD-792)

[UXPROD-1683] Future Patron Blocks: Enforce Patron Blocks in Borrowing API Created: 14/May/19  Updated: 12/Jan/23

Status: Draft
Project: UX Product
Components: Fees/Fines
Affects versions: None
Fix versions: None
Parent: Fees/Fines

Type: New Feature Priority: TBD
Reporter: Holly Mistlebauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: PMP, Unassigned-from-Holly, feesfines, mandatory, po-mvp, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Gantt End to Start
has to be done before UXPROD-1898 SIP2: Protocol for self-checkout - Bl... Open
Relates
relates to UXPROD-1898 SIP2: Protocol for self-checkout - Bl... Open
relates to UXPROD-1402 Enforce Manual Patron Blocks Closed
relates to CIRC-476 Blocked patron can successfully place... Closed
relates to UIU-675 Enforce Manual Patron Blocks Closed
Potential Workaround: Holly: There isn't a workaround for this. Blocks need to be enforced in the API.
Epic Link: Fees/Fines
Front End Estimate: Small < 3 days
Front End Estimator: Holly Mistlebauer
Front-End Confidence factor: Low
Back End Estimate: Medium < 5 days
Back End Estimator: Holly Mistlebauer
Development Team: Vega
PO Rank: 84
PO Ranking Note: Manual patron blocks are already in place, so the API needs to be updated ASAP to enforce them.
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R3
Rank: Grand Valley (Full Sum 2021): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Current situation or problem:

In scope

Out of scope

Use case(s)

Proposed solution/stories

Links to additional info

Questions



 Comments   
Comment by Holly Mistlebauer [ 14/May/19 ]

EMAIL TRAIL BETWEEN ZAK AND HOLLY...

----Original Message----
From: Zak Burke <zburke@cornell.edu>
Sent: Monday, May 13, 2019 5:01 PM
To: Holly L. Mistlebauer <hlm7@cornell.edu>
Subject: Re: should circulation APIs enforce manual patron blocks?

Holly,

It sounds like we agree that attempting to create a loan with a blocked user should return an error. That story should be filed against mod-circulation.

As to how ui-checkout works, it implements a workflow with three separate API calls:

1. get user info to check for blocks
2. get item info to check its status
3. create a loan

Checkout “fails” only because the workflow was interrupted, not because we attempted to create a loan and received an error. Looking at the ticket in question, SIP2-37 Closed , it seems to me that the self-checkout process will be similar (get user info and interrupt the workflow if the user is inactive or blocked) but there’s no guarantee that it will always be the same.

Zak

> On May 13, 2019, at 3:21 PM, Holly L. Mistlebauer <hlm7@cornell.edu> wrote:
>
> Hi Zak. I have a TO DO for myself to determine what to do about the API. I think I created a UIU ticket, but maybe it's just on my TO DO list. Part of my hesitancy is working on this task has been not knowing how the API will be used. Will it always be the same, with no way to interrupt the three-part process?
>
> The API should prevent borrowing and send the Block Description(s) back. I will create a user story for this. Should I create it in ui-users or a different JIRA project?
>
> Thanks,
> Holly
>
> ----Original Message----
> From: Zak Burke <zburke@cornell.edu>
> Sent: Monday, May 13, 2019 2:35 PM
> To: Holly L. Mistlebauer <hlm7@cornell.edu>
> Subject: should circulation APIs enforce manual patron blocks?
>
> Holly,
>
> A question that came up in the context of https://folio-org.atlassian.net/browse/SIP2-37 is whether loan-related endpoints in mod-circulation should prevent loans to users with manual blocks. Currently, they do not; manual blocks in ui-checkout are enforced entirely by the UI, not the API. (In the UI, checkout is a three-part process: 1 retrieve a user, 2 retrieve an item, 3 create a loan; if we find a block in part 1 we simply never attempt part 3.) In the context of self-checkout where we don’t control the checkout process, there is not a way to interrupt this three-part process, hence the question.
>
> The consensus among the devs was allowing checkout to blocked users feels wrong, it feels like a bug. At the same time, none of us were aware of any tickets specifically requesting this feature, so we thought we should check with a PO before we filed a bug report.
>
> And here we are!
>
> Zak

Comment by Cate Boerema (Inactive) [ 07/Aug/19 ]

Is this a duplicate of UXPROD-1898 Open ? Magda Zacharska, Holly Mistlebauer

Comment by Holly Mistlebauer [ 07/Aug/19 ]

Cate Boerema and Magda Zacharska: Good catch! If Magda is going to work on this, I will close UXPROD-1683 Draft as a duplicate. Just let me know. Thanks!

Comment by Magda Zacharska [ 08/Aug/19 ]

UXPROD-1683 Draft is not a duplicate of UXPROD-1898 Open which describes work related to supporting Block Patron SIP2 message that is being sent from a self-checkout kiosk to FOLIO. Than message is sent when the patron is detected tampering with the self-checkout or when a patron forgets to take their card. Implementing this message would allow for blocking the patron from the self-checkout kiosk. Since none of the libraries listed it as a go-live feature I don't think we will be working on this this year. If we do, than we will need to have UXPROD-1683 Draft already implemented.

Comment by Cate Boerema (Inactive) [ 08/Aug/19 ]

Thanks Magda Zacharska. If this isn't needed for self-checkout for MVP, it seems like the work Zak Burke described in the email exchange above is tech debt that won't have immediate user impact. Am I understanding that correctly? If so, I am thinking this is not needed for MVP.

Thoughts Holly Mistlebauer, Zak Burke, Magda Zacharska?

Comment by Holly Mistlebauer [ 08/Aug/19 ]

Zak Burke, Cate Boerema, Magda Zacharska: I understand now why the two issues are not duplicates. Is anyone going to use the Borrowing API for anything else between now and summer 2020? If not, then it sounds like we don't need UXPROD-1683 Draft to be part of the MVP. I don't like leaving the tech debt but this won't be the only place, I'm sure. Thanks!

Comment by Magda Zacharska [ 08/Aug/19 ]

From SIP2 point of view this is not MVP but as Zak Burke mentioned it in his comment it would make sense to prevent blocked patron from checking out until the blocking issue is resolved. The enforcement would happen during the check out so it would be a part of Circulation API and should happen on each check out unless we don't care if blocked patron continues to check items out.

Comment by Holly Mistlebauer [ 09/Aug/19 ]

Zak Burke: Do you mind clarifying what you think should be done for the MVP? Thanks!
cc: Cate Boerema; Magda Zacharska

Comment by Holly Mistlebauer [ 09/Aug/19 ]

Cate Boerema, Magda Zacharska, Zak Burke: After speaking with Zak about this I decided to add this feature back into the MVP. Here are my reasons:
1) Magda's issue UXPROD-1898 Open is dependent on this issue--she has linked this issue to her's and indicated it must be completed before she can work on her issue. Is this true?
2) This is actually a bug--updating the Borrowing API for patron blocks was overlooked by me when we initially implemented Patron Blocks (I didn't know if existed). Should I create a bug issue and get rid of this feature?
3) As part of the MVP, we cannot allow libraries using self-checkout to checkout items to patrons who are supposed to be blocked. Blocks are taken quite seriously by libraries. If Magda is going to come up with a workaround for the MVP that will keep blocked patrons from checking out items then I am fine with UXPROD-1683 Draft waiting. I can't tell based on the little information in UXPROD-1898 Open .
4) Will libraries be using the Borrowing API for things other than self-checkout? If so, they must be warned that patrons will not be blocked.

Comment by Cate Boerema (Inactive) [ 19/Aug/19 ]

As part of the MVP, we cannot allow libraries using self-checkout to checkout items to patrons who are supposed to be blocked. Blocks are taken quite seriously by libraries.

Hi Holly Mistlebauer. This seems totally logical, but I am curious, then, why institutions are not ranking UXPROD-1898 Open high. It seems like an extremely low priority issue.

Comment by Magda Zacharska [ 19/Aug/19 ]

Cate Boerema Not that many ILS-es support blocking patrons from self-checkout kiosk. It seems only Voyager and Evergreen from those that I investigated. So from self-checkout point of view, blocking a patron might not be the most commonly used functionality.

Comment by Cate Boerema (Inactive) [ 19/Aug/19 ]

Given Magda Zacharska's comment above, Holly Mistlebauer do you still think this is mvp?

Comment by Holly Mistlebauer [ 19/Aug/19 ]

Cate Boerema and Magda Zacharska: Only half the institutions have ranked the featured at all. This will be a show stopper for any institution that does self-checkout that enforces patron blocks now. But, if Cate is saying that only Voyager and Evergreen actually block patrons at self-checkout then we only need to ask those institutions that haven't ranked the feature who use Voyager or Evergreen to see if they do self-checkout. I know Cornell and TAMU use Voyager. Not sure about Evergreen.

Comment by Magda Zacharska [ 19/Aug/19 ]

Holly Mistlebauer There might be other ILS that allow to block patron from self-checkout but I just didn't find it. Also UXPROD-1898 Open is not about enforcing patron block (the current SIP2 implementation should prevent blocked patron from checking out) but making a patron blocked due to their action, for example because of their tempering with the hardware. In addition, even if the ILS supports the functionality, the kiosk itself might not support it (depending on the kiosk's vendor).

Comment by Erin Nettifee [ 16/Sep/19 ]

Do we know for sure that the current SIP2 implementation blocks patrons who have a request or renewal block on their account? EG, that's been tested or we know it's in place somewhere like at Chalmers?

Comment by Magda Zacharska [ 16/Sep/19 ]

Erin Nettifee - SIP2 was tested multiple times in Chalmers and the behavior is as expected: a blocked patron is prevented from check-out at the self-checkout station. Here is the link to the TestRail with the passing test case: https://foliotest.testrail.io/index.php?/tests/view/2792&group_by=cases:section_id&group_order=asc&group_id=360

Comment by Erin Nettifee [ 16/Sep/19 ]

Thank you Magda Zacharska!

Comment by Holly Mistlebauer [ 17/Sep/19 ]

Erin Nettifee and Magda Zacharska: Thanks!

Comment by Magda Zacharska [ 27/Sep/19 ]

This impacts requests placed from EDS: blocked patron can place requests from EDS: CIRC-476 Closed

Comment by Stephanie Buck [ 09/Jan/23 ]

Holly Mistlebauer, Erin Nettifee, Magda Zacharska - this is a pretty old feature. Is it still needed? There is no description and no story attached. 

Comment by Holly Mistlebauer [ 12/Jan/23 ]

Stephanie Buck: I believe it is still needed. Someone contacted me recently about this.

Generated at Fri Feb 09 00:17:36 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.