Notification for request in Call For Records

[lmullane]

• As a ministry coordinator
• I want an automated notification when a request goes into Call For Records
• so that I know my team has a new request to action

Assumptions & Scope What are the assumptions for this story?

When a request goes to a ministry in Call For Records, it is assigned to the ministry team, not an individual assignee. Currently, notifications are only sent to an individual who is the assignee or a watcher. This would be a change in that pattern. For discussion.

Should all ministry team members receive the notification?

What is IN scope?

Notifications to the ministry coordinator(s) when a request goes into Call For Records

What is NOT in scope?

Other notifications

System generated comments of the state change are already in place.

Acceptance Criteria

Scenario 1: Automated notification for unassigned Call for Records request

• GIVEN an request is in the Open state
• WHEN IAO user changes the request state to CFR
• THEN a notification will trigger to all ministry coordinators with the following message: "New request is in Call for Records"
• AND the ministry coordinators will not yet be assigned or watchers for the request.

Scenario 2: Notifications auto-dismiss upon assignment

• GIVEN a request is in the Call For Records State
• AND the request is unassigned
• WHEN the request is assigned to a Ministry user
• THEN any notifications sent to users notifying the new request is in Call for Records that have not been dismissed, will be automatically dismissed

...

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?

[lmullane]

Should we automatically make all ministry coordinators a watcher?

[m-prodan]

Update to include scenario - notification auto dismisses for all when assigned.

[m-prodan]

AC updated per discussion at refinement.

Decision from refnement: not to auto-assign as watchers.

[m-prodan]

Updated AC per discussion with Aparna - since request ID is already showing on the notification itself, no need to put it again in description (AC 1 - removed request ID from the notification message)

[m-prodan]

Working as expected - QA Passed great work @aparna-aot