2019-1-31 Resource Access Meeting Notes

Date

31 Jan 2019

Attendees

Discussion tems

Time	Item	Who	Description	Goals
5min	Housekeeping	Andrea Loigman	Notetaker - Joanne Leary	Call number review document
55min	Confirmation of request behavior by type	Cate Boerema (Deactivated)	Review documents: -https://docs.google.com/document/d/1lmr5UuXtYyH8vW-uXTwWA5rH7IDBbtW_IH69xhwHUh4/edit# - https://docs.google.com/spreadsheets/d/1jaID-HGft3q4YzJq6Ycy2ejWByAIvou3Zyyw4ko87YI/edit#gid=0	- Confirm understanding of various types of requests and what statuses they should be allowed on (this is just needed until we have the ability to configure the request to status mappings - UXPROD-1320) - I'd like to confirm that paging requests should only apply to items that are Available AND that we should prevent paging requests on items that already have a paging request (I think this would be simplifying) - I'd like to discuss what should happen if you try to place a disallowed request - Wireframes: https://drive.google.com/drive/folders/1qMLWk7RThsy9xUDYQpTHMrw95E-qydYz

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Reasoning	Link to Supporting Materials	Comments
e.g. loans, fees/fines	Name	e.g. Q4 2018, Q1 2019	Clearly stated decision	Because... Because...	e.g. mock-up, JIRA issue
Requests	Cate Boerema (Deactivated)	Q1 2019	New status called "Requested" or "Paged" for items that have been paged (we had previously said that paged items would remain "Available" until checked in) Added "Paged" status to this document: https://docs.google.com/spreadsheets/d/1jaID-HGft3q4YzJq6Ycy2ejWByAIvou3Zyyw4ko87YI/edit#gid=0 and agreed on the types of requests that are allowed for this status Holds should be allowed on Missing items because some institutions will allow holds that they could fulfill when/if item is found When a Hold request is placed on an item that is checked out, even though it won’t shorten the due date, the borrower should be notified of the existence of another request We probably should break up "In transit" status into "In transit for reshelving" and "In transit for request". Recalls would then be allowed on items that are "In transit for request" but not "In transit for reshelving" BUT we don't have the two types of In transit now so we will allow recalls even on items that are In transit for reshelving In this case and, in general, when there is a queue of recalls at check out, "Minimum guaranteed loan period for recalled items" will be used at checkout as the alternate loan period for items with active, pending recalls. We don't need a separate field in the loan policy for this. Mockups seemed okay to all for the first iteration BUT: People would definitely like to see us do the "deluxe" version in the future (in which we query the loan rules/request policies and only present the types of requests that are allowed before the request creation is attempted) People would like to have the popup display more information about why the request isn't allowed for patron/item combo: We could link to the request policy pretty easily But those will be pretty generic and not useful Linking to the actual loan rule would be more useful Sean thinks this may be possible, but we'd need to investigate further Need to make sure that you can close the modal popup and change the request type afterwards (in some systems, after you close the popup, you are no longer able to edit the request type and you have to cancel the request and start over)	Everyone agrees it would be good if we could only allow one paging request per item and only when the item is Available To prevent additional page requests being applied to an already-paged item, we need a status for an item that is paged "Requested" was the first item status suggested for paged items because it would make sense to a patron, while "Paged" would be meaningless to a patron But "Requested" is misleading because items with other status values can also be requested (e.g. a Checked out item can have a hold request on it)		Tabled for future discussion: How to customize what item status values patrons see in discovery (e.g. "paged" would need a display name to make sense for patrons) ASR (automated storage request). (UXPROD-1516) Delivery fulfillment handling (UXPROD-113) Whitelist for other common status values that haven't yet been implemented (e.g. Lost, Claimed returned and Recently returned) Andrea would like the ability to configure the request to status mapping/white list at a tenant level (e.g. holds are allowed where item status is missing) which is already covered in UXPROD-1320 AND she would also like the ability to override that at the request policy level (so she could allow certain patron types to make certain types of requests for certain status values but not others). Others on SIG did not seem to think this was important.

Notes

The Spring FOLIO meeting will be held at EBSCO headquarters in Ipswich, MA and will primarily be a developers meeting. Attendance is limited to around 100 people. Unless we have a need to have an RA representative to discuss high-priority issues in person with developers, we can probably forego the meeting and discuss issues with other SIGs, such as User Management, through usual channels. Deb suggested that we meet with UM members on the topic of permission sets. Andrea will ask Maura to share the presentation she prepared for UM on this topic with us.

We spent the rest of the meeting reviewing Cate’s Request Type/Item Status matrix, which will be used to hard-code the types of requests that may be placed on materials with the given item statuses. The request types included in the discussion were: Hold, Recall, Page (Rush Recall to be discussed at a later time). Some issues that arose include:

There are other common item statuses that will have to be included in the matrix (such as Lost/Billed, Claims returned)
Request types “Delivery” and “Remote Storage Request” need to be included
In Transit will probably have to be further broken out into ‘In Transit for Hold’ and ‘In Transit for Shelving’; allowable request types will differ
Is “Recall” an allowable request type for items In Transit? Yes, if the item is in transit for hold, but not for in transit for shelving. Recall is needed, because if only request type Hold is permitted, the borrower for whom the item is in transit will be given a standard loan instead of a shortened loan upon checkout. The system will have to check for the existence of requests upon checkout.
Page requests should update the item status from “available” to something else (status terminology needs to be resolved)
When a Hold request is placed on an item that is checked out, even though it won’t shorten the due date, the borrower should be notified of the existence of another request
In the situation where more than one Hold exists on an item, we need to be able to configure how long the first borrower will get (= alternative loan period for Hold)
If allowable request types are hard-coded against item statuses, we need to be able to override through the loan rules (that account for patron group, location, material type)
If a request type is not allowed in a given situation, a modal will be displayed; but it’s preferable that the operator be allowed to choose a different request type without having to start the request process from the beginning. Ideally, the system should first check the loan rule to determine which request types are permitted for a given patron/material/location, and only present those request choices.

Next meeting: discussion about call number displays on functional screens. Andrea has started a Google doc to get us thinking (see link above).