Consultations - Change States

[m-prodan]

• As a Ministry User
• I want to update the states of my consultation
• so that I can better track where the request is at from my queue

Assumptions & Scope What are the assumptions for this story? Only Ministry Coordinators can update the state on consultations There will be less states in a consult vs a traditional FOI Requests State changes should not be included in FOI Request Analytics Ministry coordinators can change states as needed, there is no enforcement of when states can change.

What is IN scope?

What is NOT in scope?

Acceptance Criteria

Scenario 1: Change State from Open - State Options

• GIVEN a Ministry Coordinator is on an Open Consultation
• WHEN they activate the state drop down
• THEN they will see the following options: Harms Assessment; Records Review; Ministry Sign-Off; Response and Closed

Scenario 2: Change State

• GIVEN a Ministry coordinator has activated the state drop down
• WHEN they select a state
• THEN the state of the consultation will be updated to the selected state
• AND the State options for the drop down will be the same as in AC 1, except for the state the request is already in

Scenario 3: Close Consultation

• GIVEN a Ministry Coordinator has activated the state drop down
• WHEN they select "Closed" from the dropdown menu
• THEN a modal will open up showing the "Close Consult" window, showing the following information: Public Body, Request ID, Request Description Closing Date of Consult. Reason for Closing Consult, Save and Cancel button.
• AND Public Body, Request ID, and Request description will be autofilled (if no data, display n/a)
• AND the save function will not be active

Scenario 4 Cancel Back to Prior State:

• GIVEN the Ministry Coordinator has opened the close request modal
• WHEN I click the cancel button
• THEN the modal will close, and that state of the request will remain as it was before selecting the close state

Scenario 5: Calendar picker for Closing date:

• GIVEN the Ministry Coordinator has opened the close request modal
• WHEN the Closing Date calendar picker has been selected
• THEN a calendar picker will appear to select a date
• AND when a date is selected, it will appear as the value for the close date

Scenario 6: Closing Date Cannot be in the Future

• GIVEN the Ministry Coordinator has opened the close request modal,
• WHEN they have activated the calendar picker for Close Date
• THEN the analyst will be unavailable to pick a date in the future

Scenario 7: Reason for Closing Request

• Given the Ministry Coordinator has opened the close request modal
• WHEN the "Reason for Close" drop down is selected
• THEN the following options will be available to select: Access Denied, Full Disclosure, Partial Disclosure, Withdrawn

Scenario 8: Reason for Closing Request

• Given the Ministry Coordinator has opened the close request modal
• WHEN the "reason for close" drop down is selected
• AND an option is selected
• THEN the option will be displayed in the field

Scenario 9: Save Change button becomes Active

• GIVEN the Ministry Coordinator has opened the close request modal
• WHEN the mandatory fields have any value filled in: Closing date, Reason for Closing Request, Number of Pages Release, and Number of pages reviewed
• THEN the Save Change button will become active

Scenario 10: Clicking Save Change button

• GIVEN the Ministry Coordinator has opened the close request modal
• WHEN all mandatory fields are filled in
• AND the save change button is clicked
• THEN the modal will close
• AND state of the request will be update to "Closed"
• AND colour of the left navigation tab will turn to black
• AND the request will be removed from all assigned queues
• AND the request details will be Read Only

Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)

Validation Rules? (If yes, list here)

Design @xxx - please link the Design here

Definition of Ready

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

Definition of Done

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

[m-prodan]

State Change for Consults Story

Will likely need some designs for this one @JHarrietha-AOT

Thought here is to track a consultation from the lifecycle of a request. Because this will be Ministry driven I am not including any validation or rules (ie: can go from Open to Sign-off, if they wish).

Copied the AC from closing a request to address that piece of the consult.

Please review when you have time @arielleandrews @lmullane @mpilchar