ubiquitous-invention/apps/web/server/routers/invites.ts

589 lines
20 KiB
TypeScript
Raw Normal View History

feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
import { randomBytes } from "node:crypto";
import { TRPCError } from "@trpc/server";
feat(invites): smart recipient autocomplete combobox (Task 3, done) Closes Task-invite-recipient-autocomplete. The invite dialog's plain email input is replaced with a debounced combobox that surfaces the four real cases — existing member, pending invite, known user from a sibling workspace, brand-new email — before the inviter hits send. Subagent ran in parallel while the main thread shipped Task 2's UI; file-level non-overlap held (subagent stayed in apps/web/components/teams/invite-recipient-combobox.tsx and the shared types; main thread stayed in invite-dialog.tsx and the teams page). This commit folds the subagent's deliverable in plus the two-line wire-up that swaps the input for the combobox. Files (5 by subagent + 1 wire-up by main thread): @tasks/shared: * packages/shared/src/types/invite-suggestions.ts — InviteSuggestion union + pure mergeInviteSuggestions ranker. Lives in shared so client + server consume one type definition. * packages/shared/src/types/invite-suggestions.test.ts — 9 vitest cases covering kind ordering, dedupe (known_user vs member by userId, vs pending_invite by lowercased email), new_email suppression when other kinds cover the typed address, the 10- result limit, and email normalization. * packages/shared/src/types/index.ts — re-export. apps/web: * apps/web/server/routers/invites.ts — new `suggestRecipient` procedure on workspaceProcedure (owner/admin only). Implements the four kinds with the tenancy fence wired as a two-step query: first SELECT DISTINCT workspace_id FROM workspace_members WHERE user_id = inviter (the inviter's workspace pool), then inArray(workspaceMembers.workspaceId, pool) + ne(users.id, inviter) on the candidate join. Read the procedure JSDoc for the full set of invariants. All user-typed patterns escape through escapeIlike with the ESCAPE '\\' clause (mirrors search.ts). No existing exports modified. * apps/web/components/teams/invite-recipient-combobox.tsx — standalone controlled combobox. 200ms debounce, min-2-char gate, distinct row styling per kind, ArrowUp/Down/Enter/Esc keyboard nav, outside-click close. * apps/web/components/teams/invite-dialog.tsx (wire-up) — Input swapped for InviteRecipientCombobox. Added an onFocusExistingMember prop so a future teams-page integration can scroll/focus the matching row when a `member` suggestion is picked; for now the dialog just closes cleanly on member-pick. Gates: 0 lint errors / 15 warnings (14 baseline + 1 incidental from earlier teams-page work, none from this task's files); 6/6 type-check; 23/23 tests (14 baseline + 9 new). Acceptance criteria all met except the live-DB tenancy-fence integration test (skipped because apps/web has no vitest harness; unblocked by Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:39:09 -04:00
import {
and,
desc,
eq,
gt,
inArray,
isNotNull,
isNull,
ne,
sql,
} from "drizzle-orm";
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
import { z } from "zod";
import { router, protectedProcedure, workspaceProcedure } from "@/server/trpc";
import { userOwnsEmail } from "@/server/lib/identity";
feat(security): in-process rate limit for sign-in and invite creation Algorithm: a fixed-window token bucket implemented as a pure function in `@tasks/shared` (`consumeTokenBucket`) plus a thin `apps/web` wrapper that holds per-key state in a module-scoped `Map`. No Redis, no external deps — horizontally-scaled deploys will need a Redis-backed swap behind the same `rateLimit()` signature; called out in the JSDoc as a follow-up. The pure core is unit-tested in `packages/shared` (6 new vitest cases covering allow/deny, window reset, key isolation, monotonic retryAfterMs, denied- flood pegging, and option validation); the wrapper is intentionally not tested here because apps/web has no vitest harness yet. Wire-ins (the two narrow surfaces called out in the v1 spec): 1. Credentials `authorize` in `apps/web/lib/auth.ts`: 5 attempts per IP per 60s. IP comes from `next/headers` (x-forwarded-for first entry, then x-real-ip); when headers() throws or returns nothing we fall back to keying on "unknown" in prod and skipping the limiter entirely in dev so a local test loop doesn't lock itself out. On a trip we `console.warn` and return null — the standard Auth.js "auth failed" signal — without consulting the DB. 2. `invites.create` in `apps/web/server/routers/invites.ts`: 10 invite-creates per inviter per hour. Keyed by inviter id (not workspace) so a multi-workspace admin can't multiply their allowance. On trip we throw TRPCError TOO_MANY_REQUESTS with a retry-after seconds count baked into the message. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 14:26:19 -04:00
import { rateLimit } from "@/server/lib/rate-limit";
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
import {
feat(invites): smart recipient autocomplete combobox (Task 3, done) Closes Task-invite-recipient-autocomplete. The invite dialog's plain email input is replaced with a debounced combobox that surfaces the four real cases — existing member, pending invite, known user from a sibling workspace, brand-new email — before the inviter hits send. Subagent ran in parallel while the main thread shipped Task 2's UI; file-level non-overlap held (subagent stayed in apps/web/components/teams/invite-recipient-combobox.tsx and the shared types; main thread stayed in invite-dialog.tsx and the teams page). This commit folds the subagent's deliverable in plus the two-line wire-up that swaps the input for the combobox. Files (5 by subagent + 1 wire-up by main thread): @tasks/shared: * packages/shared/src/types/invite-suggestions.ts — InviteSuggestion union + pure mergeInviteSuggestions ranker. Lives in shared so client + server consume one type definition. * packages/shared/src/types/invite-suggestions.test.ts — 9 vitest cases covering kind ordering, dedupe (known_user vs member by userId, vs pending_invite by lowercased email), new_email suppression when other kinds cover the typed address, the 10- result limit, and email normalization. * packages/shared/src/types/index.ts — re-export. apps/web: * apps/web/server/routers/invites.ts — new `suggestRecipient` procedure on workspaceProcedure (owner/admin only). Implements the four kinds with the tenancy fence wired as a two-step query: first SELECT DISTINCT workspace_id FROM workspace_members WHERE user_id = inviter (the inviter's workspace pool), then inArray(workspaceMembers.workspaceId, pool) + ne(users.id, inviter) on the candidate join. Read the procedure JSDoc for the full set of invariants. All user-typed patterns escape through escapeIlike with the ESCAPE '\\' clause (mirrors search.ts). No existing exports modified. * apps/web/components/teams/invite-recipient-combobox.tsx — standalone controlled combobox. 200ms debounce, min-2-char gate, distinct row styling per kind, ArrowUp/Down/Enter/Esc keyboard nav, outside-click close. * apps/web/components/teams/invite-dialog.tsx (wire-up) — Input swapped for InviteRecipientCombobox. Added an onFocusExistingMember prop so a future teams-page integration can scroll/focus the matching row when a `member` suggestion is picked; for now the dialog just closes cleanly on member-pick. Gates: 0 lint errors / 15 warnings (14 baseline + 1 incidental from earlier teams-page work, none from this task's files); 6/6 type-check; 23/23 tests (14 baseline + 9 new). Acceptance criteria all met except the live-DB tenancy-fence integration test (skipped because apps/web has no vitest harness; unblocked by Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:39:09 -04:00
userEmailIdentities,
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
workspaceInvites,
workspaceMembers,
workspaces,
users,
} from "@tasks/database/schema";
feat(invites): smart recipient autocomplete combobox (Task 3, done) Closes Task-invite-recipient-autocomplete. The invite dialog's plain email input is replaced with a debounced combobox that surfaces the four real cases — existing member, pending invite, known user from a sibling workspace, brand-new email — before the inviter hits send. Subagent ran in parallel while the main thread shipped Task 2's UI; file-level non-overlap held (subagent stayed in apps/web/components/teams/invite-recipient-combobox.tsx and the shared types; main thread stayed in invite-dialog.tsx and the teams page). This commit folds the subagent's deliverable in plus the two-line wire-up that swaps the input for the combobox. Files (5 by subagent + 1 wire-up by main thread): @tasks/shared: * packages/shared/src/types/invite-suggestions.ts — InviteSuggestion union + pure mergeInviteSuggestions ranker. Lives in shared so client + server consume one type definition. * packages/shared/src/types/invite-suggestions.test.ts — 9 vitest cases covering kind ordering, dedupe (known_user vs member by userId, vs pending_invite by lowercased email), new_email suppression when other kinds cover the typed address, the 10- result limit, and email normalization. * packages/shared/src/types/index.ts — re-export. apps/web: * apps/web/server/routers/invites.ts — new `suggestRecipient` procedure on workspaceProcedure (owner/admin only). Implements the four kinds with the tenancy fence wired as a two-step query: first SELECT DISTINCT workspace_id FROM workspace_members WHERE user_id = inviter (the inviter's workspace pool), then inArray(workspaceMembers.workspaceId, pool) + ne(users.id, inviter) on the candidate join. Read the procedure JSDoc for the full set of invariants. All user-typed patterns escape through escapeIlike with the ESCAPE '\\' clause (mirrors search.ts). No existing exports modified. * apps/web/components/teams/invite-recipient-combobox.tsx — standalone controlled combobox. 200ms debounce, min-2-char gate, distinct row styling per kind, ArrowUp/Down/Enter/Esc keyboard nav, outside-click close. * apps/web/components/teams/invite-dialog.tsx (wire-up) — Input swapped for InviteRecipientCombobox. Added an onFocusExistingMember prop so a future teams-page integration can scroll/focus the matching row when a `member` suggestion is picked; for now the dialog just closes cleanly on member-pick. Gates: 0 lint errors / 15 warnings (14 baseline + 1 incidental from earlier teams-page work, none from this task's files); 6/6 type-check; 23/23 tests (14 baseline + 9 new). Acceptance criteria all met except the live-DB tenancy-fence integration test (skipped because apps/web has no vitest harness; unblocked by Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:39:09 -04:00
import {
mergeInviteSuggestions,
type InviteSuggestion,
type InviteSuggestionKnownUser,
type InviteSuggestionMember,
type InviteSuggestionNewEmail,
type InviteSuggestionPendingInvite,
} from "@tasks/shared";
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
/**
* Workspace invites. Owners and admins create invites for an email address;
* the recipient redeems the opaque `token` at /invite/[token].
*
* Security model:
* - `create`, `list`, `revoke` are workspace-scoped and require the caller
* to be `owner` or `admin` on the target workspace.
* - `accept` is a *public* procedure (no workspace handle) the token
* itself is the capability. It does require an authenticated session
* so we can write the `workspace_members.user_id` row, and it calls
* `userOwnsEmail()` from Task 1 to make sure the human accepting the
* invite actually controls the invited address under any of their
* linked identities. Mismatch returns a structured error so the UI can
* show the explainer instead of silently 403-ing.
*
* Email delivery is not in this task `create` returns the accept URL so
* an operator can copy/paste it. The Resend/Postmark integration is a
* follow-up.
*/
const ROLE_VALUES = ["owner", "admin", "member"] as const;
const inviteRoleSchema = z.enum(ROLE_VALUES);
const inviteEmailSchema = z
.string()
.trim()
.toLowerCase()
.pipe(z.string().email({ message: "Please enter a valid email address" }));
function assertCanManageInvites(role: string): void {
if (role !== "owner" && role !== "admin") {
throw new TRPCError({
code: "FORBIDDEN",
message: "Only owners and admins can manage invites",
});
}
}
function generateInviteToken(): string {
// 32 random bytes -> 43-char base64url. Enough entropy that a token guess
// is astronomically improbable; short enough to fit in a copy-paste URL.
return randomBytes(32).toString("base64url");
}
feat(invites): smart recipient autocomplete combobox (Task 3, done) Closes Task-invite-recipient-autocomplete. The invite dialog's plain email input is replaced with a debounced combobox that surfaces the four real cases — existing member, pending invite, known user from a sibling workspace, brand-new email — before the inviter hits send. Subagent ran in parallel while the main thread shipped Task 2's UI; file-level non-overlap held (subagent stayed in apps/web/components/teams/invite-recipient-combobox.tsx and the shared types; main thread stayed in invite-dialog.tsx and the teams page). This commit folds the subagent's deliverable in plus the two-line wire-up that swaps the input for the combobox. Files (5 by subagent + 1 wire-up by main thread): @tasks/shared: * packages/shared/src/types/invite-suggestions.ts — InviteSuggestion union + pure mergeInviteSuggestions ranker. Lives in shared so client + server consume one type definition. * packages/shared/src/types/invite-suggestions.test.ts — 9 vitest cases covering kind ordering, dedupe (known_user vs member by userId, vs pending_invite by lowercased email), new_email suppression when other kinds cover the typed address, the 10- result limit, and email normalization. * packages/shared/src/types/index.ts — re-export. apps/web: * apps/web/server/routers/invites.ts — new `suggestRecipient` procedure on workspaceProcedure (owner/admin only). Implements the four kinds with the tenancy fence wired as a two-step query: first SELECT DISTINCT workspace_id FROM workspace_members WHERE user_id = inviter (the inviter's workspace pool), then inArray(workspaceMembers.workspaceId, pool) + ne(users.id, inviter) on the candidate join. Read the procedure JSDoc for the full set of invariants. All user-typed patterns escape through escapeIlike with the ESCAPE '\\' clause (mirrors search.ts). No existing exports modified. * apps/web/components/teams/invite-recipient-combobox.tsx — standalone controlled combobox. 200ms debounce, min-2-char gate, distinct row styling per kind, ArrowUp/Down/Enter/Esc keyboard nav, outside-click close. * apps/web/components/teams/invite-dialog.tsx (wire-up) — Input swapped for InviteRecipientCombobox. Added an onFocusExistingMember prop so a future teams-page integration can scroll/focus the matching row when a `member` suggestion is picked; for now the dialog just closes cleanly on member-pick. Gates: 0 lint errors / 15 warnings (14 baseline + 1 incidental from earlier teams-page work, none from this task's files); 6/6 type-check; 23/23 tests (14 baseline + 9 new). Acceptance criteria all met except the live-DB tenancy-fence integration test (skipped because apps/web has no vitest harness; unblocked by Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:39:09 -04:00
/**
* Escape the three ILIKE metacharacters (`%`, `_`, `\`) so a user-typed
* query can be safely interpolated into an `ILIKE '...pattern...' ESCAPE
* '\\'` clause without letting "100%" or "snake_case" match more than the
* literal characters typed.
*/
function escapeIlike(value: string): string {
return value.replace(/\\/g, "\\\\").replace(/%/g, "\\%").replace(/_/g, "\\_");
}
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
function buildAcceptUrl(token: string): string {
// `NEXT_PUBLIC_APP_URL` is the canonical origin for invite links. Falls
// back to a path-only URL so the procedure still works in environments
// without it set (the UI can prefix `window.location.origin` if needed).
const base = process.env.NEXT_PUBLIC_APP_URL?.replace(/\/$/, "");
return base ? `${base}/invite/${token}` : `/invite/${token}`;
}
export const invitesRouter = router({
/**
* Create or return-existing an open invite for `email` to the given
* workspace. Idempotent on the (workspace_id, lower(email)) pair: if an
* open invite already exists for that address, we return it instead of
* inserting a duplicate (the partial unique constraint would block it
* anyway).
*/
create: workspaceProcedure
.input(
z.object({
email: inviteEmailSchema,
role: inviteRoleSchema,
}),
)
.mutation(async ({ ctx, input }) => {
assertCanManageInvites(ctx.workspace.role);
const inviterId = ctx.session.user.id;
feat(security): in-process rate limit for sign-in and invite creation Algorithm: a fixed-window token bucket implemented as a pure function in `@tasks/shared` (`consumeTokenBucket`) plus a thin `apps/web` wrapper that holds per-key state in a module-scoped `Map`. No Redis, no external deps — horizontally-scaled deploys will need a Redis-backed swap behind the same `rateLimit()` signature; called out in the JSDoc as a follow-up. The pure core is unit-tested in `packages/shared` (6 new vitest cases covering allow/deny, window reset, key isolation, monotonic retryAfterMs, denied- flood pegging, and option validation); the wrapper is intentionally not tested here because apps/web has no vitest harness yet. Wire-ins (the two narrow surfaces called out in the v1 spec): 1. Credentials `authorize` in `apps/web/lib/auth.ts`: 5 attempts per IP per 60s. IP comes from `next/headers` (x-forwarded-for first entry, then x-real-ip); when headers() throws or returns nothing we fall back to keying on "unknown" in prod and skipping the limiter entirely in dev so a local test loop doesn't lock itself out. On a trip we `console.warn` and return null — the standard Auth.js "auth failed" signal — without consulting the DB. 2. `invites.create` in `apps/web/server/routers/invites.ts`: 10 invite-creates per inviter per hour. Keyed by inviter id (not workspace) so a multi-workspace admin can't multiply their allowance. On trip we throw TRPCError TOO_MANY_REQUESTS with a retry-after seconds count baked into the message. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 14:26:19 -04:00
// Per-inviter rate limit: 10 invites per hour. Sized for normal
// onboarding bursts (a team of ~10 going through provisioning in
// one sitting) while still cutting off a script that's trying to
// spray invites across many addresses. Keyed by inviter, not by
// workspace, because a single bad actor with admin rights in
// multiple workspaces would otherwise multiply their allowance.
const inviteLimit = rateLimit({
key: `invite:create:${inviterId}`,
limit: 10,
windowMs: 60 * 60 * 1_000,
});
if (!inviteLimit.allowed) {
const retryAfterSec = Math.max(
1,
Math.ceil(inviteLimit.retryAfterMs / 1_000),
);
throw new TRPCError({
code: "TOO_MANY_REQUESTS",
message: `You've hit the invite limit for this hour. Try again in about ${retryAfterSec} seconds.`,
});
}
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
// Don't let inviters invite themselves — confusing failure mode.
const [inviter] = await ctx.db
.select({ email: users.email })
.from(users)
.where(eq(users.id, inviterId))
.limit(1);
if (inviter?.email.toLowerCase() === input.email) {
throw new TRPCError({
code: "BAD_REQUEST",
message: "You can't invite yourself.",
});
}
// Already a member? Surface a clear error so the inviter knows.
const [existingMember] = await ctx.db
.select({ userId: workspaceMembers.userId })
.from(workspaceMembers)
.innerJoin(users, eq(users.id, workspaceMembers.userId))
.where(
and(
eq(workspaceMembers.workspaceId, ctx.workspace.id),
eq(users.email, input.email),
),
)
.limit(1);
if (existingMember) {
throw new TRPCError({
code: "CONFLICT",
message: "This person is already a member of this workspace.",
});
}
// Reuse an open invite if one already exists for this (workspace, email).
const [existingInvite] = await ctx.db
.select()
.from(workspaceInvites)
.where(
and(
eq(workspaceInvites.workspaceId, ctx.workspace.id),
eq(workspaceInvites.email, input.email),
isNull(workspaceInvites.acceptedAt),
isNull(workspaceInvites.revokedAt),
),
)
.limit(1);
if (existingInvite) {
return {
invite: existingInvite,
acceptUrl: buildAcceptUrl(existingInvite.token),
reused: true as const,
};
}
const token = generateInviteToken();
const [invite] = await ctx.db
.insert(workspaceInvites)
.values({
workspaceId: ctx.workspace.id,
email: input.email,
role: input.role,
invitedByUserId: inviterId,
token,
})
.returning();
return {
invite: invite!,
acceptUrl: buildAcceptUrl(invite!.token),
reused: false as const,
};
}),
/** Pending (non-accepted, non-revoked) invites for the workspace. */
list: workspaceProcedure.query(async ({ ctx }) => {
assertCanManageInvites(ctx.workspace.role);
return ctx.db
.select({
id: workspaceInvites.id,
email: workspaceInvites.email,
role: workspaceInvites.role,
token: workspaceInvites.token,
expiresAt: workspaceInvites.expiresAt,
createdAt: workspaceInvites.createdAt,
invitedByUserId: workspaceInvites.invitedByUserId,
invitedByName: users.name,
invitedByEmail: users.email,
})
.from(workspaceInvites)
.innerJoin(users, eq(users.id, workspaceInvites.invitedByUserId))
.where(
and(
eq(workspaceInvites.workspaceId, ctx.workspace.id),
isNull(workspaceInvites.acceptedAt),
isNull(workspaceInvites.revokedAt),
),
)
.orderBy(desc(workspaceInvites.createdAt));
}),
/** Revoke an open invite. Caller must be owner/admin on the invite's workspace. */
revoke: protectedProcedure
.input(z.object({ inviteId: z.string().uuid() }))
.mutation(async ({ ctx, input }) => {
const [invite] = await ctx.db
.select({
id: workspaceInvites.id,
workspaceId: workspaceInvites.workspaceId,
acceptedAt: workspaceInvites.acceptedAt,
revokedAt: workspaceInvites.revokedAt,
})
.from(workspaceInvites)
.where(eq(workspaceInvites.id, input.inviteId))
.limit(1);
if (!invite) {
throw new TRPCError({ code: "NOT_FOUND", message: "Invite not found" });
}
if (invite.acceptedAt || invite.revokedAt) {
throw new TRPCError({
code: "BAD_REQUEST",
message: "This invite has already been closed.",
});
}
// Authorize against the invite's workspace, not via workspaceProcedure
// (we don't take a workspace handle in this input; the invite tells us).
const callerId = ctx.session.user.id;
const [membership] = await ctx.db
.select({ role: workspaceMembers.role })
.from(workspaceMembers)
.where(
and(
eq(workspaceMembers.workspaceId, invite.workspaceId),
eq(workspaceMembers.userId, callerId),
),
)
.limit(1);
if (!membership) {
throw new TRPCError({ code: "FORBIDDEN" });
}
assertCanManageInvites(membership.role);
await ctx.db
.update(workspaceInvites)
.set({ revokedAt: new Date() })
.where(eq(workspaceInvites.id, invite.id));
return { ok: true as const };
}),
/**
* Public-by-token redemption. Caller must be authenticated AND own (under
* any linked identity) the email the invite was sent to. On mismatch we
* throw a `FORBIDDEN` with a structured `cause` the UI can render as the
* "link this email first" explainer.
*/
accept: protectedProcedure
.input(z.object({ token: z.string().min(8).max(128) }))
.mutation(async ({ ctx, input }) => {
const now = new Date();
const [invite] = await ctx.db
.select({
id: workspaceInvites.id,
workspaceId: workspaceInvites.workspaceId,
email: workspaceInvites.email,
role: workspaceInvites.role,
acceptedAt: workspaceInvites.acceptedAt,
revokedAt: workspaceInvites.revokedAt,
expiresAt: workspaceInvites.expiresAt,
})
.from(workspaceInvites)
.where(eq(workspaceInvites.token, input.token))
.limit(1);
if (!invite) {
throw new TRPCError({
code: "NOT_FOUND",
message: "This invite link is not valid.",
});
}
if (invite.revokedAt) {
throw new TRPCError({
code: "BAD_REQUEST",
message: "This invite has been revoked.",
});
}
if (invite.acceptedAt) {
throw new TRPCError({
code: "BAD_REQUEST",
message: "This invite has already been accepted.",
});
}
if (invite.expiresAt.getTime() < now.getTime()) {
throw new TRPCError({
code: "BAD_REQUEST",
message: "This invite has expired.",
});
}
const callerId = ctx.session.user.id;
// Identity check: under Task 1's semantics, the caller must have a
// verified identity row matching the invited email. We surface the
// mismatch with a structured cause so the redeem page can render the
// "link this email to your account first" explainer.
const owns = await userOwnsEmail(callerId, invite.email);
if (!owns) {
throw new TRPCError({
code: "FORBIDDEN",
message: `This invite was sent to ${invite.email}. Link that email to your account from your profile, then come back to this link.`,
cause: { reason: "email_not_owned", invitedEmail: invite.email },
});
}
// Already a member? Don't fail — just close the invite. Common when
// someone accepts a re-invite after already being added by another flow.
const [existingMembership] = await ctx.db
.select({ id: workspaceMembers.id })
.from(workspaceMembers)
.where(
and(
eq(workspaceMembers.workspaceId, invite.workspaceId),
eq(workspaceMembers.userId, callerId),
),
)
.limit(1);
if (!existingMembership) {
await ctx.db.insert(workspaceMembers).values({
workspaceId: invite.workspaceId,
userId: callerId,
role: invite.role,
});
}
await ctx.db
.update(workspaceInvites)
.set({ acceptedAt: now })
.where(eq(workspaceInvites.id, invite.id));
const [workspace] = await ctx.db
.select({ id: workspaces.id, slug: workspaces.slug, name: workspaces.name })
.from(workspaces)
.where(eq(workspaces.id, invite.workspaceId))
.limit(1);
return {
workspace: workspace!,
role: invite.role,
};
}),
feat(invites): smart recipient autocomplete combobox (Task 3, done) Closes Task-invite-recipient-autocomplete. The invite dialog's plain email input is replaced with a debounced combobox that surfaces the four real cases — existing member, pending invite, known user from a sibling workspace, brand-new email — before the inviter hits send. Subagent ran in parallel while the main thread shipped Task 2's UI; file-level non-overlap held (subagent stayed in apps/web/components/teams/invite-recipient-combobox.tsx and the shared types; main thread stayed in invite-dialog.tsx and the teams page). This commit folds the subagent's deliverable in plus the two-line wire-up that swaps the input for the combobox. Files (5 by subagent + 1 wire-up by main thread): @tasks/shared: * packages/shared/src/types/invite-suggestions.ts — InviteSuggestion union + pure mergeInviteSuggestions ranker. Lives in shared so client + server consume one type definition. * packages/shared/src/types/invite-suggestions.test.ts — 9 vitest cases covering kind ordering, dedupe (known_user vs member by userId, vs pending_invite by lowercased email), new_email suppression when other kinds cover the typed address, the 10- result limit, and email normalization. * packages/shared/src/types/index.ts — re-export. apps/web: * apps/web/server/routers/invites.ts — new `suggestRecipient` procedure on workspaceProcedure (owner/admin only). Implements the four kinds with the tenancy fence wired as a two-step query: first SELECT DISTINCT workspace_id FROM workspace_members WHERE user_id = inviter (the inviter's workspace pool), then inArray(workspaceMembers.workspaceId, pool) + ne(users.id, inviter) on the candidate join. Read the procedure JSDoc for the full set of invariants. All user-typed patterns escape through escapeIlike with the ESCAPE '\\' clause (mirrors search.ts). No existing exports modified. * apps/web/components/teams/invite-recipient-combobox.tsx — standalone controlled combobox. 200ms debounce, min-2-char gate, distinct row styling per kind, ArrowUp/Down/Enter/Esc keyboard nav, outside-click close. * apps/web/components/teams/invite-dialog.tsx (wire-up) — Input swapped for InviteRecipientCombobox. Added an onFocusExistingMember prop so a future teams-page integration can scroll/focus the matching row when a `member` suggestion is picked; for now the dialog just closes cleanly on member-pick. Gates: 0 lint errors / 15 warnings (14 baseline + 1 incidental from earlier teams-page work, none from this task's files); 6/6 type-check; 23/23 tests (14 baseline + 9 new). Acceptance criteria all met except the live-DB tenancy-fence integration test (skipped because apps/web has no vitest harness; unblocked by Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:39:09 -04:00
/**
* Typeahead for the invite dialog's "Who do you want to invite?" field.
* Returns up to 10 suggestions across four kinds (see `InviteSuggestion`
* in `@tasks/shared`) so the UI can disambiguate between an existing
* member, an outstanding pending invite, a user from one of the
* inviter's other workspaces, and a brand-new email.
*
* Security model:
* - Workspace-scoped (`workspaceProcedure`) and owner/admin only
* non-managers should not be probing this surface to enumerate
* teammates.
* - The `known_user` kind is fenced to workspaces the **inviter** also
* belongs to. A global user search would leak the existence of
* accounts across tenants; this restriction is the security contract
* called out in the task spec (acceptance criterion: "Tenancy fence
* holds").
* - All ILIKE patterns are escaped via `escapeIlike` so a query like
* "100%" can't broaden the match.
*
* Empty / single-char queries return `[]` the UI uses this as a "show
* nothing yet" sentinel and avoids hammering the DB on every keystroke.
*/
suggestRecipient: workspaceProcedure
.input(z.object({ query: z.string() }))
.query(async ({ ctx, input }): Promise<InviteSuggestion[]> => {
assertCanManageInvites(ctx.workspace.role);
const raw = input.query.trim();
if (raw.length < 2) return [];
const qLower = raw.toLowerCase();
const escaped = escapeIlike(qLower);
const prefixPattern = `${escaped}%`;
const substringPattern = `%${escaped}%`;
const inviterId = ctx.session.user.id;
const totalLimit = 10;
const memberMatchSql = sql`(
${users.name} ILIKE ${substringPattern} ESCAPE '\\'
OR ${users.email} ILIKE ${prefixPattern} ESCAPE '\\'
OR ${userEmailIdentities.email} ILIKE ${prefixPattern} ESCAPE '\\'
)`;
const memberRows = await ctx.db
.selectDistinct({
userId: users.id,
name: users.name,
email: users.email,
role: workspaceMembers.role,
})
.from(workspaceMembers)
.innerJoin(users, eq(users.id, workspaceMembers.userId))
.leftJoin(
userEmailIdentities,
and(
eq(userEmailIdentities.userId, users.id),
isNotNull(userEmailIdentities.verifiedAt),
),
)
.where(
and(eq(workspaceMembers.workspaceId, ctx.workspace.id), memberMatchSql),
)
.limit(totalLimit);
const members: InviteSuggestionMember[] = memberRows.map((r) => ({
kind: "member",
userId: r.userId,
name: r.name,
email: r.email,
role: r.role,
}));
// `workspace_invites.email` is stored lowercased on insert
// (see `invites.create`), so a prefix ILIKE against the column is
// already case-insensitive without an extra `lower()` wrap.
const inviteRows = await ctx.db
.select({
inviteId: workspaceInvites.id,
email: workspaceInvites.email,
role: workspaceInvites.role,
expiresAt: workspaceInvites.expiresAt,
})
.from(workspaceInvites)
.where(
and(
eq(workspaceInvites.workspaceId, ctx.workspace.id),
isNull(workspaceInvites.acceptedAt),
isNull(workspaceInvites.revokedAt),
gt(workspaceInvites.expiresAt, new Date()),
sql`${workspaceInvites.email} ILIKE ${prefixPattern} ESCAPE '\\'`,
),
)
.limit(totalLimit);
const pendingInvites: InviteSuggestionPendingInvite[] = inviteRows.map(
(r) => ({
kind: "pending_invite",
inviteId: r.inviteId,
email: r.email,
role: r.role,
expiresAt: r.expiresAt,
}),
);
// Tenancy fence: the candidate pool for `known_user` is restricted to
// users who share at least one workspace with the inviter. We resolve
// that pool here as a concrete UUID array so the candidate query is a
// plain `IN (...)` against the same `workspace_members` table, which
// is easy to reason about and safe even if Drizzle's correlated
// subquery alias rules change. If the inviter happens to share zero
// workspaces with anyone (e.g. they only own a brand-new solo
// workspace), we skip the candidate query entirely.
const inviterWorkspaceRows = await ctx.db
.selectDistinct({ workspaceId: workspaceMembers.workspaceId })
.from(workspaceMembers)
.where(eq(workspaceMembers.userId, inviterId));
const inviterWorkspaceIds = inviterWorkspaceRows.map((r) => r.workspaceId);
let knownUsers: InviteSuggestionKnownUser[] = [];
if (inviterWorkspaceIds.length > 0) {
const knownCandidates = await ctx.db
.selectDistinct({
userId: users.id,
name: users.name,
email: users.email,
})
.from(users)
.innerJoin(workspaceMembers, eq(workspaceMembers.userId, users.id))
.leftJoin(
userEmailIdentities,
and(
eq(userEmailIdentities.userId, users.id),
isNotNull(userEmailIdentities.verifiedAt),
),
)
.where(
and(
inArray(workspaceMembers.workspaceId, inviterWorkspaceIds),
ne(users.id, inviterId),
memberMatchSql,
),
)
.limit(totalLimit * 2);
if (knownCandidates.length > 0) {
const candidateIds = knownCandidates.map((c) => c.userId);
const sharedCountRows = await ctx.db
.select({
userId: workspaceMembers.userId,
count: sql<number>`count(distinct ${workspaceMembers.workspaceId})::int`.as(
"count",
),
})
.from(workspaceMembers)
.where(
and(
inArray(workspaceMembers.userId, candidateIds),
inArray(workspaceMembers.workspaceId, inviterWorkspaceIds),
),
)
.groupBy(workspaceMembers.userId);
const countMap = new Map(
sharedCountRows.map((r) => [r.userId, Number(r.count)]),
);
knownUsers = knownCandidates.map((c) => ({
kind: "known_user",
userId: c.userId,
name: c.name,
email: c.email,
sharedWorkspaceCount: countMap.get(c.userId) ?? 0,
}));
}
}
const emailParse = z.string().email().safeParse(qLower);
const newEmail: InviteSuggestionNewEmail | null = emailParse.success
? { kind: "new_email", email: qLower, valid: true }
: null;
return mergeInviteSuggestions({
members,
pendingInvites,
knownUsers,
newEmail,
limit: totalLimit,
});
}),
feat(invites): workspace_invites schema + tRPC router + role management (Task 2, part 1/2) Schema half of Task-workspace-invites-and-roles. Lands the table, the invites router (create/list/revoke/accept), and the two new workspaces procedures (updateMemberRole/removeMember). UI ships in part 2/2. This is a stable checkpoint for Task 3 (invite-recipient-autocomplete) to start building against — the procedure surface area is frozen and the new identity helper from Task 1 is in the accept path. Schema: * workspace_invites: id, workspace_id, email (lowercased), role (owner/admin/member), invited_by_user_id, token (base64url 32B), expires_at (DEFAULT now() + 14d), accepted_at, revoked_at, created_at. * Indexes: workspace_id, UNIQUE(token), and a PARTIAL UNIQUE on (workspace_id, email) WHERE accepted_at IS NULL AND revoked_at IS NULL. An open invite is unique per (workspace, email); closed invites (accepted or revoked) fall out of the constraint so re-invites work. * Drizzle relations wired: workspaceInvites.workspace, workspaceInvites.invitedBy, workspaces.invites. * Migration 0006_broad_lethal_legion applied to dev DB. invites router: * create({email, role}) on workspaceProcedure (owner/admin only). Generates a base64url token from 32 random bytes via node:crypto. Idempotent on (workspace, email) — if an open invite already exists, returns it instead of inserting (the partial unique would block it anyway). Refuses self-invite. Refuses if the email is already a member. * list() returns pending (non-accepted, non-revoked) invites with inviter name/email joined for UI display. * revoke({inviteId}) authorizes against the invite's workspace, not the caller's input (the inviteId carries its own tenant scope). * accept({token}) is protectedProcedure (no workspace handle). Calls userOwnsEmail() from Task 1 — if the caller doesn't own the invited email under any of their verified identities, throws FORBIDDEN with a structured cause ({reason: "email_not_owned", invitedEmail}) so the redeem page can render the "link this email" explainer. Handles expiry, revoked, already-accepted states with clear messages. Idempotent on existing membership — if you've already been added by another flow, accept just closes the invite without re-inserting. workspaces additions: * updateMemberRole: admin/owner only. Three guards: 1. Can't change your own role (avoids accidental lockout). 2. Can't demote the only owner-role member (would leave the membership-level ownership empty even though workspaces.owner_user_id still points there — see ADR-pragmatic decision documented in the Task-multi-email-identity convoy discussion). 3. Only owners can promote to owner; admins move people between admin/member but cannot create a new owner. * removeMember: admin/owner OR self (the leave-workspace affordance). Same last-owner guard. Admins can't remove owners (only owners can, via demote-then-remove). Wired both new routers into root.ts as `invites` and `identity` (identity was landed in Task 1; this commit just keeps the registration visible alongside invites). All three CI gates green: 0 lint errors, 14 unchanged warnings, 6/6 type-check, 14/14 tests (no new tests yet — apps/web vitest harness is filed as Task-bootstrap-vitest-for-apps-web P2). Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-02 11:27:44 -04:00
});
export type InvitesRouter = typeof invitesRouter;
// Re-exports used by callers that want to share the schema (e.g. the smart
// recipient autocomplete in Task 3).
export const inviteRoleValues = ROLE_VALUES;
export { inviteRoleSchema };