Details
-
Story
-
Status: Closed (View Workflow)
-
P1
-
Resolution: Done
-
None
-
None
-
None
-
-
Vega
Description
Context
Hold requests include items that are currently checked-out by another patron (Patron A). A hold request restricts Patron A from renewing the item. This differentiates it from a recall request where Patron A must return it sooner than the original due date/time. Once the requested item is returned, it is routed to the requested location, if necessary, and then placed on the hold shelf.
The hold 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 - Hold request
Given an item with a status of checked-out
When it is requested for hold
And there's a matching circulation rule, notice policy and template
Then send a request confirmation notice to requester (Patron B in diagram)
Scenario 2 - Cancel
Given a requested item for hold
When a FOLIO operator or patron cancels the request
And there's a matching circulation rule, notice policy and template
Then send a cancellation confirmation notice to requester (Patron B in diagram)
TestRail: Results
Attachments
Issue Links
- is blocked by
-
CIRC-262 Implement sending request-related notices (user-initiated events)
-
- Closed
-
- relates to
-
CIRC-388 Send hold request-related notices (time based)
-
- Closed
-
-
MODSENDER-4 SPIKE: Determine Technical approach for sending patron notices
-
- Closed
-
-
UICIRC-218 End to End Testing: Send hold request-related notices (item status change)
-
- Closed
-
-
UXPROD-1585 Send patron notices for user initiated request events, such as recall request, page request, hold request, cancel, etc (via email)
-
- Closed
-