Versions Compared

Old Version 4

changes.mady.by.user Cate Boerema (Deactivated)

Saved on

compared with

New Version 5

changes.mady.by.user William Weare

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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)






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.