user_project_roles

This table assigns project-specific role overrides to project members. It allows a user to have one default role at company level and a different role on a specific project.

Domain: RBAC / Project Override
Scope: Project
Status: Proposed
Last Updated: 11 Apr 2026
Mutable: Yes
Primary Owner: RBAC / Core API
RLS Applies: Yes
Client Facing: Indirectly

Purpose

The purpose of this table is to override a user’s company-level role for a particular project. This enables the same person to hold different authority levels across different projects.

What this table does

  • Assigns a project-specific role to a project member
  • Overrides or refines company-level default access
  • Supports the PRD requirement for per-project role overrides

Why this table is defined

DirtView requires the same user to potentially be a Viewer on one project, but a Project Manager on another. That cannot be modeled cleanly with only a single company-level role assignment.

Columns

Column Type Required Description Example
project_member_id uuid Yes Project member receiving the override role pmember_001
role_id uuid Yes Role applied at project level role_project_manager
assigned_by uuid No User who assigned the override user_admin_001
assigned_at timestamptz Yes When the project role was assigned 2026-04-07 14:00:00+00

Relationships

How it is used

  • Resolved during authorization for project-scoped actions
  • Used when assigning special project authority to a user
  • Serves as the first lookup before falling back to company-level role

Access and security

  • Override assignments should be restricted to admins or authorized managers
  • Changes should be audited because they affect project authority
  • Enforce uniqueness to avoid duplicate role assignments for the same project member

Example scenarios

Scenario 1: Viewer becomes PM on one project

A user with Viewer at company level gets Project Manager on Project Phoenix through a row in this table.

Scenario 2: Superintendent on specific project

A company-wide Foreman is elevated to Superintendent for one high-importance project.

Scenario 3: No override exists

If no row exists here, the user’s company-level role remains the effective baseline.

Notes and assumptions

  • This table stores project override assignments, not project membership itself
  • Module-level access may still further refine behavior through project_module_access
  • Depending on business rules, you may allow one or multiple roles per project member