Uploaded image for project: 'mod-circulation'
  1. mod-circulation
  2. CIRC-146

change item status to "in transit" upon checkin



    • Prokopovych



      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)


      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


          Issue Links



                marcjohnson Marc Johnson
                jakub Jakub Skoczen
                0 Vote for this issue
                5 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases