[feature]: Instance-admin API to deactivate (offboard) a user on self-hosted instances — willing to contribute

Is there an existing issue for this?

• I have searched the existing issues

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):

1. Is an instance-admin user-deactivation API acceptable for the Community Edition, or is user lifecycle management intended to stay exclusive to paid editions?
2. 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?
3. 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.

Begin with REST API v1 and the existing God Mode user-deactivation flow; the payload names no source files or tests to inspect. Clarify the accepted endpoint shape, admin authentication, and full access-revocation contract with maintainers before implementation; done would be an approved design plus tests and documentation for the agreed behavior.