This is clean on paper, but real-world RBAC always ends up with just one exception that breaks everything. How do you handle custom roles per tenant without exploding complexity?
@[Starball] The full technique is coming in the next part, but since you asked:
The core idea is to think in terms of who interacts with the system and what they're allowed to do: roles and permissions modeled from actual user behavior, not invented upfront.
In the KPI manager example, every tenant has at least three baseline roles: Owner, Manager, and User. These are your system defaults. Custom tenant roles are just derivations: duplicated from these defaults with modified permissions.
Here's how the design works in practice:
Annotate your routes. Each route carries metadata about its controller (class, package, or function) and which default roles can access it. Pick one style and stay consistent.
Extract defaults via script. A script loops through all routes, pulls out the module, method, and allowed default roles, and flattens that into a list. From this, you seed both the roles table and the permissions table using your constants/enums (Owner, Manager, User).
Bootstrap each tenant from defaults. When a tenant is created, those default roles are duplicated into the tenant's scope. The tenant owner can freely create or modify roles but permissions themselves are read-only. They can't invent new access vectors, only configure which roles get which existing permissions.
Assign roles at user creation. Each user gets one or more roles based on what the tenant needs.
This keeps the explosion contained: permissions are a closed, system-defined set. Tenants customize role composition, not the permission surface itself.
Tone is direct, technical audience-appropriate. Let me know if you want any part expanded before posting.
