RBAC: PAT creation flow with role selection (TRI-8749)

Lets users pick a system role at PAT-create time and persists it via
enterprise.TokenRole so PAT-authenticated requests will run with that
role's permissions once the auth-side wiring lands.

V1 scope decisions (worth flagging for review):

1. System roles only. PATs are user-scoped (not org-scoped) and
   custom roles are per-org — the role-to-org mapping for a multi-org
   user's PAT is a non-trivial design question that doesn't need to
   be answered for v1. Show the four seeded system roles
   (Owner/Admin/Member/Viewer); a follow-up can add custom roles
   once we've decided what "this PAT uses an org X custom role"
   means semantically.

2. Default to caller's own role. Loader queries rbac.getUserRole
   against the user's first org membership (createdAt ASC) and uses
   that as the dropdown default — a PAT can't be more privileged
   than the person creating it without an explicit upgrade. Falls
   back to Member for users with no role assignment yet (OSS or new
   user pre-backfill).

3. No plan gating. Plan tiers are per-org; PAT roles are global.
   Plan gating only made sense in the org-scoped Teams page UI
   (TRI-8748).

4. No privilege-escalation check. Today's PATs run through the
   legacy auth path with full superScopes — even a "Owner" PAT here
   is strictly less permissive than the status quo. Locking down
   "the PAT can't exceed the creator's role" is a hardening for a
   later ticket once the read-side actually keys off TokenRole.

Changes:

- services/personalAccessToken.server.ts: createPersonalAccessToken
  takes an optional roleId. When provided, calls rbac.setTokenRole
  after the Prisma PAT row is created. On a real failure the PAT is
  compensating-deleted (the two writes live on different ORMs sharing
  one connection — co-transactions are awkward, compensating delete
  is simpler). The OSS fallback's "RBAC plugin not installed" return
  is treated as success-with-no-role: the PAT row stays, just no
  TokenRole gets written, matching pre-RBAC behaviour.
- routes/account.tokens/route.tsx: loader fetches system roles +
  caller's current role; create form shows a role <Select> with the
  caller's role as default; OSS path (allRoles returns []) hides the
  dropdown entirely. Action passes roleId through to the service.

Out of scope here (covered elsewhere):

- The PAT auth-side path that will JOIN TokenRole and build an ability
  from the role's permissions. Lives in the enterprise plugin's
  authenticatePat path; tracked under the TRI-8741 test surface and
  the broader auth-consolidation work in TRI-8744.
- CLI auth-code PAT (createPersonalAccessTokenFromAuthorizationCode)
  unchanged. CLI PATs continue to be created without an explicit
  role — they go through the legacy permissive path and existing
  user expectations of "trigger dev just works" are preserved.

Verification: typecheck clean on webapp. Browser smoke test deferred
to your local run.

Author: matt-aitken

.server-changes/rbac-pat-role-selection.md

@@ -0,0 +1,16 @@
+---
+area: webapp
+type: feature
+---
+
+RBAC: PAT creation flow now lets users pick a system role at create
+time, persisted as an enterprise.TokenRole row (TRI-8749). Defaults to
+the caller's own role so a PAT can't be more privileged than the
+person creating it. Custom (org-defined) roles are out of scope for
+v1 — only the four global system roles are offered, and the binding
+is global to the PAT regardless of which org the request later
+targets. Compensating-delete pattern on TokenRole insert failure
+keeps the two writes (Prisma PAT row + Drizzle TokenRole row)
+consistent without cross-ORM transaction wrestling. OSS path is a
+no-op: when the RBAC plugin isn't installed the dropdown is hidden,
+no roleId is submitted, and the PAT works exactly as before.

apps/webapp/app/routes/account.tokens/route.tsx

@@ -5,6 +5,7 @@ import { ShieldExclamationIcon } from "@heroicons/react/24/solid";
 import { DialogClose } from "@radix-ui/react-dialog";
 import { Form, type MetaFunction, useActionData, useFetcher } from "@remix-run/react";
 import { type ActionFunction, type LoaderFunctionArgs, json } from "@remix-run/server-runtime";
