Skip to content

Task patterns

A task pattern is a template that tells FedMS:

"Whenever X happens, and the situation matches conditions A, B, C, spawn a task T for user U in group G, with these timestamps, pointing at this entity."

Task patterns are config entities (fedms_task_pattern). They are edited by Managers / Content Managers, exported to YAML, and version controlled like any other config.

The fields of a task pattern

Field What it does
id Machine name.
label Pattern label (for the admin UI).
taskLabel Template for the task label (supports tokens).
milestone UUID of the fedms_task_milestone term.
rule The ECA rule ID (in the task_api model) that this pattern is wired to.
conditions List of fedms_task_pattern_condition plugin IDs to evaluate.
conditionArguments Arguments per condition.
successors List of pattern IDs to evaluate after a task from this pattern completes.
actionableRelation Timestamp anchor: task created, session start, or session end.
actionableRelationDate DateTime::modify() string applied to the anchor (+3 days, -1 week, etc.).
dueRelation Same set, for the due timestamp.
dueRelationDate DateTime::modify() string for the due timestamp.

The anchor model

A task pattern defines when the resulting task is actionable and when it is due relative to one of three anchor moments:

Anchor Meaning
task created The moment the task is created.
session start The start_value of field_date on the group.
session end The end_value of field_date on the group.

For org-level patterns, the anchor is always "now" (org groups don't have a field_date).

The *RelationDate field is fed straight to PHP's DateTime::modify(), so any modifier string is accepted: +3 days, -1 week, -3 hours, next Monday, …

Example: "actionable now, due 7 days before session start" =

1
2
3
4
actionableRelation: 'task created'
actionableRelationDate: ''
dueRelation: 'session start'
dueRelationDate: '-7 days'

How patterns get attached to entities

A pattern alone doesn't fire — it has to be referenced from somewhere. There are three places a pattern can be referenced:

  1. From a node (book page, basic page) — via the fedms_task_patterns base field added to all nodes by fedms_task.module. This is how "reading this book page" becomes a task.
  2. From a media item — via the same fedms_task_patterns base field added to media. This is how "watching this video" becomes a task.
  3. From a fedms_attachment — via the fedms_task_patterns field on the attachment entity.
  4. From a webform — via a third-party setting (fedms.patterns_form) on the webform config entity.

The task_api ECA model walks all of these references when evaluating which tasks to spawn.

The conditions

Conditions narrow down "when this pattern applies". The available conditions are implemented as fedms_task_pattern_condition ECA event plugins in fedms_task/src/Plugin/ECA/Event/:

Condition plugin id (event-id) What it checks
fedms_task_pattern_is_event Is the affected group an event?
fedms_task_pattern_is_session Is the affected group a session?
fedms_task_pattern_check_event_type Does the event's bundle match the arguments?
fedms_task_pattern_check_session_type Does the session's bundle match the arguments?
fedms_task_pattern_check_user_role Does the user have the given group role?
fedms_task_pattern_check_user_org_group_role Does the user have a given role in the parent org?
fedms_task_pattern_check_user_event_group_role Does the user have a given role in the parent event?
fedms_task_pattern_check_user_session_group_role Same for sessions.

Conditions are AND-combined. Each takes arguments from conditionArguments[condition_id].

Customers can implement their own condition plugins by following the patterns in fedms_task/src/Plugin/ECA/Event/.

Successors — chaining patterns

Each pattern can declare successors[] — a list of pattern IDs to evaluate after a task from this pattern is completed.

This is how a workflow like

1
"Submit slides" → "Review slides" → "Approve slides" → "Publish"

is expressed: each predecessor pattern lists the next one as a successor.

Successors form chains, not graphs. A pattern can have multiple successors, but cycles are not detected, so don't create them.

How a task spawns from a pattern

When the task_api model fires:

  1. The model walks every enabled fedms_task_pattern.
  2. For each, it evaluates the conditions in conditions[] (with their conditionArguments[]) against the current event/group/user context.
  3. If all conditions pass, it computes:
  4. taskLabel (token-replaced),
  5. milestone (via UUID lookup),
  6. actionable and due timestamps via TaskPattern::getTimestamp().
  7. It looks up all entities that reference this pattern (the source nodes, media, attachments, webforms) and creates one task per referencing entity per applicable user.
  8. Duplicate detection: if an open task with the same (assignee, group, pattern, target_entity) already exists, no new task is created.

Anti-patterns

Things you should not do:

  • Don't create a pattern with no conditions on a high-traffic event — it will spawn unbounded tasks.
  • Don't modify a pattern's milestone UUID by hand without making sure the new term exists.
  • Don't create cycles in successors[].
  • Don't reference an entity from a pattern that the assignee can't access — the task will appear but be unactionable.

Where to author task patterns

Task patterns are managed at:

1
/admin/structure/fedms-task-pattern

— this is a config entity collection. Authoring requires the administer fedms_task_pattern permission.

The full authoring workflow is described in Admin guide → Task patterns.

Next steps