Versions Compared

Old Version 5

changes.mady.by.user William Weare

Saved on

compared with

New Version Current

changes.mady.by.user Emma Boettcher

Saved on

Key

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

...

TimeItemWhoDescriptionGoals
5 minHousekeepingAndrea Loigman
5minUsers(OLD ACCOUNT) Erin Nettifeeactive/not activeUM needs to understand our use case for the active/not active field in the user record
15min

Lost 

Emma BoettcherLost (aged to lost, declared, lost and paid) statusesDecide what actions are permitted (renew, change due date, claim returned, etc.) on items with various lost statuses
25minRequest queueCate 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://issuesfolio-org.folioatlassian.orgnet/browse/UXPROD-1558) and Rush/staff/admin requests (https://issuesfolio-org.folioatlassian.orgnet/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)
LoansEmma Boettcher Q4On 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

...