Details
-
Story
-
Status: Closed (View Workflow)
-
P1
-
Resolution: Done
-
None
-
None
-
None
-
-
Vega
Description
Context
Recall requests include items that are currently checked-out by another patron (Patron A). Recall requests typically ask Patron A to bring the item back before it's original due date/time. This differentiates it from a hold request where Patron A cannot renew the item. Once the requested item is returned, it is routed to the requested location, if necessary, and then placed on the hold shelf.
The recall request process prompts several patron notices. Specific notices are outlined below.
For each of these scenarios, exact timing and conditions are determined by a combination of notice policies and circulation rules, and exact wording is determined by templates. Each of these specific scenarios may or may not be used by every institution. If there's no corresponding policy defined in settings, then these scenarios won't apply.
Scenario 1
Given a recalled item
When it is scanned in at requested location, item status is changed to "available - awaiting pickup," and it's put on hold shelf for the patron
And there's a matching circulation rule, notice policy and template
Then send an available notice to the requester at the top of the queue
TestRail: Results
Attachments
Issue Links
- has to be done after
-
CIRC-256 Send request-related notices (item status change)
-
- Closed
-
- relates to
-
MODSENDER-4 SPIKE: Determine Technical approach for sending patron notices
-
- Closed
-
-
CIRC-387 Send request- related notices (time based)
-
- Closed
-
-
UICIRC-158 End to End Testing: Send recall request- related notices (user initiated)
-
- Closed
-
-
UXPROD-1589 Send patron notices for item status changes (request related), such as available - awaiting pickup (i.e., available notice for recalled item) via email
-
- Closed
-