Skip to content

Tasks and milestones

Tasks are the operational heart of FedMS. Every responsibility — every "someone needs to do something by some time" — is captured as a fedms_task content entity, attached to a group, assigned to a user, and grouped under a milestone.

What a task looks like

A fedms_task content entity has the following fields:

Field Purpose
label The human-readable title of the task ("Read pre-workshop briefing").
status Completed flag — FALSE while open, TRUE once done.
assignee The user responsible for the task. Required.
group The org, event, or session this task lives in. Required.
milestone A fedms_task_milestone taxonomy term that groups related tasks. Required.
pattern The fedms_task_pattern from which this task was spawned. Optional.
actionable Timestamp from which the task becomes actionable.
due Timestamp by which the task should be completed.
attachment / media / node / user / webform / webform_submission The polymorphic target entity — the thing the user needs to engage with.
uid The author of the task record (usually the system).

Tasks are revisionable: every state change creates a revision, so the history is preserved.

Milestones

A milestone is a taxonomy term in the fedms_task_milestone vocabulary. Milestones group related tasks so the user sees a coherent list rather than a flat soup.

Typical milestones for a workshop event:

  • Before the workshop — pre-reads, registrations, briefings.
  • During the workshop — engagement, attendance confirmation.
  • After the workshop — feedback, certificates, follow-ups.

The exact set of milestones is customer-configurable. Each customer defines the milestones that match their domain.

Implementation note. Milestones are referenced from task patterns by UUID, not by ID, so they can be safely synchronized between instances and across config exports. See fedms_task.module for the resolver.

Polymorphic targets

A task always points at one target entity that represents "what to do". The supported target types and their typical completion semantics are:

Target type Typical task Completion trigger
node "Read the joining instructions" View the node.
node "Create content page X" Publish the node.
media "Watch the recording" (Planned) Track playback.
media "Download the handout" Download.
fedms_attachment "Engage with the packaged artifact" Depends on attachment type.
webform "Fill in the feedback form" Submit a submission (linked to the task).
webform_submission "Review the submitted form" Manually mark complete (TBC).
user (Rarely) "Approve this user" Manually mark complete.

The full list of completion variants is being formalized at fedms/components/tasks#5.

Where tasks come from

The vast majority of tasks are spawned automatically by the task_api ECA model when:

  • a user is added to a group (org / event / session),
  • a group's field_flag_start_processed flips (start of the window),
  • a group's field_flag_end_processed flips (end of the window),
  • a successor task fires after its predecessor is completed,
  • cron triggers a periodic re-evaluation.

Each spawning is governed by a task pattern.

A small number of tasks may be created manually — for ad-hoc responsibilities that don't fit any pattern.

How a task gets actioned

From the assignee's perspective:

  1. The task appears on the user's dashboard once actionable ≤ now.
  2. The task is grouped under its milestone in the dashboard.
  3. The user clicks through to the target entity (the page, the webform, the recording).
  4. They perform the action.
  5. FedMS detects the action and marks the task complete (status = TRUE).
  6. The task disappears from "open tasks" but remains in the audit trail.
  7. Any successor task patterns registered for the completed pattern are evaluated and spawn the next round of tasks.

When membership changes

Membership changes affect tasks:

  • When a user is added to a group, applicable task patterns spawn tasks for them.
  • When a user is removed from a group, their open tasks are hidden (not deleted — the audit trail stays intact). See fedms/components/tasks#11.
  • When a user is re-activated (the soft-delete is undone), their hidden tasks reappear.

Successor chains

A task pattern can declare one or more successors — patterns that should be evaluated after this task is completed. This is how FedMS encodes workflows like:

1
2
3
"Submit slides"   completed  →  spawn  "Review slides"
"Review slides"   completed  →  spawn  "Approve slides"
"Approve slides"  completed  →  spawn  "Publish slides to delegates"

Successors form chains, not graphs. Avoid creating cycles — there is no cycle-breaker, and a cycle will loop forever.

The successor mechanism is tracked and refined at fedms/components/tasks#15 and fedms/components/tasks#25.

The MTW — Milestone Task Widget

FedMS provides a configurable widget that renders, for a given event/session, all the open tasks grouped by milestone — the Milestone Task Widget. This is the standard component for showing "what's left to do" on an event's overview page.

The MTW is being formalized at fedms/components/tasks#28.

Anti-patterns

Things you should not do with tasks:

  • Do not hand-create tasks for situations that should be a pattern. If five Managers will need this task for every event of type X, define a pattern.
  • Do not point at a target entity that does not exist yet — the pattern won't fire until the referencing entity exists.
  • Do not mark a task complete from a different user without changing the assignee — it breaks the audit trail.
  • Do not create cycles in successor chains.

Next steps