Skip to content

Latest commit

 

History

History
59 lines (40 loc) · 2.98 KB

0032-track-deletion-with-other-models.md

File metadata and controls

59 lines (40 loc) · 2.98 KB

32. Track deletion using other models

Date: 2023-11-17

Status

Accepted

Areas of impact

  • Compliance
  • Content
  • CX
  • Design
  • Engineering
  • Policy
  • Product
  • Process
  • UX

Related resources

Context

As outlined in the expanded user role management ADR, we need to delete Access entries. It’s also quite likely that we might need to delete a variety of other objects, in particular User entries, in the future.

Here “deletion” means “remove from the code paths that deal with active elements of our application” and not “scour from the earth and from history”.

For record-keeping purposes, we should not destroy the information that was in these entries, but store it for potential future investigation.

In the case of Access entries, if we were to delete the entires without doing anything else, we could run into this scenario:

  1. User A adds User C as a auditee certifying official
  2. User C makes some of the changes to the submission.
  3. User A realizes that the auditee certifying official should actually be User Z.
  4. User C’s Access entry is deleted and a new one is created for User Z.
  5. Some time later, there are questions about who did the edits in step 2.

Since the Access object active at the time is now gone, figuring out that link would require more work than seems ideal.

Decision

  • Create a new DeletedAccess class that would be created whenever the application deletes an Access object.
  • This would have all of the fields in Access1 plus:
    • removed_at (UTC timestamp)
    • removed_by_user (reference to a user object)
    • removed_by_email_address (email address of removing user) (these last two are not actually redundant).
    • removal_event (this would mostly be something like access-change, but could theoretically in future include things like account-inactivity, security-incident, data-correction, etc.)

This approach has the advantage of not touching any of the existing Access code or related code paths, lowering the likelihood of breaking existing features; the same would apply to User, etc.

This would also be the path to follow for future entries of other kinds that we might might need to remove—if we need to remove User entries, we would put them in a DeletedUser table with the same four additional fields.

Footnotes

  1. sac, role, fullname, email, and user. ↩