Site roles

A site role is a Drupal role that applies across the whole instance. Every user has at least one site role (anonymous if not logged in, authenticated once logged in) and may have more.

The site roles shipped with FedMS

Role	Source of truth for permissions	Typical use
anonymous	Drupal default + FedMS config	Visitors before sign-in.
authenticated	Drupal default + FedMS config	Every signed-in user.
manager	roles_permissions.yml → manager	Operational role: create groups, orgs, events.
content_manager	(Drupal core permissions)	Configure event/session/attachment types and fields.
host	roles_permissions.yml → host	Under review — reserved for cross-group Host capabilities.
devops	roles_permissions.yml → devops	Automation accounts; sees everything.
administrator	Drupal core	Framework administration; emergency use.

What each role gives

Manager (site-wide)

The site-wide manager role permits creation of the structural units:

• create org group
• create event group
• create session group
• access group overview

These are framework-level permissions, distinct from the per-group manager role (which permits managing a specific group's content and members).

Content Manager

The Content Manager role is for users who design the data model: event types, session types, attachment types, paragraph types, fields, view modes, and task patterns.

Content Managers typically work in the structure section (/admin/structure), the field UI, the views UI, and the workflow modeler.

Content Managers are not the same as Managers. A Content Manager sets up the templates; a Manager uses those templates to run events.

DevOps

DevOps is the operator role. It is intended for:

• Automation accounts (e.g. the user that runs cron, the user that authenticates against the API).
• Operators handling deployments, backups, monitoring.

DevOps sees everything across all groups. Don't assign this to end-users — it bypasses the group-level access controls.

Administrator

The Administrator role is the root role in Drupal — bypasses most access checks. Reserve it for emergency framework administration. Don't use it for daily operations.

Assigning site roles

/admin/people → edit the user → check the relevant roles → save.

For automation, use drush user:role:add <role> <username>.

Site role → group role sync

The framework derives the outsider and member (insider) group roles automatically from the site role:

Site role	Outsider group role	Insider group role
anonymous	anonymous	(n/a)
authenticated	outsider	member
devops	devops_out	devops_in
administrator	admin_out	admin_in

The individual group roles (Manager, Host, Speaker, etc.) are not synced — they are always assigned per-membership. See Group roles.

Adding a new site role

Adding a new site role is rarely necessary — the shipped set covers most needs. If you do need one (e.g. a custom "Auditor" role with read-only access across the instance):

1. Add a user.role.<id> config entity in the appropriate module.
2. Define the role's permissions in roles_permissions.yml.
3. Rebuild and export.

See Developer guide → Permissions for the code-level workflow.