Details
-
Story
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Done
-
None
-
-
eHoldings Sprint 75, eHoldings Sprint 76
-
8
-
Spitfire
Description
Purpose: To futher the implementation of delivery requests. In FOLIO today, it's possible to select "delivery" as a request fulfillment preference, but requests created this way aren't doing what they need to (upon check in, the requested item is being routed back to its home location for reshelving as if there were no request queue).
User stories:
As a circulation staff person
When I check in an item which has been requested for delivery
I want to know that so I can route it to the correct address
As a circulation staff person
When I check in an item which has been requested for delivery
I want the item to be automatically checked out to the requester (because there is no service point or library staff at the delivery location - checkout must happen before it leaves the library)
Scenarios:
- Scenario
- Given Request A is a delivery request at the top of the queue for Item X (fulfillment type = Delivery)
- When Item X is checked in at any service point
- Then:
- Item X's status is "Awaiting delivery"
- Request status becomes "Open - Awaiting delivery"
- “Route for delivery” modal displays in FOLIO (
UICHKIN-109) - If configured, delivery staff slip is printed (delivery address should be available token) (
UICIRC-316,UICIRC-319,UICIRC-320,UITEN-54) - Check out app is opened and pre-populated with the patron (requester) and item (
UICHKIN-109)
- Scenario*
- Given Request A is a delivery request at the top of the queue for Item X (fulfillment type = Delivery)
- When Item X is checked in at any service point a second time
- Then all of the above still hold
- Scenario*
- Given Item X is "Awaiting delivery" and Request A is "Closed - Cancelled" or "Closed - Unfilled" (because the request has been cancelled (
UIREQ-356) or expired (CIRC-509)) - When Item X is checked in at any service point
- Then FOLIO changes the item status according to existing rules, for example:
- In transit (if item is needed at another service point for reshelving or request)
- Awaiting pickup (if item is needed at this service point for a request with hold shelf pickup)
- Available (if item is not requested and the current service point is associated with the items' effective location)
- Awaiting delivery (it there is another delivery request at the top of the request queue)
- In transit (if item is needed at another service point for reshelving or request)
- Given Item X is "Awaiting delivery" and Request A is "Closed - Cancelled" or "Closed - Unfilled" (because the request has been cancelled (
- Scenario*
- Given Item X is "Awaiting delivery" for Requester A
- When Item X is checked out at any service point
- Then checkout should only be allowed for Requester A
*These scenarios rely on existing logic and will likely just work without any development
TestRail: Results
Attachments
Issue Links
- defines
-
UXPROD-113 Fulfilling delivery requests
-
- Closed
-
- has to be done after
-
CIRC-437 [Spike] Delivery requests: request processing once an item is checked in
-
- Closed
-
-
CIRCSTORE-169 Add "Open - Awaiting delivery" status to Requests
-
- Closed
-
-
UICIRC-357 [Spike] Delivery Requests: request processing when item checked-in on Front-End
-
- Closed
-
- has to be done before
-
CIRC-509 Expiration of Delivery Requests
-
- Closed
-
-
CIRC-511 Update request whitelist to handle new "Awaiting delivery" status
-
- Closed
-
- relates to
-
UICHKIN-109 Route for delivery check in modal + delivery slip
-
- Closed
-