820dae6510
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>
46 lines
2.5 KiB
Markdown
46 lines
2.5 KiB
Markdown
---
|
|
kind: task
|
|
slug: account-merge
|
|
title: Merge two existing user accounts that turn out to share an email
|
|
plan_slug: multitenant-saas-hardening
|
|
epic_slug: tenant-lifecycle
|
|
status: draft
|
|
priority: P2
|
|
tenant_id: global
|
|
owner: unassigned
|
|
cursor_todo_id: null
|
|
updated_at: "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`.
|