Skip to content

Project membership status

Project owners and administrators can suspend a project member's access without deleting the membership. This preserves the member's project groups and an append-only record of every status change, so access can later be restored without losing audit context.

Behaviour

  • Active memberships retain their normal project and stage permissions.
  • Disabled memberships remain visible to authorised membership administrators, but no longer count as active membership for project listings, project authorization, stage authorization, direct stage-member grants, live project updates, or review work.
  • Disabling and enabling append a status-history entry containing the new status, the acting user, and a UTC timestamp. Repeating an already-applied command is idempotent and does not rewrite the history.
  • A disabled member cannot join again or accept another invitation. Their existing membership must be enabled instead. Disabled public memberships are excluded from the joinable Other Projects list even though they are no longer reported as active members.
  • Full-statistics and study-presence streams independently observe project membership revocation; clients need not subscribe to project details for their streams to stop. Disabled memberships cannot regain these streams by invoking the subscription methods again. This enforcement is unconditional for already-disabled memberships, including when the mutation feature flag is off. Before delivering data, each new stream checks persisted membership after its revocation listener is attached, so a stale initial hub context cannot restore disabled access.
  • Project owners, the acting user's own membership, and members who still hold the Administrator group cannot be disabled. Remove administrator privileges before disabling that member.
  • Disabled members cannot be assigned new project groups or become project owner.

Use the controls

  1. Open Project settings → Membership.
  2. Find an active, non-administrator member and select Disable membership.
  3. Review the access-loss warning and confirm. The member immediately loses project access.
  4. To restore access, select Enable membership and confirm. Their retained project groups apply again and the restoration is added to the history.

Only users with the project's Edit memberships permission can use these controls. Viewing an individual membership requires View memberships permission.

Rollout and rollback

The disableMembership feature flag is off by default. It gates only the disable action: when off, the Disable membership button is hidden and PUT .../investigators/{id}/disable is not selected (it returns the same 404 as a route that does not exist). Enable the flag first in an isolated preview, then staging, and verify disable → access loss → enable before any broader rollout.

Turning the flag off is the rollback: it stops new disables without deleting existing history or silently reactivating disabled memberships. Nobody is stranded by it. The Enable membership button (for members who are already disabled) and PUT .../investigators/{id}/enable stay available whatever the flag says, with the same Edit memberships authorization, so an administrator can always restore a member who was disabled while the flag was on. Disabled members stay refused everywhere while the flag is off, as before.

Switching the flag on → off → on round-trips with data made in either state: disable (on), enable (off), disable again (on) leaves three status-history entries. The API tests cover this (MembershipStatusFlagRoundTripTests). Production activation is a separate, explicit rollout decision.

Compatibility

Both schema-0 (Registrations) and schema-1 (Memberships) project documents persist the same status history. Older documents with no status field are treated as active; this avoids revoking existing access during deployment. Once a status change exists, its latest entry is authoritative.