Skip to content

Event types

An event type (fedms_event_type config entity) is a bundle of the fedms_event content entity. Defining event types is how a Content Manager models the different kinds of engagement an organization runs.

Why event types matter

Every event you create has a type. The type decides:

  • Which fields the event has (a "Workshop" might have field_target_audience; a "Conference track" might have field_chair).
  • Which paragraph types the description supports.
  • Which view modes are available.
  • Which task patterns apply to events of this type.

Without a well-designed set of event types, you end up either with a single bloated type that has every field "just in case" or with too many types that drift apart. The right granularity is usually 3–7 types for most organizations.

Where to manage event types

1
/admin/structure/fedms_event_types

You need the Content Manager site role to manage event types.

Creating an event type

  1. /admin/structure/fedms_event_types/add
  2. Give it a label ("One-day workshop") and a machine name (one_day_workshop).
  3. Save.

On save, FedMS creates the bundle. You can now add fields to it.

Adding fields

From the event type edit page:

  1. Manage fields → Add field.
  2. Pick a field type — text, taxonomy reference, entity reference, media reference, smart-date, color, address, telephone…
  3. Configure storage (cardinality, allowed values) and the field instance (label, help text, default, required).
  4. Save.

The field is now part of every event of this type.

Common fields per type

For a typical training event type:

Field Type
field_target_audience Text or taxonomy
field_level Taxonomy (beginner / intermediate / advanced)
field_language Language reference
field_max_attendees Integer
field_certificate_template Entity reference (media or node)

Configuring form and view displays

  • Manage form display — controls the field order, widget choice (e.g. autocomplete vs. select), and field grouping in the event-edit form.
  • Manage display — controls the rendering on the event page. Each event type can have multiple view modes (default, profile, etc.).

Use field_group to organize fields into vertical tabs or details elements — important for usability when an event type has many fields.

Conditional fields

There is an open request for conditional fields (showing field X only when field Y is selected) — see fedms/support#50. For now, you can achieve a similar UX with field-group visibility rules, but native conditional fields are coming.

Task patterns per event type

Many task patterns are bundle-specific — e.g. "Send joining instructions" applies to "Workshop" but not to "Coaching call". When you create a task pattern, you specify which event types it applies to using the fedms_task_pattern_check_event_type condition. See Task patterns.

Best practices

  • Start small. Begin with the smallest set of event types that cover your real workflows. Add more only when you see clear duplication of fields-with-different-meaning between types.
  • Avoid duplication. If two types share 80% of their fields, ask whether they should be one type with a discriminator field.
  • Name from the user's perspective. Use names your Managers recognize ("Open enrollment workshop"), not internal jargon ("OEW-A").
  • Document the field meanings. Add field descriptions generously — the next Content Manager will thank you.

Cloning event types

Drupal does not have a built-in "clone bundle" feature. To duplicate an event type:

  1. Export config: l3d drush config:export.
  2. Copy the relevant YAML files (fedms_content.fedms_event_type.X.yml, field.field.fedms_event.X.*.yml, core.entity_form_display.fedms_event.X.*.yml, core.entity_view_display.fedms_event.X.*.yml).
  3. Search-and-replace the machine name in the copies.
  4. Import.

Next steps