Create Group content type and required fields (data model)

Problem / Motivation

The PRD requires a resilient, scalable data architecture for Groups, with core fields and support for multiple organizers/editors. This is the foundation every other MVP issue depends on.

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.

Proposed resolution

Create a Group type in the Group module (drupal/group) — a group entity bundle (e.g. community_group). Groups are group entities, not nodes; the fields below attach to the group entity:

  • title/label (Group name) — required
  • field_group_description — required (formatted text)
  • field_group_location — optional (see directory issue for taxonomy vs free text)
  • field_group_logo — optional (core Media image reference preferred)
  • field_group_type — optional taxonomy reference (vocabulary: Group type / topic)
  • field_group_organizers — dropped as the access driver. Organizers are a group role, not a user-reference field; edit access flows through the Group permission mechanism (see #3578781).
  • field_group_links — optional multi-value Link field (see Links & Resources issue)
  • field_group_primary_language — required (see multilingual issue)
  • field_group_visibility — select public/unlisted/private (see settings issue)
  • field_group_join_policy — select open/request (see settings issue)
  • field_group_archived — boolean or moderation state (see archiving issue)

Keep visibility as public/unlisted/private and join_policy as open/request (two independent axes — see #3578785). Set up view modes ("Teaser (directory)", "Full (group page)"), an organizer-friendly form display, and enable revisions (Group entities support revisions).

Acceptance criteria

  • Group content type exists with the fields above and appropriate validation.
  • A Group can be created and renders in Full view mode; Teaser has enough for the directory (name, location, language, type, logo).
  • Anonymous users can view a public Group (coordinate with the canonical-page issue).

Pipeline

Decision (2026-07-22, André): RESOLVED — build on the Group module (drupal/group). The Node-vs-custom-entity fork this issue previously held open is settled: groups are Group-module group entities. Remaining work is the concrete field/display setup on that foundation. Suggested review-rigor: panel — still security- and scale-sensitive (field storage on the group entity, display/access wiring); the panel gate now reviews the Group-based model rather than choosing the substrate. UI surface: the Group add/edit form + canonical display (Designer wireframe + UI walkthrough apply).

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.

Reference schema (now the chosen foundation)

A schema for the Group data model exists in the D11 Migration docs (imported via !28 (merged)): it uses the contrib drupal/group module with a community_group group type (derived from an Open Social → standard Drupal conversion). Following the 2026-07-22 decision to build on the Group module, this is the chosen foundation (specific field set and versions to be finalized in the panel review), not merely one option. See: Architecture Differences, Conversion Plan.

Edited by André Angelantoni