Multi-organizer edit access via the Organizer group role

Updated 2026-07-22: foundation is the Group module (drupal/group) per André — group entities + group permission mechanism + customized Group membership relationship; OG still excluded.

Problem / Motivation

The PRD explicitly requires enabling multiple organizers to edit a Group's content.

Proposed resolution

Implement access control via the Group permission mechanism (drupal/group):

  • An Organizer group role carries the group permissions to edit the group and its content; any member holding that role can edit within the group.
  • Site admins (and the site-level Groups Moderate role, see #3578786) can always edit.
  • Members without the Organizer role, and non-members, cannot edit.

Drupal-specific

  • Access flows through Group's access policy + group roles — no user-reference field driving access, and no per-node role creation. The Organizer group role is the idiomatic mechanism here (a natural fit under the Group module, not a workaround).
  • Admin override stays; enforce through Group permissions rather than a custom hook_ENTITY_access() field check.

Acceptance criteria

  • A member holding the Organizer group role can edit the Group; a member without it, and a non-member, cannot.
  • Admin override works (site admin + Groups Moderate role).
  • Access checks cover edit form, canonical actions, and any API routes — all via Group permissions.

Pipeline

Suggested review-rigor: panel — access-control correctness is security-sensitive and a prime target for two-model review.

Source: DA-New Groups — MVP PRD (Google Doc). Target Drupal core version per the project's core-version decision (see #3578750).

Part of the MVP epic #3578778.


Proposed approach (reference — not yet decided)

A proposed approach for this exists in the D11 Migration docs (imported via !28 (merged)), reflecting an Open Social → standard Drupal conversion built on the contrib drupal/group module. Treat it as a reference proposal, not a decision — whether this project adopts that schema is still open (see the data-model decision in #3578779). See: Architecture Differences.

Edited by André Angelantoni