FFS-3880: delete on exit when creating an activity

[millerti]

FFS-3880

Changes

Now, when you exit the activity flow during creation only, the records we created along the way will be deleted. As such, you will no longer see a representation of the incomplete activity on the Activity Hub when you return to it. This should work whether you hit the exit button, the back button, or even navigate to the hub manually via URL.

Testing instructions

1. When creating a new activity, verify that exiting early (before hitting save on the review page) results in your progress being discarded in all 6 activity flow types (all 4 self-attested flows and 2 validated flows). You can verify that this is working because when you return to the hub you should not see a card for your work, whereas before you would.
   1a. You will need to verify this at various points in the flow. Exit from the entry page, various hours entry pages, the document upload page, and the review page. Your changes should be discarded no matter where you exit the flow.
2. When editing a previously-created activity, verify that when you exit a flow your work is still saved. Nothing should be deleted. This too needs to be verified in all 6 flow types, also exiting at various points in the flow.
3. Try exiting flows using the back button or by manually changing your URL to be /activities to go back to the hub. Your work should be deleted no matter what when you're in a creation flow.
   3a. Also try the multi-tab situation Daphne commented about.
4. Please pay special attention to Education partial attestation flows. I think I did this right, but I am not 100% sure and I could have broken something.

Acceptance testing

• Acceptance testing in PR Environment
  • This change can be verified in a PR environment. Run this Github Action with the existing PR and most recent git sha.

[daphnegold]

This is great so far! Let me know what you think about adding logic for which flow owns the deletions.

[millerti]

Curious about what other people think about this cleanup strategy. I considered making the redaction process clean these up, but I chose not to because I don't like overloading something called "redact" with non-redaction data deletion. But I could be convinced that's ok.

[daphnegold]

I like keeping this separate from redaction. They feel conceptually different. I still have some misgivings about relying on a cleanup job for this strategy in general, though.

[millerti]

Yeah, I don't love it either. As discussed, it seems like we may want to eventually expose unfinished drafts on the hub, pending design approval, so it doesn't make sense to just delete on exit yet. Let's talk about it at eng time on Monday.

[daphnegold]

I'm going to ship this, but looking forward to the follow up with product & design about possible draft mode, quirks like browser back lets you keep editing, deleting on exit vs the job. In the future, moving towards temp session data storage until save might make it feel less like we are fighting Rails to accomplish this.

One thing that is worth looking at is the PDF, but that might be out of scope and we have forthcoming work for that, right?

[millerti]

I'm going to ship this, but looking forward to the follow up with product & design about possible draft mode, quirks like browser back lets you keep editing, deleting on exit vs the job. In the future, moving towards temp session data storage until save might make it feel less like we are fighting Rails to accomplish this.

One thing that is worth looking at is the PDF, but that might be out of scope and we have forthcoming work for that, right?

Yeah, all good points. I'm bringing this up with Design, then we can solution with Eng. Agree the PDF is out of scope for now.