2019-8-26 Resource Access Meeting Notes

Date

26 Aug 2019

Attendees

Discussion Items

Time	Item	Who	Description	Goals
5 min	Housekeeping	Andrea Loigman		Notetaker - William Weare Reminder - no meeting on 9/2
5min	Users	(OLD ACCOUNT) Erin Nettifee	active/not active	UM needs to understand our use case for the active/not active field in the user record
15min	Lost	Emma Boettcher	Lost (aged to lost, declared, lost and paid) statuses	Decide what actions are permitted (renew, change due date, claim returned, etc.) on items with various lost statuses
25min	Request queue	Cate Boerema (Deactivated)	Manual request queue reordering vs rush request	- We recently reviewed and approved mockups for the manual request re-order page: https://drive.google.com/file/d/1VBGboSPqwuaZH5k0k4dH5xWdPEjVCG8y/view?usp=sharing -- Discussed with developers and, as anticipated, there are some design challenges with supporting manual request reording as well as auto-ordering via FIFO when moving requests from one item to another -- Developers and I discussed the possibility of flagging a queue as manually re-ordered and, when moving requests from one item to another, placing moved requests at the end of the queue in such cases (as opposed to ordering FIFO as we normally do) -- HOWEVER there are challenges: --- Technical: There is no easy way to do this with current architecture ---- Design: Once a queue has been flagged as manually reordered, when/how does it get reset to FIFO? Overall, it would be much easier if the queues could be manually ordered or FIFO but not both. Alternative 1: When moving requests from one item to another, you ALWAYS need to manually order the queue (right now it automatically slots moved requests into the queue according to the request creation date). Alternative 2: Instead of supporting manual re-order of request queue, we could implement Auto-sort of recalls above holds (https://folio-org.atlassian.net/browse/UXPROD-1558) and Rush/staff/admin requests (https://folio-org.atlassian.net/browse/UXPROD-1409)

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Comments
Requests	Cate Boerema (Deactivated)	Q4	No one on the call had objections to putting requests at the end of the queue when moving from one item to another as long as they can be manually reordered and the request creation date is unchanged and visible Just in case Chalmers really objected to this idea, we discussed the rush request alternative briefly as well General sense was there would be cases where you would want to reorder a request but not do a rush request. More discussion is needed on use cases, but a couple were offered: Someone is in position 2 of the queue calls and says, "I want to be in the queue, but will be out of town for a while, can you move me to the bottom" Library requests an item for document delivery of a chapter of a book for the China campus. They want it at the top of the queue but don't want to "rip it away" from the person who has it now. Overall, SIG would prioritize manual reorder of the queue and think rush requests would be an additional feature down the road	Carsten said he was still very interested in instance/title level requests which would reduce the need to move requests from one item to another. Chalmers really wants this to. We plan to start a subgroup to gather requirements on this topic, but it hasn't been flagged cap-mvp. Carsten wondered what patrons would think if they saw their queue position changing. Andrea and others on the call said it hasn't been an issue for them (and some institutions don't show queue position to patrons)
Loans	Emma Boettcher	Q4	On declared lost and aged to lost items, the SIG would like to allow (with staff confirmation and/or override) the standard loans actions: renew, change due date, declared lost, claim returned.	Impact on fines/fees mentioned but not discussed Being able to claim returned was not discussed to the same degree as renew and change due date, may be worth a quick revisit

Notes

Erin Nettifee – active/not active

Question from the User Management SIG:

Use cases for status: active and inactive
Conflict between status and expiration date
What does an inactive status do? Why would you use it

Cases:
• Lost ID
• Student is away (studying abroad)

There is also a separate blocking feature (borrowing, renewals, & request)
Blocking is separate from active/inactive

Other cases:
• Seasonal staff (through feed or added manually)

Question, re: Relationship regarding staff permissions
When inactive, borrowing, etc. is disabled; however, we want notices, fines, etc. to continue.

Use cases:
• Managing intermittent staff
• Blocking checkout
• Relation to proxies
• Relation to logins

Freeze records are not currently in the MVP
Freezing record: freeze status of patron record--so it won’t be overridden by system / bulk upload
Renewal? Should be blocked as well for inactive users? Yes.

Emma Boettcher – Lost (aged to lost, declared, lost and paid) statuses

Lost and missing statuses

Last conversation; five different statuses
First two: (1) declared lost & (2) aged to lost

• Can items be renewed?
• Change due date?
• Claimed returned?
• Declare lost?

What does renewing something that is declared lost do to the fines & fees?
Re: effect on fines & fees; we will need to follow-up with Holly (not here today).

Renew through staff override would be very helpful.
Do we need to differentiate between aged to lost and declared lost, re: renewal, claimed returned, etc.? Treat them the same.
We need to understand what it will do to fines & fees.

Emma will try to follow-up with Holly before the next meeting.

RE: aged to lost:
• Renew
• Change due date
• Claim returned
• Declared lost
All of these should be allowed—w/ staff override.

Cate Boerema – Manual request queue reordering vs rush request

Inventory:

Reviewed and approved mock-up for reordering the request queu

Another feature impacts queue: ability to move request from one item to another; add to new list according to creation date;
How do we deal with a manually reordered queue? Do we create a flag so that we don’t slot an item in? No easy place to put that flag. How does it get unflagged?

The original request date comes with the item. They can be moved—and then reordered (manually).

Looking forward to having instance requests rather than item level requests. Title-level requests are not MVP.

Another option:

Staff/admin/rush recalls/request
Create a request that jumps to the top of the queue
(Item needed for reserves, for example).

Should we use this instead?
We can choose the date the item becomes due (it needn’t be a ‘rush’);
One is not a replacement for the other; we want both; they are different in ways that potentially matter. Use case? Perhaps we can talk about this further.