2019-10-10 Resource Access Meeting Notes
Date
Attendees
- Andrea Loigman
- Andy Horbal
- Jana Freytag
- Holly Mistlebauer
- Elizabeth Chenette
- David Bottorff
- Kai Sprenger
- Cate Boerema (Deactivated)
- Laurence Mini
- Joanne Leary
- Emma Boettcher
- Kimie Kester
- David Larsen
- Sharon Wiles-Young
- Darcy Branchini
- Mark Canney
- Magda Zacharska
- Donna Minor
- Cheryl Malmborg
- Rameka Barnes
- Cornelia Davis
- William Weare
- Regina Frindt
- mey
Discussion Items
| Time | Item | Who | Description | Goals |
|---|---|---|---|---|
| 5min | Housekeeping | Andrea Loigman |
| |
| 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:
|
| 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:
Given this, we really can't auto-check out items. Instead, we may need to do the following:
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:
|
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 | 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.”