Modules

FedMS' functionality is split across one install profile and seven component modules. Each is published as a separate Composer package and lives in its own GitLab project. This page is the high-level index — each module gets its own detailed page.

The install profile

Profile	Composer package	Purpose
fedms	fedms/profile	Bootstraps a tenant site; declares the baseline modules, themes, and config.

The seven component modules

Module	Composer package	What it provides
fedms_federation	fedms/federation	Group types (org, event, session), federation hooks, group-membership lifecycle, permissions YAML.
fedms_content	fedms/content	fedms_event and fedms_session content entities, default paragraph types.
fedms_attachment	fedms/attachment	fedms_attachment content entity.
fedms_task	fedms/task	fedms_task content entity, fedms_task_pattern config entity, ECA condition plugins.
fedms_eca	fedms/eca	The 10 ECA models that encode the business logic.
fedms_locale	fedms/locale	i18n / l10n (German shipped).
Scripts and recipes	fedms/scripts + fedms-recipe/*	Install / config / export Ahoy commands and optional Drupal recipes.

Dependency order

The modules depend on each other in this order (lower = lower in the stack):

fedms_locale     (independent)

fedms_content    (independent of federation)
├── group:group
├── paragraphs
└── viewsreference

fedms_attachment ─→ fedms_content
                   ├── drupal:media
                   ├── drupal:text
                   ├── field_group
                   └── paragraphs

fedms_federation ─→ fedms_content
                   ├── address
                   ├── color_field
                   ├── drupal:telephone
                   ├── drupal:taxonomy
                   ├── group:gnode
                   ├── group:group
                   ├── groupmedia
                   ├── pathauto
                   ├── smart_date
                   └── subgroup

fedms_task       ─→ fedms_attachment
                   ├── drupal:node
                   ├── smart_date
                   └── webform

fedms_eca        ─→ fedms_task + many ECA modules
                   (eca_access, eca_base, eca_cache, eca_config,
                    eca_content, eca_endpoint, eca_form,
                    eca_language, eca_log, eca_misc, eca_queue,
                    eca_render, eca_ui, eca_user, eca_views,
                    plus eca_entity_print, eca_group, eca_tamper,
                    eca_vbo, eca_webform, easy_email,
                    group_action, modeler, modeler_api,
                    symfony_mailer_lite, token)

The install profile pulls all of this in and orders the install correctly.

How to pick the right module for a change

If you're adding or changing something, the right module is usually:

Change	Module
A field on the org / event / session group	fedms_federation
A field on the fedms_event / fedms_session content entity	fedms_content
A field on fedms_attachment	fedms_attachment
A field on fedms_task	fedms_task
A new task-pattern condition plugin	fedms_task
A new ECA model or change to an existing model	fedms_eca
A translation / language addition	fedms_locale
A new optional feature bundle	A new recipe under fedms/components/recipes/
Cross-cutting workflow that touches everything	fedms_eca plus a coordinating module
Site-specific code	A site-specific custom module (not a fedms_* module)

What does not belong in any FedMS module

These belong to the tenant site, not the framework:

• Specific orgs, events, sessions, users, memberships.
• Tenant-specific event types, session types, attachment types, task patterns.
• Tenant-specific books and content.
• Tenant-specific theming.
• Tenant-specific recipes.

Keep tenant content out of the framework repos — it pollutes the clean per-customer install.

Next steps

• Open the page for the module you want to learn about (links above).
• For the data model in code, see Entities.
• For ECA models, see ECA models.