Snapshots and retention

Every destructive policy captures the original value into xf_mc_sun_snapshot before mutating the live row. Reactivation reads from the snapshot to restore. The retention enforcer cron deletes snapshots once their per-category window expires.

Snapshot categories

Snapshots are tagged with one of three categories. Each category has its own retention window.

Category	What it covers	Retention option	Default
pii	Released usernames.	PII snapshot retention	365 days
profile	Native profile fields: about, signature, location, website, custom_title.	Profile snapshot retention	730 days
custom	Textbox and textarea custom user fields (anything under AdminCP > Users > Custom user fields).	Profile snapshot retention	730 days

A snapshot row carries original_value, created_date, and hard_delete_after. The retention enforcer cron deletes any snapshot whose hard_delete_after is in the past. Each deletion writes one retention_purge audit row so the GDPR receipt survives the snapshot itself.

How long a member can be reactivated

A member's reactivation surface area shrinks tier by tier:

• A Warned member has nothing to restore (the Warned tier writes no snapshots by default).
• A Soft sunset or Hard sunset member can be fully restored (profile fields plus username, if any) until the snapshot windows expire.
• A Released member can be partially restored until the PII window expires: their profile fields come back, but the released username is gone forever and the member picks a new one.
• After PII retention has elapsed for a Released member, only the public action record remains in the audit log. No restoration is possible.

Audit log retention

The audit log itself has its own window. Audit log retention (default 2555 days, ≈ 7 years) controls how far back the action records are kept. The retention enforcer prunes audit rows older than this window in 1000-row chunks per pass.

Right-to-erasure

When a member is hard-deleted from XenForo (the user delete flow):

1. Sunset's audit rows referencing that member are scrubbed in place: user_id, actor_user_id, and detail are nulled, erasure_scrubbed is set. The row stays as a compliance record but carries no PII.
2. The member's xf_mc_sun_user_state, xf_mc_sun_snapshot, and xf_mc_sun_reactivation_request rows are deleted.
3. The xf_mc_sun_released_username row is deliberately retained. It survives the user delete so the re-registration lockout continues to apply during its window.

The user export at AdminCP > Users > (edit) > Tools > Export user data includes a mc_sunset node with the member's tier history, audit entries (subject of), and snapshot field keys (no original values are exported; the snapshot table is admin-only).