Group settings: visibility + join policy, with enforcement
Problem / Motivation
“Manage Group Settings” is Must Have, including visibility and the ability to join; join flow must set approval expectations.
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
Add/confirm Group settings: Visibility (public/unlisted/private) and Join policy (open vs request-to-join) as fields on the group entity. Enforcement is via Group access + group permissions consistently across:
- Directory (respects visibility — Group access filters the listing),
- Group page (respects visibility — Group access policy gates the canonical route),
- Join action (open → immediate membership relationship; request → pending status + organizer approval).
Acceptance criteria
- Organizers can edit settings.
- Changing join policy changes join behavior immediately.
- Private Groups are not joinable without appropriate access; visibility rules enforced consistently everywhere.
Pipeline
Suggested review-rigor: panel — enforcement spans multiple surfaces; a missed check is a real access defect.
UI surface: Group settings form (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.
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.