Filter Records by Modified Date/Date Uploaded

[m-prodan]

• As an IAO or Ministry user
• I want to be able to sort the records log view by modified date, or date uploaded
• so that I can more easily find problematic files in the records packages

Assumptions & Scope This is feedback we are hearing from users where it is very hard in large packages to determine exactly where a file is compared to the harms package. This can create troubles/issues if the user is trying to replace a bad conversion, and can't easily see where the file lives in the records log for replacement.

The default view will be upload date, and we will use a slider design to have them switch to modified date, similar to what we did with the redaction code sort.

Sort order should be sorted by modified date in ASC order (oldest to newest, which is how the package is currently ordered).

When filtering by a tag (e.g., division, error, etc.), the files should also be sorted by modified date in ASC order (oldest to newest, which is how the package is currently ordered).

What is IN scope? Adjusting sort order of the files listed in the records log

Acceptance Criteria

Scenario 1: Records Log - Default View

• GIVEN a user is on the records log of a request
• WHEN there are records uploaded
• THEN the files will be sorted by date uploaded
• AND the sort slider will be set to 'Date uploaded' (design TBD - devs can mock this up in Jackie's absence)

Scenario 2: Records Log Sort - Date Modified

• GIVEN a user is on the records log
• AND the slider is set to date uploaded
• WHEN they click on the slider to 'Date modified'
• THEN the order of the files will appear in modified date from oldest to newest
• AND the attachments/child files will continue to be nested under the corresponding parent/msg file in modified date order

Scenario 3: Records Log Sort - Date Uploaded

• GIVEN a user is on the records log
• AND the slider is set to date modified
• WHEN they click on the slider to 'Date uploaded'
• THEN the order of the files will appear in their upload date, from newest to oldest
• AND the attachments/child files will continue to be nested under the corresponding parent/msg file in date uploaded order

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]

File sort story by modified date vs date uploaded. I am thinking we use a slider design consistent with what we did for the redaction tool. We can figure out the placement independently

cc: @lmullane @liseandtea @KyEggleston @abin-aot

[lmullane]

@JHarrietha-AOT, we will need a design. Dev team is suggesting similar to GitHub:

Pagination is not in scope for this ticket but may need pagination in another ticket to cover use cases where ministries have thousands of records for a request. cc @m-prodan