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

Move Requests from One Item to Another

    XMLWordPrintable

Details

    • Story
    • Status: Closed (View Workflow)
    • P2
    • Resolution: Done
    • None
    • 1.11.0
    • Core: F - Sprint 64, Core: F - Sprint 65, Core: F - Sprint 66, Core: F - Sprint 67
    • 13
    • Prokopovych

    Description

      Purpose: To enable library staff to easily move requests from one item to another when the originally requested item has gone missing or a new copy has been acquired. This story focuses on the simple scenarios. See linked stories for handling of other scenarios.

      User story:
      As a librarian
      I want to be able to move requests from an item with a long queue to an item with a shorter queue
      So they can be fulfilled faster and, ideally, in the order they are created

      As a librarian
      I want to be able to move requests off an item that has gone missing
      So they can be fulfilled by another item

      Scenarios:

      1. Scenario
        • Given a request for which fulfillment has not yet begun (so request status = Open - not yet filled)
        • When the pane header dropdown is opened
        • Then a move request option should display
      2. Scenario
        • Given move request is selected
        • Then a Select item popup should display:
          • Header: Select item
          • Subheader 1: Other items in <ResourceTitlefromInstance>
          • Subheader 2: <Count> records found
          • Body is a table with the following columns:
            • Barcode - Item barcode
            • Item status - Item status (e.g. Available, Checked out)
            • Request queue - Count of open requests on item (request status = Open - not yet filled, Open - Awaiting pickup or Open - in transit)
            • Location - Effective location for item
            • Material type - Material type specified for item
            • Loan type - Loan type specified for item (use temporary, if populated, otherwise use permanent)
          • Styling should mimic that of the find user popup (minus the filters)
          • NOTES: RA SIG also wanted to see call number and enumeration as columns here, but I am going to hold off on adding those until we have the call number logic worked out (UXPROD-1626)
      3. Scenario
        • Given the item select popup
        • When displayed
        • Then a row should display for every other item within the same instance
        • NOTE: There are some situations where you might want to move a request to an item in another instance but the RA SIG sees this as an edge case so we will not implement that just yet. In general, you want to move requests to another copy in the same instance.
      4. Scenario
        • Given a row in the item select popup
        • When clicked
        • Then:
          1. The request whitelist is checked to see if the current request type is allowed on the selected item
            • If no, AND:
              • There is >1 possible request type for the destination item, the user is prompted to select a new request type from the types allowed per the whitelist
              • There is only one possible request type for the destination item, the user is just notified that the request type will change
            • If yes (request type is allowed), the original request type is retained.
          2. The request policy is checked (via circ rules) to determine if the request type is allowed for the patron/item combination
            • If no:
              • Request creation is prevented CB: I tested this by moving a recall to an item for which only holds were allowed and it prevented the move per this acceptance criterial. However, it occurs to me that it would be nice if, instead, we could offer the user the ability to switch to a hold request. So a modal that says " <RequestType> requests are not allowed for this patron and item combination." but then offers the ability to cancel the request move OR select from possible request types. What do you think? Would this be very difficult to implement? Should I create another story for it if I want it done?
              • Modal should display:
                • Header: Request not allowed
                • Body: <RequestType> requests are not allowed for this patron and item combination.
                • Buttons:
                  • Close (closes modal and returns user to item select popup)
                  • X (same behavior as close button)
              • Note this modal has already been coded as part of UIREQ-211
            • If yes, the request is moved to the new item
          • NOTE: We would love to just have the list of items pre-filtered to only display those that are allowed per request policy so the user doesn't need to select an item only to find it's not possible for the request to be moved there. However, making that happen is significantly more work so we are putting it out of scope for now. Please see UXPROD-1630 for more details, if you are interested.
      5. Scenario
        • Given Request R is moved to Item X
        • When request queue for Item X is viewed
        • Then:
          • Destination request queue is ordered FIFO (by request create date). This will ensure the first to request receives the first copy. CB: I created 2 requests on item 1. Then I created a request on item 2 for a requester named Mraz. Then I created another request on item 1 for a requester named Rutherford. I then moved Mraz's request to item 1. I expected it to be in position 3 of the queue because it was created before Rutherford's request, but Rutherford's remained in position 3 and Mraz's went to position 4.
          • However, once request fulfillment has begun for the request in position 1 (request status = “Open - In transit” or “Open - Awaiting pickup”), that request cannot be displaced from position 1 of the queue
          • NOTE: Future plans for the request queue include the following (out of scope for now):
      6. Scenario CB: If this is really complicated, we could split this out and disallow moves to available items for the purposes of this story. I would then create a separate story for this behavior.
        • Given Request R is moved to Item X
        • When Item X's starting status is Available
        • Then:
          • Request R should change to a Page request
          • Item X's status should be changed to Paged
      7. Scenario
        • Given a request is moved with or without changing request type
        • When moved
        • Then patron notices should not be triggered
      8. Scenario CB: This temporary solution isn't in place, but maybe the full solution is by now. I will test as part of UIREQ-271
        • Given Item X is Checked out AND has 0 recall requests in the request queue (so, since Chalmers is only using recalls, for them this would mean no requests on Item X)
        • When Request R is a recall request move to Item X is attempted
        • Then:
          • Move should not be allowed
          • Popup should display reading "Recalls can't be moved to checked out items that have not been previously recalled."
          • Assumption is that this error will come from backend
        • CB: This is a temporary solution. A separate story has been created for the handling of such a move (which is somewhat complex): UIREQ-271

      TestRail: Results

        Attachments

          1. Move request in dropdown.PNG
            Move request in dropdown.PNG
            142 kB
          2. screenshot-1.png
            screenshot-1.png
            35 kB
          3. SelectItem.png
            SelectItem.png
            15 kB

          Issue Links

            Activity

              People

                mpk35 Michal Kuklis
                cboerema Cate Boerema
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases