Is there an existing issue for this?
Summary
After an admin removes someone from a project (or workspace), that user should not be able to get access back by clicking Join on a public project. Access should return only when an admin explicitly adds or invites them again. Today, remove only sets is_active=false, and the self-join API can reactivate the same membership without an invite.
Why should this be worked on?
Admins expect “Remove member” to revoke access until they allow it again. On public projects, removed members can rejoin immediately via POST /api/users/me/workspaces/<slug>/projects/invitations/, which reactivates the inactive row. That makes member removal ineffective for common public-project setups and creates a security/UX gap: remove looks permanent in the UI, but access can be restored without admin action. Distinguishing admin-revoked membership from voluntary leave (e.g. an access_revoked flag) fixes this while still allowing public rejoin after someone leaves on their own, and invite/add flows remain the path to restore access.
Is there an existing issue for this?
Summary
After an admin removes someone from a project (or workspace), that user should not be able to get access back by clicking Join on a public project. Access should return only when an admin explicitly adds or invites them again. Today, remove only sets
is_active=false, and the self-join API can reactivate the same membership without an invite.Why should this be worked on?
Admins expect “Remove member” to revoke access until they allow it again. On public projects, removed members can rejoin immediately via
POST /api/users/me/workspaces/<slug>/projects/invitations/, which reactivates the inactive row. That makes member removal ineffective for common public-project setups and creates a security/UX gap: remove looks permanent in the UI, but access can be restored without admin action. Distinguishing admin-revoked membership from voluntary leave (e.g. anaccess_revokedflag) fixes this while still allowing public rejoin after someone leaves on their own, and invite/add flows remain the path to restore access.