+import { useState } from "react";
 import { typedjson, useTypedLoaderData } from "remix-typedjson";
 import { z } from "zod";
 import { PageBody, PageContainer } from "~/components/layout/AppLayout";
@@ -22,6 +23,7 @@ import { InputGroup } from "~/components/primitives/InputGroup";
 import { Label } from "~/components/primitives/Label";
 import { NavBar, PageAccessories, PageTitle } from "~/components/primitives/PageHeader";
 import { Paragraph } from "~/components/primitives/Paragraph";
+import { Select, SelectItem } from "~/components/primitives/Select";
 import {
   Table,
   TableBlankRow,
@@ -34,6 +36,8 @@ import {
 } from "~/components/primitives/Table";
 import { SimpleTooltip } from "~/components/primitives/Tooltip";
 import { redirectWithSuccessMessage } from "~/models/message.server";
+import { prisma } from "~/db.server";
+import { rbac, SYSTEM_ROLE_IDS } from "~/services/rbac.server";
 import {
   type CreatedPersonalAccessToken,
   type ObfuscatedPersonalAccessToken,
@@ -52,14 +56,52 @@ export const meta: MetaFunction = () => {
   ];
 };
 
+// PATs aren't org-scoped, but role/permission catalogues are seeded
+// per-org in enterprise's allRoles. To get the canonical system roles
+// (Owner/Admin/Member/Viewer — orgId IS NULL on those rows), we hand
+// allRoles any orgId the user belongs to and filter down to system
+// roles. This is a UI-only convenience — the chosen role becomes a
+// global TokenRole row that applies wherever the PAT is used. Custom
+// (org-defined) roles are out of scope for v1: their org-binding
+// semantics for a multi-org user's PAT need a separate design pass.
+async function loadSystemRolesForUser(userId: string) {
+  const orgMember = await prisma.orgMember.findFirst({
+    where: { userId },
+    select: { organizationId: true },
+    orderBy: { createdAt: "asc" },
+  });
+  if (!orgMember) return { roles: [], userRoleId: null as string | null };
+
+  const allRoles = await rbac.allRoles(orgMember.organizationId);
+  const systemRoles = allRoles.filter((r) => r.isSystem);
+
+  const userRole = await rbac.getUserRole({
+    userId,
+    organizationId: orgMember.organizationId,
+  });
+
+  return { roles: systemRoles, userRoleId: userRole?.id ?? null };
+}
+
 export const loader = async ({ request }: LoaderFunctionArgs) => {
   const userId = await requireUserId(request);
 
   try {
-    const personalAccessTokens = await getValidPersonalAccessTokens(userId);
+    const [personalAccessTokens, { roles, userRoleId }] = await Promise.all([
+      getValidPersonalAccessTokens(userId),
+      loadSystemRolesForUser(userId),
+    ]);
+
+    // Default the role picker to the user's own role in their primary
+    // org so a freshly-created PAT isn't more privileged than the
+    // person creating it. Falls back to Member if they don't have one
+    // (new user, OSS path with no role assignments yet).
+    const defaultRoleId = userRoleId ?? SYSTEM_ROLE_IDS.member;
 
     return typedjson({
       personalAccessTokens,
+      roles,
+      defaultRoleId,
     });
   } catch (error) {
     if (error instanceof Response) {
@@ -81,6 +123,11 @@ const CreateTokenSchema = z.discriminatedUnion("action", [
       .string({ required_error: "You must enter a name" })
       .min(2, "Your name must be at least 2 characters long")
       .max(50),
+    // Optional — when the RBAC plugin isn't installed (OSS), the UI
+    // hides the dropdown and submits no roleId; the action passes that
+    // through and createPersonalAccessToken just doesn't write a
+    // TokenRole row.
+    roleId: z.string().optional(),
   }),
   z.object({
     action: z.literal("revoke"),
@@ -103,6 +150,7 @@ export const action: ActionFunction = async ({ request }) => {
         const tokenResult = await createPersonalAccessToken({
           name: submission.value.tokenName,
           userId,
+          roleId: submission.value.roleId,
         });
 
         return json({ ...submission, payload: { token: tokenResult } });
@@ -131,7 +179,7 @@ export const action: ActionFunction = async ({ request }) => {
 };
 
 export default function Page() {
-  const { personalAccessTokens } = useTypedLoaderData<typeof loader>();
+  const { personalAccessTokens, roles, defaultRoleId } = useTypedLoaderData<typeof loader>();
 
   return (
     <PageContainer>
@@ -151,7 +199,7 @@ export default function Page() {
             </DialogTrigger>
             <DialogContent className="max-w-md">
               <DialogHeader>Create a Personal Access Token</DialogHeader>
-              <CreatePersonalAccessToken />
+              <CreatePersonalAccessToken roles={roles} defaultRoleId={defaultRoleId} />
             </DialogContent>
           </Dialog>
         </PageAccessories>
@@ -211,7 +259,15 @@ export default function Page() {
   );
 }
 
-function CreatePersonalAccessToken() {
+type SystemRole = { id: string; name: string; description: string };
+
+function CreatePersonalAccessToken({
+  roles,
+  defaultRoleId,
+}: {
+  roles: SystemRole[];
+  defaultRoleId: string;
+}) {
   const fetcher = useFetcher<typeof action>();
   const lastSubmission = fetcher.data as any;
 
@@ -228,6 +284,13 @@ function CreatePersonalAccessToken() {
     ? (lastSubmission?.payload?.token as CreatedPersonalAccessToken)
     : undefined;
 
+  // OSS path: rbac.allRoles returns []; we hide the dropdown entirely
+  // rather than showing an empty Select. createPersonalAccessToken's
+  // roleId is optional, so omitting it produces a working PAT with no
+  // explicit role attached (matches pre-RBAC behaviour).
+  const showRolePicker = roles.length > 0;
+  const [selectedRoleId, setSelectedRoleId] = useState(defaultRoleId);
+
   return (
     <div className="max-w-full overflow-x-hidden">
       {token ? (
@@ -248,6 +311,7 @@ function CreatePersonalAccessToken() {
       ) : (
         <fetcher.Form method="post" {...form.props}>
           <input type="hidden" name="action" value="create" />
+          {showRolePicker && <input type="hidden" name="roleId" value={selectedRoleId} />}
           <Fieldset className="mt-3">
             <InputGroup>
               <Label htmlFor={tokenName.id}>Name</Label>
@@ -265,6 +329,37 @@ function CreatePersonalAccessToken() {
               <FormError id={tokenName.errorId}>{tokenName.error}</FormError>
             </InputGroup>
 
+            {showRolePicker && (
+              <InputGroup>
+                <Label>Role</Label>
+                <Select<string, SystemRole>
+                  value={selectedRoleId}
+                  setValue={(v) => setSelectedRoleId(v)}
+                  items={roles}
+                  variant="tertiary/small"
+                  dropdownIcon
+                  text={(v) => roles.find((r) => r.id === v)?.name ?? "Select a role"}
+                >
+                  {(items) =>
+                    items.map((role) => (
+                      <SelectItem key={role.id} value={role.id}>
+                        <span className="flex flex-col">
+                          <span>{role.name}</span>
+                          {role.description ? (
+                            <span className="text-xs text-text-dimmed">{role.description}</span>
+                          ) : null}
+                        </span>
+                      </SelectItem>
+                    ))
+                  }
+                </Select>
+                <Hint>
+                  The token's permissions are bound to this role. Defaults to your own role so the
+                  token can't do more than you can.
+                </Hint>
+              </InputGroup>
+            )}
+
             <FormButtons
               confirmButton={
                 <Button type="submit" variant={"primary/small"}>

apps/webapp/app/services/personalAccessToken.server.ts

@@ -3,16 +3,30 @@ import { customAlphabet, nanoid } from "nanoid";
 import { z } from "zod";
 import { prisma } from "~/db.server";
 import { logger } from "./logger.server";
+import { rbac } from "./rbac.server";
 import { decryptToken, encryptToken, hashToken } from "~/utils/tokens.server";
 import { env } from "~/env.server";
 
 const tokenValueLength = 40;
 //lowercase only, removed 0 and l to avoid confusion
 const tokenGenerator = customAlphabet("123456789abcdefghijkmnopqrstuvwxyz", tokenValueLength);
 
+// The OSS fallback's setTokenRole returns this exact string when no
+// enterprise plugin is loaded. We treat that as "no role attached" —
+// the PAT is still valid; auth just falls through to legacy permissive
+// behaviour. Any other error is treated as a real failure and triggers
+// the compensating delete below.
+const FALLBACK_NOT_INSTALLED_ERROR = "RBAC plugin not installed";
+
 type CreatePersonalAccessTokenOptions = {
   name: string;
   userId: string;
+  // Optional: when provided, persist a TokenRole row alongside the PAT
+  // so PAT-authenticated requests pick up that role's permissions
+  // (TRI-8749). The dashboard tokens page passes a chosen system role;
+  // the CLI auth-code path doesn't pass one (legacy behaviour
+  // preserved — those PATs run with no explicit role).
+  roleId?: string;
 };
 
 /** Returns obfuscated access tokens that aren't revoked */
@@ -322,6 +336,7 @@ export async function createPersonalAccessTokenFromAuthorizationCode(
 export async function createPersonalAccessToken({
   name,
   userId,
+  roleId,
 }: CreatePersonalAccessTokenOptions) {
   const token = createToken();
   const encryptedToken = encryptToken(token, env.ENCRYPTION_KEY);
@@ -336,6 +351,48 @@ export async function createPersonalAccessToken({
     },
   });
 
+  // Persist the role choice in enterprise.TokenRole. This lives on a
+  // different schema (Drizzle, not Prisma) — co-transactional inserts
+  // across the two ORMs are awkward, so we use a compensating-delete
+  // pattern: if setTokenRole fails, roll back the PAT row by deleting
+  // it. The auth path treats "no role" as permissive (matches OSS
+  // fallback) so a brief orphan window between the two writes is
+  // harmless. The compensating delete narrows that window from "until
+  // manual cleanup" to "until the request returns".
+  if (roleId) {
+    const roleResult = await rbac.setTokenRole({
+      tokenId: personalAccessToken.id,
+      roleId,
+    });
+    if (!roleResult.ok) {
+      // The OSS fallback always returns ok=false with this exact
+      // message. That isn't a failure — there's no enterprise plugin
+      // to write to, so the PAT just runs without an explicit role
+      // (matches the pre-RBAC behaviour). Don't compensating-delete
+      // in that case.
+      if (roleResult.error === FALLBACK_NOT_INSTALLED_ERROR) {
+        logger.debug("createPersonalAccessToken: no RBAC plugin, skipping role assignment", {
+          patId: personalAccessToken.id,
+          userId,
+        });
+      } else {
+        await prisma.personalAccessToken
+          .delete({ where: { id: personalAccessToken.id } })
+          .catch((err) => {
+            logger.error(
+              "Failed to compensating-delete PAT after TokenRole insert failed",
+              {
+                patId: personalAccessToken.id,
+                roleResultError: roleResult.error,
+                deleteError: err instanceof Error ? err.message : String(err),
+              }
+            );
+          });
+        throw new Error(`Failed to assign role to access token: ${roleResult.error}`);
+      }
+    }
+  }
+
   return {
     id: personalAccessToken.id,
     name,