project_module_access

This table stores module-level access rules for a user within a specific project. It is the finest-grained part of the 3-level access model after company-level and project-level role assignment.

Domain: RBAC / Module Access

Scope: Project / Module

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 define module-specific access for a project member, such as whether the member can read or write Drawings, Forms, RFIs, Documents, or Photos within that project.

What this table does

Stores module-level access flags for a project member
Allows fine-grained read/write control per module
Acts as the third layer in the access model: company → project → module
Can further restrict or clarify what a project role allows in practice

Why this table is defined

DirtView’s architecture explicitly requires independent module-level access within a project. For example, a user may be on a project but should only access Drawings and RFIs, not Forms or Documents.

Columns

Column	Type	Required	Description	Example
`id`	uuid	Yes	Primary key for the module access record	`pma_001`
`tenant_id`	uuid	Yes	Tenant owning the project and user	`tenant_001`
`project_id`	uuid	Yes	Project the access applies to	`project_phoenix`
`project_member_id`	uuid	Yes	Project member receiving the module access rule	`pmember_001`
`module_key`	text	Yes	Module name being controlled	`drawings`
`can_read`	boolean	Yes	Whether the project member can view this module	`true`
`can_write`	boolean	Yes	Whether the project member can create or modify in this module	`false`
`assigned_by`	uuid	No	User who set this module access	`user_pm_001`
`assigned_at`	timestamptz	Yes	When the module rule was created or set	`2026-04-07 15:00:00+00`

Relationships

tenant_id → tenants.id
project_id → projects.id
project_member_id → project_members.id
module_key conceptually aligns with module concepts used elsewhere in the app

How it is used

Evaluated during project-scoped authorization checks
Used by UI to decide which modules to show inside a project
Used by backend to allow or reject module-specific actions
Can work alongside role-derived permissions for finer control

Access and security

Changes here directly affect module visibility and editability
Use uniqueness constraints on (project_member_id, module_key)
Only authorized project admins/managers should change module access
Module access changes should be audited

Example scenarios

Scenario 1: Drawings read-only access

A project member can view Drawings but not upload or annotate them: module_key=drawings, can_read=true, can_write=false.

Scenario 2: Forms-only field user

A user can write Forms but has no access to RFIs or Documents on the project.

Scenario 3: Restrict one module despite broad role

A generally powerful role may still be limited from one module for a specific project.

Notes and assumptions

This table is the finest-grain project access layer in the current RBAC design
It should complement, not replace, company and project role assignment
Be clear in code about precedence rules between role-derived permissions and module overrides