Skip to content

Content and attachments

Most of what people do on a FedMS instance is interact with content: read briefings, watch recordings, fill in webforms, download materials, write notes. This page describes the content types FedMS uses, and how attachments fit into the picture.

The content layers

A FedMS instance has four overlapping layers of content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
┌──────────────────────────────────────────────────────────────────┐
│                                                                  │
│  Editorial entities    fedms_event, fedms_session                │
│  (the prose body of    Composed of paragraphs:                   │
│  events and sessions)    - text       - view                     │
│                          - media      - webform                  │
│                                                                  │
│  Group content         Drupal nodes attached to groups:          │
│                          - book pages   - basic pages            │
│                        Media items attached to groups:            │
│                          - image, video, audio, document, …     │
│                                                                  │
│  Attachments           fedms_attachment entities:                │
│                        Wrappers around media / webforms that    │
│                        can carry their own task patterns.       │
│                                                                  │
│  Tasks                 fedms_task entities pointing at any of    │
│                        the above.                                │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Editorial entities — events and sessions

The fedms_event and fedms_session content entities carry the prose content of an event or session: a description, embedded media, embedded views (e.g. "all sessions of this event"), and embedded webforms.

The body is a paragraph field (entity_reference_revisions) that accepts four built-in paragraph types:

Paragraph type What it does
text Rich-text content (CKEditor 5).
media Embedded media entity (image, video, document, …).
view Embedded view (e.g. a list of related sessions).
webform Embedded webform — submission stays in the event/session context.

Content Managers can add more paragraph types in their own modules.

The exact set of paragraph types per event/session type is configurable.

Group content — books and pages

In addition to the editorial entities, an event or session group can have group content attached to it directly:

  • Book pages (group_node:book) — used for structured, multi-page content like "Joining Instructions" or "Course Handbook".
  • Basic pages (group_node:page) — used for single-page content.
  • Media items of every type — image, video, audio, document, PDF, remote video, vector image.

Group content respects group permissions: only members of the group can see the content unless permissions are explicitly relaxed.

Books are particularly useful because they can:

  • have a hierarchical structure (parent / child pages),
  • be referenced from a task pattern so that "read the joining instructions" becomes an automatic task,
  • be cloned with their event when an event is cloned to another org.

Attachments

The fedms_attachment content entity is a wrapper around content artifacts that need to be attached to an event or session, and that may carry their own task patterns.

Why a separate entity? Because you sometimes need to attach the same artifact (a recording, a signed form, a survey) to an event or session plus spawn a follow-up task ("watch this recording", "sign this form"). Wrapping the artifact in an attachment entity gives you a place to attach the task patterns and metadata.

Attachment fields

Field Purpose
label Display name.
description Paragraph field (same as events/sessions).
group The event or session this attachment belongs to.
assignee One or more users responsible for this attachment.
visibility private (assignees only), group (group members), public.
field_video Video field (used by the recipe attachment_recording).
fedms_task_patterns Task patterns that should spawn from this attachment.

Attachment types

fedms_attachment_type is the bundle config entity for attachments. Customers can define their own types — for example:

  • "Recording"
  • "Signed consent form"
  • "Pre-read pack"
  • "Survey response"

Out of the box, FedMS ships one attachment type: default.

How tasks link to content

A task is created from a task pattern. Every task points to one content entity that represents "what to do":

  • Point at a book page for "read this".
  • Point at a media item for "watch this video" or "review this document".
  • Point at a webform for "fill in this form".
  • Point at a webform submission for "review this submitted form".
  • Point at an attachment for "engage with this packaged artifact".
  • Point at a user for assignee-based tasks (rare).

When the user completes the corresponding action (views the page, downloads the file, submits the webform), the task is marked complete automatically.

The variations of how each entity type counts as "completed" are tracked at fedms/components/tasks#5.

Multilingual content

Both fedms_event and fedms_session are translatable. Out of the box, FedMS ships English (en) and German (de) translations of the framework's labels and messages. Customers can add more languages via the fedms_locale module's tooling.

See the Localization module page for how to extract and import translations.

Webforms

Webforms are first-class citizens in FedMS:

  • They can be embedded in events, sessions, and attachments via the webform paragraph type.
  • They can be referenced from task patterns to spawn "fill in this webform" tasks.
  • They can sync their fields back to existing entities (users, nodes, …) via the Webform Content Creator module.

When a webform task is created, FedMS will create an empty draft submission to make the task/submission relationship unambiguous (see fedms/components/tasks#20). This avoids the "which session did the user fill in feedback for" problem when the same form appears in multiple sessions.

Next steps