role_permissions

This table maps roles to permissions. It defines what each role is allowed to do and is the main bridge between named roles and granular access rules.

Domain: RBAC

Scope: Tenant role mapping

Status: Proposed

Last Updated: 11 Apr 2026

Mutable: Yes

Primary Owner: RBAC / Core API

RLS Applies: Yes, through role ownership

Client Facing: Indirectly

Purpose

The purpose of this table is to define the set of permissions granted to each role. It allows the platform to change access behavior without changing the meaning of a role name in code.

What this table does

Maps a role to one or more permissions
Forms the effective capability bundle behind a role
Supports default roles and future tenant-customized roles
Allows more precise access control than hardcoded role checks

Why this table is defined

DirtView needs roles to be understandable for humans and permissions to be understandable for machines. This table connects those two layers.

Columns

Column	Type	Required	Description	Example
`role_id`	uuid	Yes	Role receiving the permission	`role_pm`
`permission_id`	uuid	Yes	Permission granted to the role	`perm_drawings_view`
`is_allowed`	boolean	Yes	Whether this permission is granted for the role	`true`
`created_at`	timestamptz	Yes	Creation timestamp	`2026-04-01 08:00:00+00`

Relationships

role_id → roles.id
permission_id → permissions.id

How it is used

Read during authorization checks to expand a role into actual permissions
Used in tenant admin UI when showing or editing role capabilities
Seeded for default roles during onboarding

Access and security

Changes here directly affect user authorization and should be tightly controlled
Role-permission changes should be audited
Use uniqueness constraints to avoid duplicate mappings

Example scenarios

Scenario 1: Project Manager role

The Project Manager role is linked to permissions such as projects.view, drawings.view, rfi.manage, and projects.members.manage.

Scenario 2: Viewer role

The Viewer role is linked only to read-oriented permissions.

Scenario 3: Safety Manager role

The Safety Manager role may get strong form and certification permissions but limited project administration permissions.

Notes and assumptions

This is a mapping table, not a permission definition table
Most systems will only store allowed permissions, but is_allowed leaves room for future explicit deny rules if needed
Use composite primary key or unique constraint on (role_id, permission_id)