MNTOR-3971: Use last optout date instead of last update

[Vinnl]

References:

Jira: MNTOR-3971
Figma: N/A

Description

This newly-added API response property accurately reflects the last scan date (which we had incorrectly hoped the last update date to do).

Note that I'm not familiar with the QA customs tool, so I mostly followed existing patterns and added last_optout_at wherever I could find optout_attempts. I think that covers it, but it uses quite a few custom types and otherwise lives fairly separate from the rest of the codebase, so I'm not particularly confident.

Screenshot (if applicable)

Not applicable.

How to test

Make sure the DataBrokerRemovalAttempts and AdditionalRemovalStatuses flags are on, which in Storybook you can do by setting it to:

["DataBrokerRemovalAttempts", "AdditionalRemovalStatuses"]

(You might have to refresh, because the initial value Storybook sets is {}, which is not an array and thus causes an error.)

A Plus user (e.g. in the above story) should then see the removal attempt in the Fixed tab for any "Requested removal" scan results. If you want to be sure that it's showing the last optout date as returned from the API, you can set it to some recognisable value in /src/apiMocks/mockData.ts.

Checklist (Definition of Done)

• Localization strings (if needed) have been added.
• Commits in this PR are minimal and have descriptive commit messages.
• I've added or updated the relevant sections in readme and/or code comments
• I've added a unit test to test for potential regressions of this bug.
• If this PR implements a feature flag or experimentation, I've checked that it still works with the flag both on, and with the flag off.
• If this PR implements a feature flag or experimentation, the Ship Behind Feature Flag status in Jira has been set
• Product Owner accepted the User Story (demo of functionality completed) or waived the privilege.
• All acceptance criteria are met.
• Jira ticket has been updated (if needed) to match changes made during the development process.
• Jira ticket has been updated (if needed) with suggestions for QA when this PR is deployed to stage.

[github-actions]

Preview URL 🚀 : https://blurts-server-pr-5591-mgjlpikfea-uk.a.run.app

[mansaj]

It's best practice to separate out the db migration part of the PR with the business logic on top.

This way, in the event of a rollback, we can rollback the part 2 without running into the similar issue we had before

[Vinnl]

@mansaj I did actually think of that, and then promptly forgot about it 😅 I split the commits up now, with a separate migration commit in 9670eb8.

[flozia]

Looks good.

[Vinnl]

@mansaj Could you also review to make sure the migration and back-end parts are OK?

[mansaj]

@mansaj I did actually think of that, and then promptly forgot about it 😅 I split the commits up now, with a separate migration commit in 9670eb8.

Sorry, I actually meant to for this PR to be split into 2 PRs. The reason is stated above, but with commits, we'd still have to do cherry picking etc in the event of a rollback. Just my 2c

[mansaj]

Just the comment about splitting this PR into two. Otherwise LGTM

[Vinnl]

PRs aren't separately recorded in Git history; individual commits can be rolled back regardless of whether they're a PR merge commit or a regular commit (i.e. reverting a PR through the GitHub UI is just executing git reverts as well). But happy to create a separate PR containing just the first commit :) #5618

[github-actions]

Cleanup completed - database 'blurts-server-pr-5591' destroyed, cloud run service 'blurts-server-pr-5591' destroyed