2019-10-10 Resource Access Meeting Notes

Date

10 Oct 2019

Attendees

Discussion Items

Time	Item	Who	Description	Goals
5min	Housekeeping	Andrea Loigman		Notetaker - Andy Horbal
10min	Blocks	Holly Mistlebauer	Forgot to ask these two questions when discussing blocks on September 30	1) Should patron notices be sent for manual patron blocks? Automated patron blocks? 2) Patty W. (a PO) recently asked me about these types of blocks: Informational block where nothing is blocked, you just want the patron's attention -- would this be a note or something else? A way to block the patron from checking out laptops due to their bad past behavior with laptops.
15min	Claims returned	Emma Boettcher	User record notes for claims returned	Gather requirements for ending claims process and adding note about claim returned to user record. Decide how many notes fields are needed.
30min	Requests	Cate Boerema (Deactivated)	Delivery requests: checking in should automatically check out item to requester	For delivery requests, we had a requirement that said that, when the item was checked in, it should be automatically checked out to the requester (when top request in queue is delivery request). The challenge we have run into is that check out can/should be prevented for a variety of reasons: Check out notes (this isn't a "hard prevent" but could cause staff to decide not to check the item out) Patron borrowing block Loan policy with Loanable = N Patron expired Other? Given this, we really can't auto-check out items. Instead, we may need to do the following: When item is checked in, notify that it is needed for delivery and print delivery slip Direct user to check out app where requester and item are pre-populated Happy path: item is checked out and routed for delivery If checkout doesn't happen for any of the above reasons: Item in "Awaiting delivery" status Request in "Open - Awaiting delivery" status Staff investigates checkout failure and resolves by: Removing patron block and checking out to requester Cancelling request and scanning into check in app Other? Introducing the new request and item state make this feature significantly more complex. Do people have ideas for how to simplify for MVP? If we do decide to introduce the new states, we need to: Update request whitelist Decide whether items that are "Awaiting delivery" can be marked Missing, Lost etc Decide whether requests that are "Open - Awaiting delivery" can expire Other?

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

Fees/fines

Holly Mistlebauer

Post-MVP

Holly created 2 JIRA issues:

UXPROD-2109: Allow for patron notices to be sent on request for manual patron blocks

UXPROD-2108: Expand patron blocks to allow blocking of borrowing by material/item type

Informational blocks will be handled by user notes

Loans

Emma Boettcher

Q4

Add additional field for patron-facing (notice) information in declared lost & claim returned resolution actions

When resolving a claim returned item, create a note on the user record with the outcome of the claim and a link to the loan.

Requests

Cate Boerema (Deactivated)

Q4

Above described solution with new item and request state seemed like best approach to SIG.

We updated the request whitelist

And we specified some other key requirements in this document: https://docs.google.com/document/d/1iWhEAxd3hvlvqmDgXmbJ2a3A_J2ahQHaMN2RKvDLvWI/edit?usp=sharing

I have enough to go on for now. May come back with follow up questions later.

Notes

Blocks - Holly Mistlebauer

Q: Should patron notices be sent for manual patron blocks, whereby the block is set by someone in the library (because, for instance, we don’t have a valid address for them)? Should patron notices be sent for automatic blocks, whereby the block is set automatically by the system (because, for instance, they have exceeded a fine limit)?

Cornell indicated that they have never sent notices like this in the past? Chicago indicated that they would like this OPTION, but don’t want it to happen every time. Not needed for MVP. Holly reminded everyone that we can already display these blocks in the patron view in the discovery system if we choose to. In response to feedback from Chalmers, Holly clarified that blocks aren’t currently working in self-checkout because it’s not in the API, but this is a known issue that is being worked on. There’s also an issue with EDS, for which Chalmers will create a JIRA.

A: Holly will create a feature for post-MVP giving people the option of sending notices.

Holly also asked about two types of blocks that we haven’t previously discussed:

Informational block where nothing is blocked, you just want the patron's attention -- would this be a note or something else?
A way to block the patron from checking out laptops due to their bad past behavior with laptops.

Chicago indicated that OLE treats these as notes, not blocks. Erin and Jana from User Management will present to the RA SIG on this topic next week. The consensus in the SIG is that something that gets staff attention (such as a note) is needed, but it doesn’t need to be a block per se.

Claims Returned - Emma Boettcher

For claims returned items, does information entered into “additional information” field anywhere other than the comments on the loan itself (which is the only place it displays now)? For instance, should we write an automated note that appears on the user record? Consensus is that this would be a great feature, but is not needed for MVP.

When applying a “Lost” status, the option is given to “notify patron.” The SIG discussed whether or not this notification should include the notes entered in the additional information field and a consensus emerged that the functionality we want is to have the option to enter additional information for both the patron and staff (which might be different) to view. This definitely should be consistent across FOLIO.

Requests - Cate Boerema

The notetaker instigated a brief discussion of the reasons why patrons couldn’t be blocked at the point of placing the delivery request instead of at the point of checkout. Mainly, it is because things can happen between the time when the request is placed and when the item is ready to checked out, and these things happen often enough and are great enough significance that this should be avoided at all costs. The SIG was not able to think of an alternative to the solution Cate described in the agenda. The SIG indicated that by and large items with the new status “Awaiting Delivery” should have the same properties as an item “Awaiting Pickup.”