Skip to content

Task patterns (authoring)

A task pattern is the template from which tasks are spawned. The Concepts → Task patterns page describes what a pattern is; this page describes how to author patterns.

Where to author

1
/admin/structure/fedms-task-pattern

You need the administer fedms_task_pattern permission. By default this is granted to the Manager site role.

Step-by-step: a typical pattern

Let's create the pattern "Send joining instructions 7 days before the workshop".

1. Define the milestone first

The pattern needs a milestone to attach the task to. Milestones are taxonomy terms in the fedms_task_milestone vocabulary at:

1
/admin/structure/taxonomy/manage/fedms_task_milestone

Create a milestone "Before the workshop" if it doesn't exist.

2. Create the pattern

/admin/structure/fedms-task-pattern/add

Fill in:

Field Value
Label Send joining instructions
Machine name send_joining_instructions
Task label Send joining instructions to [user:display-name]
Milestone Before the workshop
Rule (pick the ECA rule that fires when a user is added to an event)

3. Conditions

For "this only applies to workshop-type events and to attendees":

  • Condition 1: fedms_task_pattern_check_event_type with arguments one_day_workshop, multi_day_workshop.
  • Condition 2: fedms_task_pattern_check_user_event_group_role with arguments attendee.

4. Timestamps

For "actionable now, due 7 days before the session starts":

  • Actionable relation: task created, no date modifier.
  • Due relation: session start, date modifier -7 days.

5. Successors

If completing this task should spawn a follow-up (e.g. "Confirm attendance"), list the successor pattern's machine name in successors.

6. Attach the pattern to content

The pattern only fires when something references it. For "Send joining instructions", the something is typically a book page or a media item that the user needs to view (or, in this case, the manager needs to dispatch).

Edit that node or media item → set its fedms_task_patterns field to include send_joining_instructions → save.

7. Save the pattern and verify

After saving the pattern, create a test event of one of the configured types and add a test attendee. The pattern should fire and create a task with the expected label, milestone, actionable date, and due date.

Anti-patterns

Things to avoid:

  • Patterns with no conditions on high-traffic event types — they spawn unbounded tasks.
  • Patterns referencing a milestone by UUID directly — always go through the picker.
  • Cycles in successors — there is no cycle-breaker.
  • Patterns that change the parent successor chain — e.g. don't set successors that depend on the order of evaluation.

Editing existing patterns

Patterns are config entities. Edits to a pattern do not retroactively affect existing tasks — they only change behavior for future spawning. If you need to "fix" already-spawned tasks, do it manually or via a one-off ECA model.

Disabling a pattern

Patterns have a status (enabled / disabled). A disabled pattern is ignored by the spawning engine but kept in config for audit.

There is a related request to be able to pause patterns per event: fedms/components/tasks#18.

Exporting patterns to config

Task patterns are part of the fedms_task module's config. Export with:

1
l3d ahoy fedms export-config

The exported YAML lives at: web/modules/contrib/fedms_task/config/install/fedms_task.fedms_task_pattern.<id>.yml.

Commit the file in the fedms/components/tasks repo.

How patterns interact with cron

Lifecycle-driven patterns (anything anchored to session start or session end) rely on cron to fire — cron walks views.view.groups_unprocessed and flips the field_flag_*_processed flags, which triggers the task_api model.

If cron is delayed, lifecycle tasks are delayed too. Make sure cron is running at a frequency that suits your event-window granularity (10-minute cron is a sensible default).

Next steps