Skip to content

fedms_eca

The fedms_eca module ships the ten ECA models that encode FedMS' business logic. It does not contain much PHP — its value is in its config (config/optional/eca.eca.*.yml) and in the conventions those models embody.

GitLab

fedms/components/eca

What it ships

Ten ECA models in config/optional/:

Model Heart of … Reference page
event_groups Event-group lifecycle reactions event_groups
group_blocks Group-context block rendering group_blocks
group_members Membership add/remove/re-activate group_members
group_operations Operations menu / VBO, group-context tokens group_operations
links Contextual link manipulation links
milestone_views Milestone taxonomy in Views milestone_views
session_groups Session-group lifecycle reactions session_groups
task_api Task spawning engine ⭐ task_api
users User automations users
views_fields Computed/derived fields for Views views_fields

For an overview and the model-editing workflow, see ECA models.

Module dependencies

A long list (fedms_eca.info.yml):

  • All the eca_* core sub-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.
  • ECA contrib add-ons: eca_entity_print, eca_group, eca_tamper, eca_vbo, eca_webform.
  • easy_email — for the email actions used by the upcoming notification flows.
  • entity_print:entity_print_views — view-based PDF export.
  • fedms_task — the conditions and actions used by task_api.
  • group_action — VBO-style group actions.
  • modeler:modeler and modeler_api:modeler_api — the modeler framework.
  • symfony_mailer_lite — outbound mail.
  • token — token replacement.

Where the models are edited

Two paths:

  1. The modeler — /admin/config/workflow/eca — interactive, visual editing. The current modeler is bpmn_io; a successor is coming.
  2. Directly in YAML — discouraged. The modeler regenerates the data hash and the node IDs; hand-edits get overwritten on the next save through the UI.

The model-editing workflow

  1. Read the per-model doc (this page links to each).
  2. Read the ECA guide for the events/conditions/actions vocabulary.
  3. Open /admin/config/workflow/eca in the local dev environment on a clean install.
  4. Make your changes in the modeler.
  5. Save the model.
  6. From the site root, run:
1
l3d ahoy fedms export-config
  1. cd web/modules/contrib/fedms_eca and inspect the diff:
1
l3d git diff
  1. Commit and push, then open an MR.

Custom plugins

When an ECA-model change requires a new condition / action / event plugin that doesn't exist yet, implement the plugin first in PHP in the appropriate module (fedms_task, fedms_federation, etc.), then reference it from the model.

Plugins live under src/Plugin/ECA/{Condition,Action,Event}/ per module.

Don't hand-edit eca.eca.*.yml

The model YAML files contain a data: field with a SHA-256 hash that the modeler maintains. Hand-edits desync the hash and can silently break the model. Always go through the modeler and re-export.

The exception is mechanical edits like search-and-replace of deprecated condition IDs — those are safe.

Mass-disabling models

If a model breaks the site, you can disable it without uninstalling:

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

Or set $settings['eca_disable'] = TRUE; in settings.php to disable the entire ECA engine at the framework level. Fix the model, then re-enable.

Future direction

  • The modeler is being replaced. The replacement should be drop-in for the data model but with a cleaner UX. Don't write tooling that hard-codes BPMN.io specifics.
  • The model list will likely grow (notifications, federation transport) and split (fedms/components/eca#8 Break up ECA models into smaller ones).
  • The condition-plugin set in fedms_task will grow as new patterns emerge.

Next steps