Admin & Security
Audit trails, the unified deletion pipeline, and GDPR data portability.
Administrative operations and user security lifecycles span multiple feature slices (primarily users and audit).
The Audit Trail
The features/audit slice owns the admin log viewer. However, the actual writer function (shared/audit/record.ts) is a cross-cutting port used by over 50 endpoints across the platform.
No-Throw Invariant
The Account Deletion Pipeline
Deleting a user is a highly destructive, multi-system action. The platform enforces that there is exactly one deletion path: accountDeletion.workflow.ts.
Whether a user deletes their own account, an admin deletes a single user, or an admin executes a bulk deletion, it all funnels through this one workflow. This guarantees that side-effects are never skipped:
- Cloudinary Assets: Resumes and avatars are aggressively purged from the CDN. Orphaned blobs are billable forever.
- Google Grants: The user's OAuth refresh token is explicitly revoked at Google. Before this unified pipeline, an admin deleting a user would delete the database row but leave a live token valid at Google indefinitely.
Activity & GDPR Portability
Derived Activity Timeline
The user's security activity timeline is completely derived. Rather than inserting into a redundant UserActivity table, the system merges four existing sources (AuditLog, LoginEvent, SubscriptionEvent, and LegalAcceptance) on the fly. This means features added today retroactively show history from yesterday.
The Export Manifest
The GDPR data export (server/dataExport.ts) intentionally mirrors the exact same models that the deletion workflow destroys.
Schema-Bound Testing
__tests__/dataExportManifest.test.ts) reads the raw schema.prisma text file and fails the CI build if a user-owned model is in neither the export manifest nor a deliberate exclusion list. This guarantees that a new feature added to the schema cannot quietly become a GDPR portability gap.