Project User Roles

Project-Scoped Permissions

Colabmacs supports project-scoped roles, allowing administrators to grant users elevated permissions within a single project only, without granting broader system access.

This enables delegated project management while preserving strong administrative and financial boundaries.

How Project Roles Work

Project roles are assigned to the project–user relationship, not to the user globally.

Key characteristics:

• Roles are attached to a user within a specific project
• Permissions granted by the role are scoped to that project only
• System roles remain global and are evaluated independently
• Project roles never grant access outside the associated project

This makes it possible to delegate responsibility for one project without affecting others.

Where Project Roles Are Assigned

Project roles are managed directly on the project–user pivot, alongside other project-specific constraints.

They can be updated from either:

• Projects → Project → Users
• Users → User → Projects

From the same interface, administrators can also configure:

• Project-user budgets
• Project-user expiration dates

Info

For clean UI/UX, Colabmacs exposes a single project role selector, even though the underlying permission system supports multiple roles.

Role Availability (Public Roles Only)

Only roles marked as Public are available for assignment at the project level.

This ensures:

• Internal or system-only roles cannot be misapplied
• Administrators explicitly control which roles are usable in projects
• Project governance remains predictable and secure

Info

Public roles are still regular system roles — the public flag only controls where they can be assigned.

Permission Scoping Behavior

Permissions granted by a project role are evaluated only when the user is operating within that project context.

Example:

• A user with update events via a project role:
  • ✅ Can update events belonging to that project
  • ❌ Cannot update events in other projects
  • ❌ Cannot update events globally unless they also hold a system role

Recommended: Project Manager Role

A common and strongly recommended pattern is to create a Project Manager role using manage_* permissions.

This provides meaningful authority while keeping scope tightly controlled.

Why manage_* Permissions Matter

The manage X permission automatically grants:

• view X
• create X
• update X
• delete X

This makes it ideal for delegated ownership roles where full lifecycle control is required.

Recommended Permissions for a Project Manager

Permission	Purpose
manage usage records	View and edit project usage records
manage usage sessions	Start and stop usage sessions
manage charges	View and manage project charges
manage events	Update project bookings and reservations
manage projects	Update project settings
manage project users	Add, remove, or edit project members

What a Project Manager Can Do

With the recommended permissions, a Project Manager can:

• View project usage in a searchable table
• View project charges in real time
• See all active usage sessions associated with the project
• Start or stop usage sessions (subject to access rules)
• Modify or cancel existing project bookings
• Add, remove, or update project members
• Apply project-user budgets and expiration dates
• Update project-level metadata

This enables day-to-day project operations without granting system-wide authority.

Usage Session Enforcement

When a project member starts a usage session:

• The user starting the session must pass all access rules
• All booking and activation rules are enforced
• Training requirements are evaluated on the acting user
• The usage session and resulting usage record are associated with the user who starts it

Tips

This allows project managers to coordinate work centrally while preserving safety, training, and access enforcement.

Individual Permission Notes

view projects

Allows viewing project details and metadata only.

update events + create usage sessions

Allows centralized coordination of project bookings and workflows.

This enables a project manager to start sessions from bookings created by other project members, without bypassing access rules.

Best Practices

• Prefer project roles over system roles whenever possible
• Restrict project roles to public roles only
• Use manage_* permissions for delegated ownership
• Keep system roles reserved for administrators
• Delegate responsibility without expanding global access