Uploaded image for project: 'ui-requests'
  1. ui-requests
  2. UIREQ-334

When Moving Request from One Item to Another, Put at End of Queue



    • Core: F - Sprint 77, Core: F - Sprint 78
    • 5
    • Prokopovych


      Purpose: We are going to have to revisit how we handle queue ordering when moving requests from one item to another now that we are going to allow manual reordering of request queues (per UXPROD-1242 and UIREQ-112, more specifically). Currently, when requests are moved from one item to another, they are placed in the destination queue FIFO by original request creation date. That is great in that it allows requests to be fulfilled in the order they are received. However, we now want to implement manual reordering of request queues and these features are not in conflict. The simplest way to resolve this conflict is to place moved requests at the end of the queue and ask the librarian to reorder them (they will often order them according to request creation date). See discussion notes below for discussion.

      User story:

      • As a circulation staff member who is moving a request from one item to another
      • I want the moved request to appear at the end of the destination queue by default but an easy way to move it to another position in the queue (using manual queue reording (UIREQ-112))
      • So I can decide if I want to fulfill FIFO or make an exception for some reason


      1. Scenario
        • Given I am moving a request from one item to another
        • When the move has completed successfully
        • Then:
          • Success message should display (this is already working) Works but so slooooow
          • Move request modal should close (this is already working) Works but so slooooow
          • The request queue page with reorder capabilities (UIREQ-112) should display for the destination queue and my moved request should appear at the end (last position) of the queue Works but so slooooow
      2. Scenario
        • Given the request queue page with reorder capabilities
        • When closed by clicking the X in the corner
        • Then the moved request should display in view mode in the Requests app

      Discussion notes:

      How we came to decide on this change:

      CB: Do we need to revisit the move requests functionality to make sure it still works? The current logic says that, when a request is moved from one item to another, it is slotted into the new queue according to request creation date so that the new queue is ordered FIFO. There are a couple of exceptions to this (i.e. a moved request can't supersede a request in position 1 when that request is a page or when it has already begun fulfillment). But generally speaking, that is the way the feature works. How can we reconcile these two features? Maybe we should say that, if a queue has been reordered, it gets a flag or some sort which tells the move request feature to just put the moved feature at the end of the queue. A popup could alert the user to this fact during the move. Thoughts?

      Marc: When does a queue not become manually reordered?

      • Could be when the queue empties, but that is very complex
      • Could be a flag on a request that has been re-ordered (and that would apply too other requests whose position changed as the consequence of an explicit move). But then we would have to modify every request in the queue at the time of reorder (even if only the last two in the queue were swapped)

      The simplest solution from a technical perspective is, that for every move, item would automatically go to the end of the queue and user would have to manually put it in the order they want

      CB: Checked with RA SIG and Chalmers and both were okay with the simple approach described above.

      TestRail: Results


          1. MoveRequestsSlow.mp4
            3.18 MB
          2. Screenshot_2.png
            26 kB
          3. screenshot-1.png
            342 kB
          4. SlowMovingRequest.mp4
            6.52 MB
          5. WrongRequestOpenAfterMove.mp4
            6.48 MB

          Issue Links



                mpk35 Michal Kuklis
                cboerema Cate Boerema
                Cate Boerema Cate Boerema
                0 Vote for this issue
                5 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases