CS-656 Create script to Migrate all users from old domain to new domain - remove duplicate people records

[github-actions]

This is an automated pull request to merge chas/email-migration-script into dev.
It was created by the [Auto Pull Request] action.

---

Summary by cubic

Adds Trigger tasks merge-duplicate-user and migrate-org-email-domain to consolidate duplicate users after email or domain changes. Fulfills CS-656 by removing duplicate people records across an org during domain migrations.

• New Features
  • Atomic DB transaction with 30s timeout and org:{organizationId} tagging; improved logging.
  • Reassigns member references across policies (assignee/approver and signedBy), policy versions, tasks/task items, risks, vendors, findings, comments, audit logs, devices, background checks, trust access requests/grants, and offboarding records.
  • Deduplicates and migrates employee training video completions.
  • Moves OAuth accounts to the surviving user; deletes old sessions and user; deletes old member; updates invitations from oldEmail to newEmail.
  • migrate-org-email-domain scans active members, matches oldDomain→newDomain by local-part with case-insensitive comparison (lowercased emails/domains), triggers merge-duplicate-user per pair, and returns merged/failed counts and pair results; no-ops if normalized domains are identical.

^{Written for commit 4ae255c. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
comp-framework-editor	Building	Preview, Comment	Jun 30, 2026 6:51pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
app	Skipped		Jun 30, 2026 6:51pm
portal	Skipped		Jun 30, 2026 6:51pm

[cubic-dev-ai]

4 issues found across 1 file

Confidence score: 2/5

• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, there is no guard for oldEmail === newEmail, so a self-merge can delete the very user/member being kept; merging as-is risks destructive data loss on valid-looking input — add an explicit equality short-circuit before any delete/update steps.
• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, the training completion migration drops id and then later updates by id, which can make that migration fail or silently affect zero rows; this creates a concrete partial-migration/regression risk — keep id in the projection (or change downstream updates to available keys) and verify with a targeted migration test before merging.
• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, resolving members outside the transaction introduces a TOCTOU window where merge targets can change mid-operation, leading to inconsistent merges under concurrency — move member resolution inside the same transaction (or lock rows) before merge.
• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, the final merge log reports deleted IDs as survivors, which can mislead incident response and audits after a bad merge — correct survivor/deleted ID mapping in the log payload before shipping.

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[linear]

CS-656

[cubic-dev-ai]

2 issues found across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[chasprowebdev]

@cubic-dev-ai please review it

[cubic-dev-ai]

@cubic-dev-ai please review it

@chasprowebdev I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

3 issues found across 2 files

Confidence score: 2/5

• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, deleting oldUser before re-pointing user-level relations can cascade/null fields like AuditLog.userId, which risks losing historical attribution after a duplicate merge — migrate those relations to the surviving user first, then delete.
• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, SOA/ISMS approverId values are not migrated before old-member deletion, so pending/approved document approver assignments can be cleared as a side effect — add an explicit approver reassignment step before the delete.
• In apps/api/src/trigger/tasks/people/merge-duplicate-user.ts, OffboardingAccessRevocation.revokedById is matched using member IDs instead of user IDs, so the actor link can be silently missed and revocation history becomes inaccurate — switch the comparison/update logic to user IDs before merging.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/api/src/trigger/tasks/people/merge-duplicate-user.ts">

<violation number="1" location="apps/api/src/trigger/tasks/people/merge-duplicate-user.ts:235">
P2: Migrate SOA/ISMS document approverId before deleting the old member. Otherwise pending/approved document approver assignments are nulled during the merge.</violation>

<violation number="2" location="apps/api/src/trigger/tasks/people/merge-duplicate-user.ts:245">
P1: Re-point user-level relations before deleting oldUser. Deleting oldUser currently cascades or nulls historical records such as AuditLog.userId instead of preserving them on the surviving account.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[chasprowebdev]

@cubic-dev-ai please review this.

[cubic-dev-ai]

@cubic-dev-ai please review this.

@chasprowebdev I have started the AI code review. It will take a few minutes to complete.