Proposal: Record archiving / data retention (willing to implement)

[Makuro]

Hi,

on long-running instances the email, note and attachment tables keep growing, which slows down list views, streams and search and inflates backups. The existing “Archive” folder for emails only moves records, it doesn’t reduce data. The forum has many threads about this; the usual answers are manual SQL deletes or custom cleanup jobs.

I’d like to build a proper archiving feature and contribute it. Rough idea:

• Archive storage: a single generic table (e.g. ArchiveRecord) holding a JSON snapshot of the record including resolved relations, a denormalized text field with a FULLTEXT index, the parent (Account/Contact) and a snapshot of team/assigned-user access.
• Archiving job: a scheduled job with configurable rules per entity type (e.g. “Case closed > 2 years”, “Email older than X and not linked to an open record”). It snapshots, moves attachments (optionally to a separate storage), then hard-deletes the original together with related stream notes. It supports a dry-run mode.
• Read-only UI: ArchiveRecord as a regular entity with read-only ACL, a detail view that renders the snapshot, and an “Archive” panel on Account/Contact.
• Retention and GDPR: a retention period per type after which archived records are purged, and a way to remove all archived data related to a person.
• Restore: restoring a single record from its snapshot, if feasible.

Questions to the maintainers:

1. Would you consider this for core, or should it be an extension?
2. If extension: would you accept small core PRs that make it cleaner, e.g. a reliable way to collect all relations of a record before deletion?
3. Any architectural constraints or existing plans I should align with?

I’m happy to adapt to your conventions.

Thanks!