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>
1.8 KiB
1.8 KiB
| kind | slug | title | plan_slug | epic_slug | status | priority | tenant_id | owner | cursor_todo_id | updated_at |
|---|---|---|---|---|---|---|---|---|---|---|
| task | disconnect-linked-email | Disconnect a linked email from a user's profile | multitenant-saas-hardening | tenant-lifecycle | draft | P2 | global | unassigned | null | 2026-06-02 |
Task summary
Let a user remove a linked email from their profile. Sounds simple; isn't. Removing the wrong row can either lock the user out (no verified email = can't be matched on next sign-in) or strand an invite that was bound to that email.
Why deferred from the invites convoy
Task-multi-email-identity ships the "Linked emails" list as read-only. Adding a remove action requires:
- Server-side guard: cannot remove the user's last verified identity. Cannot remove the
source='primary'identity unless another verified identity is promoted to primary in the same transaction. - UX for the "this email has 2 pending workspace invites — accept or revoke them first" case.
- Audit-log entry (overlaps with
Task-workspace-soft-delete-and-audit). - Confirmation modal with clear "this will affect: pending invites X, Y" copy.
Scope (sketch — refine when scheduled)
identity.disconnectEmail({ identityId })procedure with the guards above.- Profile UI: confirmation modal that lists pending-invite impact before the destructive action.
- If the disconnected identity was
source='primary', prompt to choose a new primary from the remaining verified set.
Acceptance criteria (draft)
- Cannot disconnect the only verified identity on an account.
- Disconnecting an email that has pending invites surfaces those invites in the confirmation flow.
- Audit-log row written for every disconnect.
Links
- Epic:
./Epic-tenant-lifecycle.md - Depends on:
./Task-multi-email-identity.md,./Task-workspace-soft-delete-and-audit.md(for audit log).