Skip to content

Members and roles

FedMS has two layers of roles:

  1. Site-wide roles that determine what a user can do across the whole instance (administer the site, create content types, manage their own profile, etc.).
  2. Group roles that determine what a user can do inside a specific organization, event, or session.

A user typically has one site-wide role and multiple group roles across many groups.

Site-wide roles

Site-wide roles are the standard Drupal roles, customized for FedMS.

Site role Description
Anonymous Site visitors before login. Almost no permissions.
Authenticated Default role on login. Almost no permissions on its own.
Manager Operational manager. Can create orgs, events, sessions; runs day-to-day.
Content Manager Can create and configure event/session/attachment types and their fields.
Host Reserved for host-specific cross-group capabilities (under review).
DevOps Used by automation accounts; sees everything.
Administrator Emergency / framework-level administration; not used for daily work.

The site-wide role-to-permission mapping is built declaratively from fedms_federation/config/roles_permissions.yml via the Roles Permission Builder module, so the mapping is auditable and rebuildable.

Group roles

Every group (org, event, session) has its own membership list, and each membership carries one or more group roles. Group roles fall into three categories:

Category Description
Outsider roles Apply to users who are not members of the group. Mapped automatically from site-wide roles.
Insider roles Apply to users who are members of the group. The base insider role is member.
Individual roles Assigned manually per member. These express the function the person serves in the group.

The individual roles are the interesting ones — they encode the FedMS domain.

The individual roles

Role Typical meaning Available on
Manager Runs the group operationally. Has the broadest permissions. org, event, session
Host / Sponsor The org or event's external face; often a representative of the client. org, event, session
Speaker / Tutor Delivers content during a session. event, session
Moderator Facilitates a session; may speak less than the speaker but holds the room. event, session
Attendee / Delegate The primary audience of an event/session. event, session
Service Provider A third party providing a service (venue, AV, catering, interpretation). event, session
Observer Watches without participating. Used for shadowing, training of trainers, or auditing. event, session

Not every group needs every role. A small workshop may have only a Manager, a Speaker, and Delegates.

Role sync between site and group

For the outsider and insider roles, the group role is derived automatically from the user's site-wide role:

Site role Outsider role Insider role
Anonymous Anonymous (not applicable)
Authenticated Outsider Member
DevOps DevOps (outsider) DevOps (insider)
Administrator Administrator (outsider) Administrator (insider)

This sync is what guarantees that, for example, any authenticated user automatically picks up the member group role as soon as they are added as a group member — without anyone having to do a manual role assignment.

The individual roles (Manager, Host, Speaker, etc.) are never synced. They are always assigned by hand (or by an ECA model, but deliberately, not as a function of the site role).

Permissions

Permissions in FedMS are managed declaratively via the Roles Permission Builder module. The full mapping lives in fedms_federation/config/roles_permissions.yml and is the source of truth.

The matrix is detailed; the Permissions matrix page in the Admin guide shows it in a readable form, broken down by role and group bundle.

How memberships are managed

Memberships are not deleted; they are deactivated. The group_relationship entity has a status base field (added by fedms_federation) that flips to FALSE when a member is "removed", preserving the audit trail.

This means:

  • A removed member can be re-activated with their original role and history intact.
  • Reports can answer "who has ever been a member of this event?" without losing the answer to "who is currently a member?".

The full membership lifecycle is implemented by the group_members ECA model.

Cross-group: org → event → session

Memberships at different levels are independent, but there is a deliberate constraint between them:

  • A session member must also be an event member (server-side enforced — see Sessions).
  • An event member does not have to be an org member (yet). This is under discussion; see fedms/components/federation for current thinking.

Next steps