Skip to content

Sessions

A session is a sub-unit of an event. The granularity varies by event type:

  • For a one-day workshop, the event may have a single session that represents the workshop itself.
  • For a multi-day program, each day may be a session.
  • For a coaching series, each call may be a session.
  • For a conference, each talk or track may be a session.

The point of separating sessions from events is that the people, the time window, and the content of each session are often different from the event as a whole, even though sessions inherit context from their parent event.

Two entities, one session

Like events, sessions exist as a pair of linked entities:

Entity Type Purpose
Session group group (bundle session) Structure, members, content attached at session level, permissions.
Session content fedms_session (bundle = the session type) Editorial body.

A session group is always a sub-group of an event group, enforced by the Drupal subgroup module.

The session group

The session group fields mirror those of an event group, with some session-specific additions:

Field Purpose
label The display name of the session.
field_date Smart-date window — start and end timestamps.
field_venue Venue (often different from the parent event's venue).
field_accommodations Accommodation info.
field_description Short description (paragraphs).
field_session_profile Reference to a reusable session profile (planned).
field_flag_start_processed Cron-driven flag: has the session-start hook fired yet?
field_flag_end_processed Cron-driven flag: has the session-end hook fired yet?
field_sync Federation sync marker (intended).

The session content entity

The fedms_session content entity carries the editorial content of the session. It supports the same four built-in paragraph types as events (media, text, view, webform), plus any custom paragraph types the customer defines.

Out of the box, FedMS ships one session bundle: in. Customers typically create their own bundles to model their session types.

Session types

A session type is a fedms_session_type config entity. Each corresponds to a bundle of the fedms_session content entity.

Session types let a customer model the variety of session formats in their portfolio:

  • "Lecture"
  • "Workshop"
  • "Coaching call"
  • "Roundtable"
  • "Q&A"

Each type can have its own fields, view modes, and task patterns.

Session types are managed at /admin/structure/fedms_session_types by users with the Content Manager site role.

The membership constraint

Sessions have one load-bearing constraint that is enforced server-side:

A session member must be a member of the parent event.

When you add a member to a session, the user picker only offers users who are already members of the parent event. This is enforced by fedms_federation::EntityHooks::queryEntityReferenceAlter. It is deliberate, and it should not be bypassed.

Reasons:

  1. Auditability. It guarantees that anyone who participated in a session can be traced back to a deliberate event-level invitation.
  2. Privacy. It prevents session-level over-sharing — a Speaker on a single session never sees the entire event attendee list unless they are also an event member.
  3. Federation. It keeps the session membership a clean subset of the event membership, which is what gets federated.

The Allow session/event member sync feature lets Managers copy event members into a session in one click — without violating the constraint.

Session lifecycle

Sessions have the same lifecycle flags as events:

  • field_flag_start_processed — flips when the session start window has passed and the lifecycle-bound tasks have spawned.
  • field_flag_end_processed — flips when the session end window has passed and the post-session tasks have spawned.

Both flags are driven by cron via views.view.groups_unprocessed and the task_api ECA model.

What a session is not

  • A session is not a calendar entry. It is the unit of work within an event.
  • A session is not a sub-event. Sub-events would be a separate level of nesting; FedMS currently does not support them.
  • A session is not a topic — it is a delivery. If you want to reuse the same content across many deliveries, model the content as a separate book and reference it from each session.

Next steps