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

Requests - Display of actions in Detail and Edit

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Draft (View Workflow)
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
    • Template:
    • Analysis Estimate:
      Small < 3 days
    • Front End Estimate:
      Medium < 5 days

      Description

      Purpose: To capture and display actions on a request. Request actions track the history of what has happened to a given request. All requests will have at least one request action (the creation of the request) and as things happen to the request (it is edited, it is cancelled) new actions will be logged against the request.

      This story will focus on displaying the request actions in Request Details and Edit Request.

      Scenarios

      1. Scenario
        • Given the “Request details” screen
        • When displayed
        • Then a “Request actions” collapsible sub-section should appear, as shown in the linked wireframe
      2. Scenario
        • Given the “Request actions” collapsible sub-section of Request details
        • When the sub-section is collapsed
        • Then just the sub-section Title “Request actions” should appear
      3. Scenario
        • Given the “Record actions” collapsible sub-section in Request details screen
        • When the sub-section is expanded
        • Then a list of all actions on the request should display, newest to oldest, with the following data elements, as shown in the linked wireframe
          • Action date – date and time of the action
          • Action – see table below
          • Request status (the new request status that resulted from the action)
          • Source – the name and username of the user who performed the action (this could be either a staff person, the requester) or the system process that performed the action
      4. Scenario
        • Given an expanded “Record actions” collapsible sub-section in the Request details screen
        • When a Cancellation action is displayed
        • Then the following information should display
          • Action date – date and time of the action
          • Action – Request cancelled, the Reason for cancellation that was chosen by the operator, and any data that was entered into the Additional information field, concatenated and separated by dashes, as seen in the linked mockup
          • Request status (the new request status that resulted from the action)
          • Source – the name and username of the user who performed the action (this could be either a staff person, the requester) or the system process that performed the action
      5. Scenario
        • Given the “Edit request” screen
        • When displayed
        • Then a “Request actions” collapsible sub-section should appear, as shown in the linked wireframe
      6. Scenario
        • Given the “Record actions” collapsible sub-section on the Edit request screen
        • When collapsed
        • Then just the sub-section Title “Request actions” should appear
      7. Scenario
        • Given the “Record actions” collapsible sub-section on the Edit request screen
        • When the sub-section is expanded
        • Then a list of all actions on the request should display, newest to oldest, with the following data elements, as shown in the linked wireframe
          • Action date – date and time of the action
          • Action –see table below
          • Request status (the new request status that resulted from the action)
          • Source – the name or username of the user who performed the action (this could be either a staff person, the requester) or the system process that performed the action
      8. Scenario
        • Given an expanded “Record actions” collapsible sub-section on the Edit request screen
        • When a Cancellation action is displayed
        • Then the following information should display
          • Action date – date and time of the action
          • Action – Request cancelled, the Reason for cancellation that was chosen by the operator, and any data that was entered into the Additional information field, concatenated and separated by dashes, as seen in the linked mockup
          • Request status (the new request status that resulted from the action)
          • Source – the name and username of the user who performed the action (this could be either a staff person, the requester) or the system process that performed the action
      Action Resulting Request status
      Request created Open - not yet filled
      Request awaiting pickup Open - awaiting pickup
      Request cancelled Closed - cancelled
      Request filled Closed - filled
      Request expiration date reached Closed - unfilled
      Hold shelf expiration date reached Closed - pickup expired
      Hold shelf expiration date edited Open - awaiting pickup
      Request expiration date edited (no status change)
      Fulfillment preference changed (no status change)
      Pickup location changed (no status change)
      Delivery address changed (no status change)

      Out of scope for this story: Action - Request in transit

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                cboerema Cate Boerema
                Analysis Estimator:
                Tania Fersenheim Tania Fersenheim
                Front End Estimator:
                Matt Connolly Matt Connolly
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases