project_members
This table assigns tenant members to projects. It is the base project membership layer used before applying project-specific roles or module permissions.
Purpose
The purpose of this table is to define which tenant members belong to which projects. It answers the question: “Can this user access this project at all?”
What this table does
- Links a tenant membership to a specific project
- Acts as the membership gate for project-scoped access
- Provides the basis for project-level role overrides
- Supports project-specific access control and RLS checks
Why this table is defined
DirtView supports project-level access boundaries. A user may belong to a tenant but still should not automatically have access to every project inside that tenant. This table makes project access explicit.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the project membership record | pmember_001 |
tenant_id |
uuid | Yes | Tenant owning the project and membership | tenant_001 |
project_id |
uuid | Yes | Project being assigned | project_phoenix |
membership_id |
uuid | Yes | Tenant membership being assigned to the project | membership_123 |
is_active |
boolean | Yes | Whether the project membership is currently active | true |
joined_at |
timestamptz | Yes | When the user was added to the project | 2026-04-07 12:00:00+00 |
added_by |
uuid | No | User who added the member to the project | user_admin_001 |
Relationships
- tenant_id → tenants.id
- project_id → projects.id
- membership_id → tenant_memberships.id
- id is referenced by user_project_roles.project_member_id
- id is referenced by project_module_access.project_member_id
How it is used
- Checked by project-level RLS policies
- Used to populate project roster and assignments
- Acts as the base record for project-level role and module overrides
- Used when inviting or removing users from a project
Access and security
- This table is central to project isolation and must be correct
- Project membership changes should be audited
- Enforce uniqueness on
(project_id, membership_id) - Only authorized users should add or remove project members
Example scenarios
Scenario 1: Add PM to one project
A tenant member is added to Project Phoenix through a new project member row.
Scenario 2: Remove a user from project access
The project membership is deactivated so the user no longer sees the project.
Scenario 3: Basis for project override
After membership exists, a project-specific role can be assigned through user_project_roles.
Notes and assumptions
- This table gives project presence, not necessarily project authority
- Project roles and module access are layered on top of this table
- Keep project membership separate from employee project assignment