Versions Compared

Key

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

Date

...

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to Supporting Materials

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue
RequestsCate 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).
    • Delivery fulfillment handling
    • Whitelist for other common status values that haven't yet been implmeneted (e.g. Lost, Claimed returned and Recently returned statuses)
    • 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.







...