Is there an existing issue for this?
Summary
Self-hosted instances currently have no token-authenticated, instance-admin way to deactivate (offboard) a user. God Mode covers it in the UI, but it is session-only, and REST API v1 has no user-lifecycle endpoints. Related requests (#8631, #8459 / PR #8059) address workspace/project membership, but not the user account itself — API tokens, web/device sessions, and login remain untouched by membership removal.
We run a self-hosted Community Edition instance (same team as plane-mcp-server PR makeplane/plane-mcp-server#137 and the recent comments on #8782) and have already built and battle-tested this for our own deployment. Before investing in a PR, we would like to ask the maintainers: would you accept an upstream contribution adding an official instance-admin user-deactivation API — and if so, in what shape?
What our implementation provides (happy to contribute or adapt any part of it):
- A synchronous find → deactivate → verify contract designed for automated offboarding platforms:
GET /users?email= (find), POST /users/{id}/deactivate (idempotent; already-inactive returns success), GET /users/{id} (verify).
- "Deactivate" covers the full access surface, not just the
is_active flag: revokes active API tokens, deactivates workspace and project memberships, sets an unusable password, and clears web sessions, device sessions, and social (OAuth) login connections as defence-in-depth.
- Deactivate-only by design: no create / delete / role-change / reactivate code paths; instance admins and bot accounts are refused; every call is audit-logged.
- The verify endpoint returns concrete counts (active tokens, memberships, sessions,
has_usable_password) so a caller can prove "access is gone" instead of trusting a flag.
Why should this be worked on?
Automated, auditable offboarding is a baseline compliance requirement (SOC 2 / ISO 27001 access-revocation controls). Most systems in a typical self-hosted stack — Google Workspace, GitLab, Gitea/Forgejo, Keycloak — expose an admin API to disable a user; Plane currently requires a manual God Mode click, which is neither automatable nor auditable. Anyone integrating Plane into an identity-lifecycle / joiner-mover-leaver pipeline hits this gap.
Questions for the maintainers (design-first, same approach as on #8782):
- Is an instance-admin user-deactivation API acceptable for the Community Edition, or is user lifecycle management intended to stay exclusive to paid editions?
- If acceptable, where should it live — the
instance (admin) app with its own auth, or REST API v1 under a new admin scope — and what auth model do you prefer for instance-admin API access?
- Would you like a short design proposal / RFC to review first, or a PR directly?
We are happy to contribute the implementation with tests and documentation, adapted to whatever conventions you prefer.
Is there an existing issue for this?
Summary
Self-hosted instances currently have no token-authenticated, instance-admin way to deactivate (offboard) a user. God Mode covers it in the UI, but it is session-only, and REST API v1 has no user-lifecycle endpoints. Related requests (#8631, #8459 / PR #8059) address workspace/project membership, but not the user account itself — API tokens, web/device sessions, and login remain untouched by membership removal.
We run a self-hosted Community Edition instance (same team as plane-mcp-server PR makeplane/plane-mcp-server#137 and the recent comments on #8782) and have already built and battle-tested this for our own deployment. Before investing in a PR, we would like to ask the maintainers: would you accept an upstream contribution adding an official instance-admin user-deactivation API — and if so, in what shape?
What our implementation provides (happy to contribute or adapt any part of it):
GET /users?email=(find),POST /users/{id}/deactivate(idempotent; already-inactive returns success),GET /users/{id}(verify).is_activeflag: revokes active API tokens, deactivates workspace and project memberships, sets an unusable password, and clears web sessions, device sessions, and social (OAuth) login connections as defence-in-depth.has_usable_password) so a caller can prove "access is gone" instead of trusting a flag.Why should this be worked on?
Automated, auditable offboarding is a baseline compliance requirement (SOC 2 / ISO 27001 access-revocation controls). Most systems in a typical self-hosted stack — Google Workspace, GitLab, Gitea/Forgejo, Keycloak — expose an admin API to disable a user; Plane currently requires a manual God Mode click, which is neither automatable nor auditable. Anyone integrating Plane into an identity-lifecycle / joiner-mover-leaver pipeline hits this gap.
Questions for the maintainers (design-first, same approach as on #8782):
instance(admin) app with its own auth, or REST API v1 under a new admin scope — and what auth model do you prefer for instance-admin API access?We are happy to contribute the implementation with tests and documentation, adapted to whatever conventions you prefer.