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.2 KiB
Markdown
46 lines
2.2 KiB
Markdown
---
|
|
kind: task
|
|
slug: manual-email-verification
|
|
title: Manual email verification — add an email outside an OAuth provider
|
|
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
|
|
|
|
Let a user add a new email to their profile (one they don't have an OAuth account for) by typing it, receiving a one-time verification code, and entering the code. Required so people can accept invites sent to emails they only use for forwarding / aliases / etc.
|
|
|
|
## Why deferred from the invites convoy
|
|
|
|
`Task-multi-email-identity` populates the identities table from OAuth provider claims only. That covers the common case (sign in via GitHub, GitHub knows your verified GitHub email). It does NOT cover: "I have a personal Gmail I never use to log in, and someone invited me at that address."
|
|
|
|
This is real product surface but requires:
|
|
|
|
- Verification token table (or reuse `verification_tokens` which NextAuth already provides).
|
|
- An outbound email send — needs a chosen provider (Resend / Postmark / SES). The invites convoy explicitly deferred email-send to a follow-up because picking a provider is its own discussion.
|
|
- Rate-limit on code requests (3/hour/email) — overlaps with `Task-rate-limit-and-abuse-guardrails`.
|
|
- A code-entry UI on the profile page.
|
|
|
|
## Scope (sketch — refine when scheduled)
|
|
|
|
- Profile UI: "Add email" button → input → "Send code" → 6-digit code entry.
|
|
- Backend: `identity.requestEmailVerification({ email })` (rate-limited), `identity.confirmEmailVerification({ email, code })`.
|
|
- On confirm, insert `user_email_identities` with `source='manual'`, `verified_at=now()`.
|
|
- Reject if the email is already a verified identity on another user (same rule as OAuth case).
|
|
|
|
## Acceptance criteria (draft)
|
|
|
|
- [ ] User can add a verified email to their profile without going through OAuth.
|
|
- [ ] Codes expire in 15 minutes; max 3 sends per email per hour.
|
|
- [ ] Confirmed emails appear in the "Linked emails" section with `source='manual'`.
|
|
|
|
## Links
|
|
|
|
- Epic: `./Epic-tenant-lifecycle.md`
|
|
- Depends on: `./Task-multi-email-identity.md`, transactional email provider decision.
|