Requests - Display of actions in Detail and Edit

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

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