Scoped Roles

Scoped Membership Roles

Colabmacs supports scoped membership roles, allowing administrators to grant users elevated permissions within a specific relationship instead of assigning everything globally.

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

The three supported membership contexts are:

• Team Members
• Project Members
• Resource Team Members

Each context uses roles that are explicitly marked for that assignment type.

New in This Release

Roles can now be explicitly scoped to Team Members, Project Members, and Resource Team Members. This reduces role ambiguity and makes delegated role assignment much clearer.

How Scoped Roles Work

Scoped roles are assigned to the relationship, not to the user globally.

Key characteristics:

• Roles are attached to a specific membership record
• Permissions granted by the role are evaluated within that scoped context
• System roles remain global and are evaluated independently
• Scoped roles never grant general system-wide access on their own

This makes it possible to delegate responsibility for one team, one project, or one resource-support relationship without affecting unrelated areas.

Role Contexts

When creating or editing a role, administrators can control where it may be assigned.

Available role contexts are:

• Team Member Role
• Project Member Role
• Resource Team Member Role

Only roles marked for a given context are available in that assignment UI.

This removes ambiguity and helps prevent a role intended for one kind of membership from appearing in the wrong place.

Add a Description

Use the role Description field to explain the role’s intended purpose, typical assignee, and any important limits. This makes delegated role assignment much easier for administrators and team managers.

Role Availability

Only roles marked as Public are available for assignment in scoped membership interfaces.

This ensures:

• Internal or system-only roles cannot be misapplied
• Administrators explicitly control which roles are usable in member assignment flows
• Delegated role management remains predictable

Info

Public roles are still regular system roles. The public flag only controls where the role may be assigned.

Where These Roles Are Assigned

Team Member Roles

Team-member roles are assigned on the team membership relationship.

Typical uses include:

• Delegated team management
• Member administration
• Team-level coordination

Project Member Roles

Project-member roles are assigned on the project-user relationship.

From the same interface, administrators can also configure:

• Project-user budgets
• Project-user expiration dates

Typical uses include:

• Project management
• Project-level coordination
• Delegated access to project operations

Resource Team Member Roles

Resource Team Member roles are assigned on the resource support team relationship.

Typical uses include:

• Trainers
• Technicians
• Resource owners
• Support specialists

Info

For clean UI/UX, each assignment flow exposes a single role selector showing only the roles valid for that membership context.

Permission Scoping Behavior

Permissions granted by a scoped role are evaluated only within the relevant context.

Examples:

• A user with update team members via a team-member role can manage members for that team
• A user with update events via a project-member role can act within that project
• A user with a resource-support role can have permissions relevant to that resource assignment

Those permissions do not automatically expand into unrelated teams, projects, or global administration.

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.

Recommended: Team Manager Role

For delegated team administration, create a Team Manager role using team-relevant permissions such as:

Permission	Purpose
update teams	Update team settings
create team members	Invite or add team members
update team members	Adjust team-member roles
delete team members	Remove members from the team
create projects	Create projects for that team

This is a good fit for non-owner users who help manage a team without taking on system-wide administration.

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.

Best Practices

• Prefer scoped membership roles over system roles whenever possible
• Restrict scoped roles to public roles only
• Mark each role for the correct assignment context
• Use the Description field so administrators understand the intended use
• Use manage_* permissions for delegated ownership
• Keep system roles reserved for administrators
• Delegate responsibility without expanding global access