Page Comparison

• Need default expiration period for request expiration
  • Otherwise requests could be filled years after they were created which "makes us look dumb"
  • Some feel tenant level setting would be fine, others think it might belong in the request policy. Need to discuss more later.
  • Cate Boerema (Deactivated) will check the backlog to see if there is a feature already and, if not, create one

  • Jira Legacy
    server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1628

• Need some ability to archive old, closed requests
  • Cate Boerema (Deactivated) to add a feature if there isn't one already:

    Jira Legacy
    server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1042

• Would be nice to have a pickup location filter on the Requests page
  • Feature will be added

  • Jira Legacy
    server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-1629

• Concern over the ability to Recall items that are In transit
  • This was something we agreed to when we worked out the Request to Item status whitelist
    • It was seen as a necessity since we don't have a way in FOLIO to differentiate between In transit to home location and In transit for another request
    • At the time, SIG wanted the ability to allow recalls on items that were in transit for another request but disallow them on items that were in transit to home location
    • However, we agreed (at the time) that it was acceptable for now and that the due date for the item to be loaned would be calculated based on the minimum guaranteed loan period (so it would be back in approximately the same time as a regular recall)
  • However, Cate asked whether we could also allow recalls on paged items so that institutions like Chalmers could avoid having to use hold requests - question was whether the same logic could apply in this scenario
  • SIG was concerned that this was:
    1. Overcomplicating from a code perspective and
    2. Possibly misleading for patrons who are creating recall requests thinking they will be available in, say, 2 weeks when, in reality, they might take longer if the item needs to sit on the hold shelf for a week before checked out to the first requester in the queue
    3. Darcy was going to think about whether there are complications for patron notices
  • This requires more thought, as I believe it may follow from the above reasoning that:
    1. Recalls should only be allowed on checked out items
    2. There shouldn't be a queue of recalls allowed
  • These would be pretty major changes to the current design of requests

Bugs found while demoing:

• Creating a hold request on a paged item results in the page being marked filled - Can't reproduce
• Create a request from the item record in inventory (this auto-populates with the item record which is good). Then close the draft request and then click New to create a new request. The item details from before are auto-populating.

  Jira Legacy
  server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UIREQ-244