group_members ECA model

Source: eca.eca.group_members.yml

Purpose: Membership lifecycle for org, event, and session groups — add, update, remove, re-activate. Implements the soft-delete behavior by manipulating the status boolean on group_relationship (added by fedms_federation::EntityHooks::entityBaseFieldInfo).

This is the second-largest model in FedMS after task_api, with 163 plugins.

Events the model listens to

Plugin	Label
eca_endpoint:access	Access: confirm remove member
eca_endpoint:access	Access: re-activate member
eca_endpoint:access	Access: remove member
eca_endpoint:response	Response: confirm remove member
eca_endpoint:response	Response: remove member
eca_endpoint:response	Response: re-activate member
content_entity:update	Update event membership
content_entity:update	Update org membership
content_entity:update	Update session membership
form:form_build	Build form: re-activate members

Entities & contexts touched

• group_relationship (with the status base field added by fedms_federation)
• Three group bundles: org, event, session
• user

Why it exists

The FedMS UX requires:

1. Soft removal — a removed member can be re-activated without losing role/timeline metadata. The status flag is the soft-delete switch.
2. Cascading semantics — removing a member from an org may need to propagate (or explicitly NOT propagate) to events and sessions.
3. Access-controlled endpoints — the confirm-remove and re-activate actions are exposed via eca_endpoint.

Editing notes / gotchas

• The status field on group_relationship is the lever. Code that filters memberships should respect it. Don't filter on a different field.
• The federation hook queryEntityReferenceAlter excludes existing members from user pickers. This model makes sure that hook keeps working for re-activation flows too.
• The "Update org/event/session membership" branches share logic. If you fix a bug in one, audit the other two for symmetry.
• Confirmation flows must be wired through eca_endpoint, not through a custom controller — keep the model the single source of truth.

Related issues

• fedms/components/tasks#11 — Task rule when members are removed.
• fedms/components/tasks#21 — Ask for confirmation before removing member.
• fedms/support#62 — Removing a user from event doesn't remove from session.
• fedms/components/federation#12 — Batch assign users to a group.

See also

• fedms_federation/src/Hook/EntityHooks.php — the federation-side hooks this model coexists with.
• group_operations — exposes the user-facing operations.
• task_api — consumes membership changes to spawn / hide tasks.