Details
Description
Assumptions
This story assumes the "check-in-by-barcode" endpoint has been implemented according to the specification in CIRC-154. The additional logic described below is executed after the item (and corresponding loan) is retrieved and the regular check in logic is performed: the item status is changed to Available and open loan, if any, is closed. This means that the Item will undergo a series of status changes (Checked out -> Available -> In transit) throughout the process. It also means that failures in a particular step of process will terminate remaining steps and leave the item, loan (and in the future: requests) in the last updated state and report the failure back to the user.
Th flow:
1. Item is scanned, we look up the open loans for the item, if there is an open loan we close it and continue, if not we continue
2. We perform a "has open fulfillable (hold) request" check, if true we set the item status to "Awaiting pickup" and change the request status and stop
(we are not handling delivery requests)
3. We perform a "is item at home location" check, if true we set the status to Available, if false we set the status "In transit"
In transit status change logic
1. Find the service point that the item was checked in at (included in by CIRC-104, supported by CIRC-151) by looking at the loan's checkinServicePointId field
2, Look up which locations that service point serves (using an array search on the servicePointIds property of locations)
3. Determine if the item’s home location (effective) is served by the checkin service point by checking if it's included in the list of locations retrieved in the previous step (if so, continue normally, I’ve omitted this flow for simplicity)
(all steps below, are for when not at service point that serves effective location)
4. Look up the primary service point for the item’s effective location (using an ID lookup of location) – which we want to store as the destinationServicePointId (new field) on the item to address UICHKIN-40 JFS: looks like we need a issue to add dSPId to the item schema
5. Change the item status to from Available to In transit likely we need to handle the situation when item is scanned again
(follow the rest of the check in process)
Errors
There are a number of failure scenarios to account for here:
• What should happen if there are no service points that serve the home (effective) location? JFS: report error and terminate
• What should happen if there is no primary service point that serves the home location? JFS: report error and terminate
• What should happen if any lookup of a location or service point fails (presumably overall fail) JFS: report error and terminate
Backend blocker for UICHKIN-17
TestRail: Results
Attachments
Issue Links
- blocks
-
CIRC-172 Backend Work for UICHKIN-49: Transit to pickup service point for Request
-
- Closed
-
-
UICHKIN-17 Item status change upon checkin: in transit
-
- Closed
-
-
UICHKIN-40 Display destination service point for in transit items
-
- Closed
-
-
UICHKIN-41 Display modal when items go in transit
-
- Closed
-
-
UICHKIN-44 Check in items that are In transit
-
- Closed
-
-
UICHKIN-60 Print Transit Slip at Check-in
-
- Closed
-
- is blocked by
-
CIRC-104 Store service point of check-in/-out along with the loan
-
- Closed
-
-
CIRC-151 Provide pickup service point name for requests
-
- Closed
-
-
CIRC-154 design and implement a "check-in-by-barcode" API
-
- Closed
-
-
MODINVSTOR-230 Store destination service point item is in transit to
-
- Closed
-