[Story] FEAT-USER-GROUPS-14: Visibility Baseline (membership not exposed to non-members)

[sven1103-agent]

Parent Feature

#1558

User Story

As a user, I want to be sure that group membership information is never visible to people outside
the group, so that I keep control over who can see who is in which team.

Acceptance Criteria

• Given a group exists, When a non-member (no project access-administration, no admin role) views
  the group directory, project cards, Project Access page, or any other surface, Then they never
  see the member list, member counts, or any signal of a specific user's membership.
• Given a project access-administration holder or QBiC admin views a shared group, When they are
  not members themselves, Then they see the member list only in the context governed by
  admin/access-administration (per strategy §5.1); on READ-only surfaces they see group
  name+description only.
• Given I am a member of a group, When I view that group, Then I see the member list and counts;
  when I view a different group I am not a member of, I do not.
• Given the DPA (data processing agreement), When a user is informed beforehand, Then
  ORCID/username/full-name visibility to other users is disclosed as required; group names remain
  public.

Requirement IDs: GROUP-R-09, GROUP-NFR-03

---

Proposed requirement IDs (draft, for the requirements PR)

These IDs are proposals — they must be written into docs/requirements.md under a new GROUP
domain in a dedicated, human-approved requirements PR (AGENTS.md §0/§12, strategy §6). Classify
constraints (GROUP-C-*) separately; constraint IDs must not be referenced by stories.

Functional

ID	Statement
GROUP-R-01	QBiC admins can create and manage org groups (unique name case-insensitive, description, membership, manager assignment).
GROUP-R-02	Users can create ad-hoc groups self-service; creator becomes OWNER; empty ad-hoc groups auto-dissolve.
GROUP-R-03	Group OWNER/MANAGER can add/remove MEMBERs; MANAGER can rename/describe; MEMBER can self-remove.
GROUP-R-04	When a manager leaves an ad-hoc group such that it would be left without governance, the group offers a guarded transfer-or-dissolve choice.
GROUP-R-05	Users can discover groups by public name/description and see their own membership and role.
GROUP-R-06	Users with project change-access can share a group onto a project at READ/WRITE/ADMIN (never OWNER); members gain access at the next authorization check.
GROUP-R-07	Effective project access is the maximal of direct grants, group grants, and system roles.
GROUP-R-08	Project access-administration holders can list, change, and revoke group grants on a project.
GROUP-R-09	Group names/descriptions are public; member lists and counts are visible only to group members, project access-administration holders, and QBiC admins; membership is never exposed to non-members.
GROUP-R-10	Notification profile: newly-gained-access emails (deduplicated), join digest, revocation email, dissolution email, project owner/admin information on membership changes; role-level changes are audit-log-only.
GROUP-R-11	Project overview cards show the group names a project is shared with.
GROUP-R-12	QBiC admins can administer org groups (CRUD, membership, oversight) and have read-only oversight of ad-hoc groups.

Non-functional

ID	Statement
GROUP-NFR-01	When a user's group membership or a group's project grant is revoked, the change must take effect at the next authorization decision for the affected user, with a maximum observed propagation delay of 60 seconds across all deployed instances. (PO-confirmed, strategy §4.6.)
GROUP-NFR-02	Group names must be unique case-insensitively.
GROUP-NFR-03	Revoking/dissolving a group must not leave orphaned GROUP_<id> ACE entries or membership rows.

---

Pending decisions / open items (do not create stories for these yet)

• Group size limits / group count limits per user (strategy §8).
• Manager demotion path (§8) — story 02 and 04 cover assignment; explicit demotion is deferred.
• Whether org groups pre-seed with any project grants at rollout (§8).
• Audit-trail: strategy §3/§5.2 says "audit events for every group operation" — a dedicated
  FEAT-USER-GROUPS-15 — Audit Group Operations story should be created if the PO wants explicit
  user-visible audit coverage (not created here to avoid inventing scope).

---

Last updated: 2026-09-21

---

Tracking

• Epic: EPIC 6 — Revocation & security
• Stable Story ID: FEAT-USER-GROUPS-14
• Source: docs/features/FEAT-USER-GROUPS-stories.md — PO-approved (2026-09-22)