Date
Attendees
Discussion Items
| Time | Item | Who | Description | Goals |
|---|---|---|---|---|
| 5 min | Housekeeping | Andrea Loigman |
| |
| 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://issues.folio.org/browse/UXPROD-1558) and Rush/staff/admin requests (https://issues.folio.org/browse/UXPROD-1409) |
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments |
|---|---|---|---|---|
| Requests | Q4 |
|
| |
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.