Summary of Redactions

[sumathi-thirumani]

• As an IAO user
• I want to be able to differentiate between redaction codes applied on original redline, vs the OIPC layer.
• so that I always have the most up to date info

Assumptions & Scope
It was learned during development of OIPC stories that sections changed to the OIPC review layer compound with the existing redline layer. This may complicate or confuse someone that looks back on a request and may result in inaccurate information.

What is IN scope?
Updates to summary of redactions when an OIPC review layer is created

What is NOT in scope?

Acceptance Criteria

Scenario 1: Summary of Redactions - OIPC Layer

• GIVEN an IAO user is on an OIPC review request
• WHEN they create an OIPC layer
• THEN the summary of redactions will include a second line showing "OIPC Summary of Redactions"
• AND the Redline summary of redactions will still persist

Scenario 2: Summary of Redactions - OIPC - Changes

• GIVEN an IAO user is on the OIPC layer of a records package
• WHEN sections for redactions have been completely removed
• OR new sections for redactions have been added
• THEN the summary of redactions for the OIPC layer will update accordingly.

Scenario 3: xxxxxx
...

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]

@sumathi-thirumani-aot - AC added - thanks for catching this.

[sumathi-thirumani]