Users, Roles and Permissions

TX1's identity model is User → Role → Permission. A role is a bundle of permissions; a user gets one or more roles.

Core Entities

Default Roles

Creating a User

Admin → Users → New User:

1. Username (unique).
2. Display name.
3. Email (used for password recovery).
4. Initial password (force change on first login, optional).
5. Roles.
6. Optional security questions and recovery codes.

Assigning Roles

Multi-select roles — they compose (permission sum). A user with both Estimator and Viewer simply gets Estimator's permissions (Viewer adds nothing extra).

Custom Roles

Admin → Roles → New Role:

1. Name and description.
2. Tick individual permissions.
3. Save.

Typical custom roles:

• Reviewer — view all, approve items, but cannot edit.
• Finance — read projects, full access to markup and margins.
• Carbon Lead — full access to the Carbon view, read everywhere else.

Permissions Catalogue

The Permissions entity is populated with fine-grained capabilities like:

• Projects: View, Create, Edit, Delete, Archive, Lock, Release-Lock-of-Others.
• Resources: View, Create, Edit, Delete, Save-to-Master.
• Templates: View, Use, Edit, Publish-to-Organisation.
• Markup: View, Edit.
• Carbon: View, Edit, Verify, Unverify.
• Admin: Manage Users, Manage Roles, Manage Permissions, Manage Master Library.

Seats and Licensing

Active users are bound by the licence. Deactivating (not deleting) a user frees a seat without destroying history.

User Deletion vs Deactivation

• Deactivate — user cannot sign in, history preserved, seat freed.
• Delete — hard delete, blocked if the user is the CreatedBy of any audited entity. Prefer deactivation.

Audit Trail

Every entity in TX1 inherits AuditableEntity:

• CreatedAt / CreatedByUserId
• ModifiedAt / ModifiedByUserId

Queryable under Admin → Audit Log.