Background

Deletion of records in Registry v4 has several design quirks owning to how the codebase has evolved over the years.

• Many records can be Suspended, which generally deactivates the record but leaves it visible in the Registry interface. Sanity checking of Suspended records is inconsistent... it may be possible for a configuration to reference a Suspended object. (eg: CO-332, CO-1760)
• A CO Person may be set to Deleted status.
• Prior to the introduction of ChangelogBehavior in Registry v0.9.4, all Delete operations were hard deletes (records were removed from the database).
• CO Person Expunge was introduced to simplify removal of CO Person objects and related data. Expunge includes special logic such as rewriting history records when the expunged subject was an actor on another CO Person.
• ChangelogBehavior converted most Deletes into soft deletes (records are retained in the database, but flagged as deleted), except for removal of the CO itself (which remains a hard delete). The name Expunge suggests records are removed from the database, but that does not in fact happen.
• In order to handle the deletion of large COs, Registry v4.0.0 introduced Garbage Collection. When a CO is deleted, it is moved into a In Trash state. The GarbageCollectorJob eventually removes the CO from the database.
• Handling of delete operations in ProvisionerBehavior has not been clearly refined with the introduction of ChangelogBehavior.
• Deleting of a configuration object (eg: a Message Template) used by another configuration object (eg: an Enrollment Flow) generally does not perform dependency checks. Because of ChangelogBehavior, this can result in invalid configurations.

Approach

1. In general, a configuration object may not be Suspended if it is in use, however exceptions are permitted if they are documented as Application Rules.
2. Person Deleted status will become Archived. This will be accomplished by changing the display label, the underlying database value will remain "D". Functionally, Archived status is similar to Suspended status, but is intended to convey intent not reactivate.
3. Delete will continue to be a soft delete.
4. The term Expunge will be re-purposed to describe a hard delete. A CO Administrator may enable Expunge within their CO via CO Settings. Doing so will expose an Expunge operation where a Delete operation also exists. Expunge permissions will initially be the same as Delete permissions. Expunge will be available on any model that supports Delete, so (eg) an Email Address may be expunged without removing the rest of the Person record.
   1. Expunging a record with dependent records will also expunge those dependent records.
5. COs cannot be deleted, only expunged. Requesting the expungement of a CO will place the CO into Pending Removal status. While in this status, the CO may be reactivated. The physical removal of the CO will be processed by the GarbageCollectorJob. Other models may eventually support this mechanism, for example Groups with large numbers of members.
6. There will no longer be a special Person Expunge operation. The extra logic will be folded into the standard Person Delete callbacks. Both Delete and Expunge of a Person record will perform this extra logic, the former resulting in a series of soft deletes and the latter resulting in a series of hard deletes.
7. Dependency checking, preferably automatic so it need not be implemented per model, will prevent deletion of an object that is still referenced elsewhere.

Summary

See Also

• CFM-24 Changelog Behavior
• CFM-94 Garbage Collection
• CFM-124 Person Expunge
• CO-149 Delete should become expire/invalidate
• CO-1015 Refactor Suspend/Delete
• CO-1103 Evaluate Soft vs Hard Delete
• CO-1568 Job to "Prune" Deleted Records
• CO-1634 Reimplement Provisioner Delete Actions
• CO-2103 GDPR Data Erasure Plugin