rstillwell/ubiquitous-invention
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions
ubiquitous-invention/plans/Plan-multitenant-saas-hardening/Epic-tenant-lifecycle/Task-account-merge.md
Randall Stillwell 820dae6510 docs(plans): split workspace-invites convoy into identity + invites + autocomplete 
User pushed back on "strict email match in v1" — the right architectural
answer is multi-email identity (one users row owning multiple verified
emails), not a stopgap. Scaling the convoy accordingly:

1. Task-multi-email-identity (NEW, P1, foundation)
   - user_email_identities table (user_id, email lowercased, verified_at,
     source: primary | oauth:<provider> | manual)
   - Refactor ensureUserIdByEmail -> ensureUserIdByVerifiedEmail against
     the new table.
   - OAuth callback writes a source='oauth:<provider>' identity when the
     provider returns email_verified=true. Cross-user conflict rejects.
   - Profile UI: "Linked emails" section, read-only in v1.
   - Exports userOwnsEmail(userId, emailLower) for invite accept to call.

2. Task-workspace-invites-and-roles (existing, narrowed)
   - All the original spec.
   - Accept procedure calls userOwnsEmail() instead of comparing
     users.email directly. Mismatch renders an explainer page, not a
     silent accept.

3. Task-invite-recipient-autocomplete (NEW, P1, polish)
   - invites.suggestRecipient returns typed suggestions across four
     kinds: member / pending_invite / known_user / new_email.
   - Tenancy fence on known_user is the security-relevant assertion;
     test for it explicitly.
   - Combobox UI renders each kind with its own affordance.

Three follow-ups filed explicitly to keep this convoy PR-sized:
- Task-manual-email-verification (add an email outside OAuth)
- Task-disconnect-linked-email (destructive, needs last-verified guard)
- Task-account-merge (handle the legacy duplicate-users case)

Epic file refreshed with the new task table, follow-up table, and a
phase ordering note. Identity lands first because it touches the
sign-in path; invites and autocomplete can ship in their own PRs.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 10:02:38 -05:00

2.5 KiB
Raw Blame History

kind slug title plan_slug epic_slug status priority tenant_id owner cursor_todo_id updated_at
task account-merge Merge two existing user accounts that turn out to share an email multitenant-saas-hardening tenant-lifecycle draft P2 global unassigned null 2026-06-02

Task summary

Handle the case where a user has, historically, created two separate users rows (one via GitHub OAuth, one via Credentials, etc.) and now wants them merged into a single identity. The current behavior in Task-multi-email-identity is to reject the OAuth sign-in when the email collides with another user — this task is the operator-facing fix.

Why deferred from the invites convoy

Account merge is security-sensitive and has cascading data implications:

  • Both users may have authored objects, posted comments, owned workspaces, accepted invites.
  • After merge, all FKs on the losing user's id need to point to the winning user's id, in one transaction.
  • Some FKs have unique constraints (e.g., workspace_members(workspace_id, user_id)) — merging two users who are both in the same workspace creates a conflict that has to be resolved by keeping the higher-role row.
  • Requires both accounts to prove ownership (re-sign-in to the losing account, then OAuth-verify the winning account's email).

This is its own multi-day effort. Out of scope for the invites convoy.

Scope (sketch — refine when scheduled)

  • Detection: when ensureUserIdByVerifiedEmail would reject an OAuth sign-in because the email is verified on another user, instead surface a "we found another account with this email — merge?" affordance.
  • Merge procedure: a transactional operator that rewires FKs from the losing user to the winning user, handles unique-constraint collisions per table, and writes a comprehensive audit-log entry.
  • UI: profile-side "Merge another account into this one" flow that requires authenticating to both.

Acceptance criteria (draft)

  • All FKs that referenced the losing user now reference the winning user; no orphans.
  • Workspace-membership conflicts resolved with the higher-role row kept.
  • Audit-log entry includes a snapshot of every rewired FK count.
  • Losing user row is hard-deleted only after a 30-day window during which the merge can be reverted (soft-delete first; reuses Task-workspace-soft-delete-and-audit semantics).

Links

  • Epic: ./Epic-tenant-lifecycle.md
  • Depends on: ./Task-multi-email-identity.md, ./Task-workspace-soft-delete-and-audit.md.