RBAC: auto-assign system roles on org create + invite accept (TRI-8854)

Pairs with the enterprise/db backfill migration (cloud side) so every
new (user, org) pair gets a UserRole row from day one without anyone
falling through to PERMISSIVE_ABILITY on the Teams page.

Mapping mirrors the backfill (legacy ADMIN had full access; the new
Admin role excludes billing + member management, so legacy ADMIN
belongs in the new Owner slot, not the new Admin slot):

  legacy ADMIN  -> Owner  (sys_role_owner)
  legacy MEMBER -> Member (sys_role_member)

Changes:

- services/rbac.server.ts: export SYSTEM_ROLE_IDS constant. The IDs
  are seeded by the enterprise/db migration and never change; both
  org creation and invite acceptance import from here so the role
  reference is in one place.
- models/organization.server.ts: createOrganization calls
  rbac.setUserRole({ roleId: owner }) after the org row is created.
  Outside any transaction (rbac uses a separate Drizzle/postgres-js
  connection). On OSS the fallback returns ok=false; we log + continue
  since the legacy OrgMember.role write is the source of truth there.
- models/member.server.ts: acceptInvite assigns Owner if the invite
  was ADMIN (defensive — the current UI only invites with MEMBER) or
  Member otherwise. setUserRole runs after the prisma transaction
  commits for the same reason as above. Returns the same shape as
  before so callers don't change.

Verification: typecheck clean. Migration step (TRI-8854 part 1) is on
the cloud side; together they ensure both existing and new (user, org)
pairs land on a sensible RBAC role.

Author: matt-aitken

.server-changes/rbac-userrole-default-assignment.md

@@ -0,0 +1,11 @@
+---
+area: webapp
+type: feature
+---
+
+RBAC: auto-assign system roles when creating an org or accepting an
+invite (TRI-8854). createOrganization assigns the Owner role to the
+creator; acceptInvite assigns Owner if the invite was ADMIN (defensive
+— current UI only invites with MEMBER) or Member otherwise. Pairs with
+the enterprise/db migration that backfills UserRole rows from existing
+OrgMember.role data on RBAC go-live.

apps/webapp/app/models/member.server.ts

@@ -1,6 +1,8 @@
 import { type Prisma, prisma } from "~/db.server";
 import { createEnvironment } from "./organization.server";
 import { customAlphabet } from "nanoid";
+import { logger } from "~/services/logger.server";
+import { rbac, SYSTEM_ROLE_IDS } from "~/services/rbac.server";
 
 const tokenValueLength = 40;
 const tokenGenerator = customAlphabet("123456789abcdefghijkmnopqrstuvwxyz", tokenValueLength);
@@ -163,7 +165,7 @@ export async function acceptInvite({
   user: { id: string; email: string };
   inviteId: string;
 }) {
-  return await prisma.$transaction(async (tx) => {
+  const result = await prisma.$transaction(async (tx) => {
     // 1. Delete the invite and get the invite details
     const invite = await tx.orgMemberInvite.delete({
       where: {
@@ -207,8 +209,41 @@ export async function acceptInvite({
       },
     });
 
-    return { remainingInvites, organization: invite.organization };
+    return {
+      remainingInvites,
+      organization: invite.organization,
+      inviteRole: invite.role,
+    };
+  });
+
+  // 5. Assign the corresponding RBAC role for the new member. Done
+  // outside the transaction because rbac runs against a separate
+  // postgres-js connection (Drizzle, not Prisma) — calling it inside
+  // the tx would mix transaction boundaries. The legacy OrgMember.role
+  // → RBAC mapping matches the backfill migration (TRI-8854):
+  //   ADMIN  → Owner
+  //   MEMBER → Member
+  // In practice every invite is created with role=MEMBER (see
+  // inviteMembers above — there's no UI to invite someone as ADMIN),
+  // so the ADMIN branch is defensive cover for direct DB writes.
+  // OSS fallback returns ok=false; we log + continue (legacy
+  // OrgMember.role is the source of truth for OSS auth).
+  const roleId =
+    result.inviteRole === "ADMIN" ? SYSTEM_ROLE_IDS.owner : SYSTEM_ROLE_IDS.member;
+  const roleResult = await rbac.setUserRole({
+    userId: user.id,
+    organizationId: result.organization.id,
+    roleId,
   });
+  if (!roleResult.ok) {
+    logger.debug("acceptInvite: skipped RBAC role assignment", {
+      organizationId: result.organization.id,
+      userId: user.id,
+      reason: roleResult.error,
+    });
+  }
+
+  return { remainingInvites: result.remainingInvites, organization: result.organization };
 }
 
 export async function declineInvite({

apps/webapp/app/models/organization.server.ts

@@ -12,6 +12,8 @@ import slug from "slug";
 import { prisma, type PrismaClientOrTransaction } from "~/db.server";
 import { env } from "~/env.server";
 import { featuresForUrl } from "~/features.server";
+import { logger } from "~/services/logger.server";
+import { rbac, SYSTEM_ROLE_IDS } from "~/services/rbac.server";
 import { createApiKeyForEnv, createPkApiKeyForEnv, envSlug } from "./api-key.server";
 import { getDefaultEnvironmentConcurrencyLimit } from "~/services/platform.v3.server";
 export type { Organization };
@@ -82,6 +84,26 @@ export async function createOrganization(
     },
   });
 
+  // Assign the creator the Owner system role so the new Teams page UI
+  // shows them as an Owner from the moment the org exists. Mirrors the
+  // legacy `OrgMember.role = "ADMIN"` write above (TRI-8854: legacy
+  // ADMIN maps to new Owner, not new Admin — the new Admin role
+  // excludes billing + member management). On the OSS deployment the
+  // fallback's setUserRole returns ok=false and we just log; the legacy
+  // OrgMember.role write is the source of truth for OSS auth.
+  const roleResult = await rbac.setUserRole({
+    userId,
+    organizationId: organization.id,
+    roleId: SYSTEM_ROLE_IDS.owner,
+  });
+  if (!roleResult.ok) {
+    logger.debug("createOrganization: skipped RBAC role assignment", {
+      organizationId: organization.id,
+      userId,
+      reason: roleResult.error,
+    });
+  }
+
   return { ...organization };
 }
 

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

@@ -15,3 +15,16 @@ export const rbac = plugin.create(
   { getSessionUserId },
   { forceFallback: env.RBAC_FORCE_FALLBACK }
 );
+
+// Stable IDs for the system roles seeded by the enterprise/db migration
+// (cloud/enterprise/db/drizzle/migrations/0000_legal_titanium_man.sql).
+// They never change — anything that needs to set a default role at
+// creation time keys off these. The OSS fallback's setUserRole returns
+// `{ ok: false, error: "RBAC plugin not installed" }` and is safe to
+// call with these ids; it just no-ops.
+export const SYSTEM_ROLE_IDS = {
+  owner: "sys_role_owner",
+  admin: "sys_role_admin",
+  member: "sys_role_member",
+  viewer: "sys_role_viewer",
+} as const;