Skip to content

ECA models

FedMS ships 10 ECA models in fedms_eca/config/optional/. Each encodes one slice of business logic declaratively as Events → Conditions → Actions. Together they implement most of the framework's runtime behavior.

If you are new to ECA, read the ECA guide first — it explains the events / conditions / actions / gateways / tokens vocabulary.

The 10 models at a glance

Model Plugins Heart of … Reference
task_api 187 The task spawning engine. Walks patterns and creates fedms_task instances. task_api
group_members 163 Membership lifecycle — add/remove/re-activate; soft-delete via group_relationship.status. group_members
event_groups 63 Event-group lifecycle: form prep, clone flow, local-tasks/operations. event_groups
group_blocks 35 Group-context block rendering (new-content, new-subgroup, new-member tiles). group_blocks
users 28 User lifecycle — login, prepare/build form, presave, update. users
milestone_views 17 Custom rendering for events/sessions in milestone Views. milestone_views
session_groups 15 Session-group lifecycle: form prep, member-pool restriction (UI). session_groups
views_fields 13 Computed/derived fields exposed to Views (Edit links, member ops). views_fields
group_operations 9 Operations menu, group-context tokens, pre-save guarantees. group_operations
links 3 Contextual link alteration (destination params, theme-aware variants). links

(Plugin counts are approximate — they grow over time.)

Where models live

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
web/modules/contrib/fedms_eca/config/optional/
├── eca.eca.event_groups.yml
├── eca.eca.group_blocks.yml
├── eca.eca.group_members.yml
├── eca.eca.group_operations.yml
├── eca.eca.links.yml
├── eca.eca.milestone_views.yml
├── eca.eca.session_groups.yml
├── eca.eca.task_api.yml
├── eca.eca.users.yml
└── eca.eca.views_fields.yml

Each YAML file is machine-generated by the modeler. Don't hand-edit them — go through the modeler at /admin/config/workflow/eca and re-export.

In-code docs for each model also live alongside the YAML at:

1
web/modules/contrib/fedms_eca/docs/<model>.md

These are the canonical in-repo references, kept in sync with the model files. The pages in this documentation site mirror them and add cross-references into the wider docs.

Common cross-references

Many models depend on each other. The key relationships:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
   users ───── triggers ─────► task_api
     │                             ▲
     │                             │
     ▼                             │
   group_members ─── feeds ────────┤
     │                             │
     ▼                             │
   event_groups, session_groups ───┤
     │                             │
     ▼                             │
   group_operations (tokens) ──────┘
     │
     ▼
   links, group_blocks, milestone_views, views_fields
   (all consume group-context tokens)

Editing flow

  1. Read the relevant per-model page below for context and known gotchas.
  2. Open the modeler at /admin/config/workflow/eca on a dev environment.
  3. Make the change in the modeler. For visual edits, use the modeler's drag-and-drop. For YAML-level tweaks (e.g. changing an event plugin's configuration), the modeler exposes form fields.
  4. Save the model in the modeler.
  5. Export config:
1
l3d ahoy fedms export-config
  1. Inspect the diff:
1
2
cd web/modules/contrib/fedms_eca
l3d git diff
  1. Commit and push in the fedms_eca repo.

Custom plugins used

Several models rely on custom ECA plugins implemented in fedms_task:

Plugin Used by
fedms_task_pattern_condition (event plugin) task_api
fedms_task_pattern_condition_arguments (event plugin) task_api
fedms_task_create_task_from_pattern (action plugin) task_api

When extending a model, prefer adding a new condition plugin in PHP rather than packing logic into the YAML.

The model files contain a hash

Each model file has a third_party_settings.modeler_api.data field that holds a SHA-256 hash of the modeler's serialized form of the model. Hand-edits desync the hash. The modeler regenerates it on every save — that's the right way to update it.

Disabling a model

If a model breaks the site, disable it temporarily:

1
2
l3d drush config:set eca.eca.<model> status 0
l3d drush cr

…fix the model, then re-enable.

For nuclear-level disable, set $settings['eca_disable'] = TRUE; in settings.php.

The per-model pages

Next steps