Concepts

This section defines the domain model of FedMS. It is the single source of truth for what every term in the application means. Users, administrators, developers, and AI agents should all agree on the definitions here.

If something behaves contrary to what these pages say, that is a bug — either in the code or in this documentation. Please open an issue against fedms/documentation.

The big picture

A FedMS instance is shaped by a small number of primitives that compose into a rich workflow:

┌────────────────────────────────────────────────────────────────────┐
│                                                                    │
│   Org ───── sub-Orgs                                                │
│    │                                                               │
│    └── Events ───── Sub-Events?  (planned)                          │
│            │                                                       │
│            └── Sessions                                             │
│                                                                    │
│   Each level is a group with:                                       │
│     - members (users with roles)                                    │
│     - content (book pages, media, paragraphs, etc.)                │
│     - tasks (instances of task patterns)                            │
│     - attachments (wrappers around media / webforms)                │
│                                                                    │
│   Federation synchronizes the right slices                          │
│   between participating FedMS instances.                            │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

In this section

Page	What it covers
Federation	What makes FedMS federated, and how instances exchange data.
Organizations	The org group: the top-level tenant unit, plus sub-orgs.
Events	The event group and the fedms_event content entity.
Sessions	The session group and the fedms_session content entity.
Members and roles	How people are attached to groups, and what each role can do.
Content and attachments	Books, pages, paragraphs, media, and fedms_attachment.
Tasks and milestones	The fedms_task content entity and the milestone taxonomy.
Task patterns	The fedms_task_pattern config entity that spawns tasks.
Glossary	A quick alphabetical lookup of every FedMS term.

Two parallel entity worlds — don't confuse them

FedMS deliberately uses two parallel sets of entities for organizations, events, and sessions:

World	Entity type	Used for
Group world	group (bundle org, event, or session)	Structure, hierarchy, membership, federation, permissions
Content world	fedms_event, fedms_session	Editorial body, paragraphs, view modes, translations

When someone says "the event", they may mean either the event group or the event content entity, depending on context. The two are linked but distinct.

Why two? Because Drupal's group module is excellent at the structural things (membership, sub-grouping, access control) and Drupal's content entity API is excellent at the editorial things (fields, paragraphs, translations, revisions). Trying to do both with one entity type sacrificed one or the other; using both lets each do what it does best.

If you are a developer, the Entities page in the Developer guide explains how to navigate between the two worlds in code.