Name of the top-tier system role. Treated as a glass-break super-user:
auth checks short-circuit to "allowed" when the user holds this role,
regardless of the DB-side permission set (see lib/auth.ts).
Because owner's grants are computed in code and never read from the DB,
its permission set is not editable via the matrix — editing it would
be a silent no-op. AdminDashboardRoleService.update rejects owner
permission-set changes and the matrix UI disables owner's cells. The
other system roles (admin/member/viewer) keep editable permission
sets; is_system only blocks renames and deletion, not permission edits.
Lives in its own module so AdminDashboardUserService can read it
without importing AdminDashboardRoleService — the two services
reference each other for types and helpers, and routing a runtime
constant through either of them creates a circular module-evaluation
order that Turbopack resolves non-deterministically.
Name of the top-tier system role. Treated as a glass-break super-user: auth checks short-circuit to "allowed" when the user holds this role, regardless of the DB-side permission set (see
lib/auth.ts).Because owner's grants are computed in code and never read from the DB, its permission set is not editable via the matrix — editing it would be a silent no-op.
AdminDashboardRoleService.updaterejects owner permission-set changes and the matrix UI disables owner's cells. The other system roles (admin/member/viewer) keep editable permission sets;is_systemonly blocks renames and deletion, not permission edits.Lives in its own module so
AdminDashboardUserServicecan read it without importingAdminDashboardRoleService— the two services reference each other for types and helpers, and routing a runtime constant through either of them creates a circular module-evaluation order that Turbopack resolves non-deterministically.