Users and permissions¶
FedMS' permission model is layered:
- Site-wide roles apply across the whole instance.
- Group roles apply inside specific orgs, events, or sessions.
Both layers combine into the effective permissions a user has at any given moment. The framework's permission model is described in depth in Members and roles. This section is the administrator's view — how to manage roles and permissions in practice.
In this section¶
- Site roles — the instance-wide roles and how to assign them.
- Group roles — the in-group roles and how they are derived or assigned.
- Permissions matrix — the role × permission table for orgs, events, and sessions.
How permissions are managed¶
The role-to-permission mapping is declarative — it lives in
fedms_federation/config/roles_permissions.yml and is applied via
the Roles Permission Builder
module.
This means:
- The truth is in one YAML file, version controlled in
fedms/components/federation. - Permissions can be rebuilt deterministically on any instance.
- Changes made via the Drupal admin UI (
/admin/people/permissions) are not the source of truth — they will be overwritten on the next config rebuild.
To change a permission for a role:
- Open
roles_permissions.yml. - Make the change there.
- Rebuild on each instance:
1 | |
- Export config and commit.
For group roles, the same module needs to be extended — see
fedms/components/profile#10.
Adding a user¶
To add a new user:
/admin/people/create- Fill in username, email, password.
- Assign one or more site roles.
- Save.
To add the user to a group with a specific group role:
- Open the group (org / event / session).
- Members tab → Add member.
- Pick the user, pick the group role(s), save.
Removing a user¶
User removal is soft: the account is blocked, and their group relationships are deactivated, but nothing is hard-deleted. This preserves the audit trail.
Hard deletion is available for GDPR / right-to-erasure requests; use
/admin/people → bulk operation → Delete. Be aware this removes
the user from all historical records.
Masquerading¶
The Masquerade module is installed by default. Users with the
masquerade as user permission (typically Admins and DevOps) can
temporarily impersonate another user from the admin UI — useful for
debugging "what does X see?" questions without using the user's
credentials.
There is a known login-button visibility issue tracked at
fedms/support#71.
Role delegation¶
The Role Delegation module lets you give a Manager the ability to
assign specific roles to other users without giving them the
full administer permissions permission. Configure at
/admin/people/role-delegation.