Using negative permissions, this role prevents a user's ability tocreate & delete a workspace within a given organization.Workspaces are uniquely owned by an org and a user, so the org has tosupercede the user permission with a negative permission.# Use caseOrganizations must be able to restrict a member's ability to create aworkspace. This permission is implicitly granted (see#16546 (comment)).To revoke this permission, the solution chosen was to use negativepermissions in a built in role called `WorkspaceCreationBan`.# RationalUsing negative permissions is new territory, and not ideal. However,workspaces are in a unique position.Workspaces have 2 owners. The organization and the user. To preventusers from creating a workspace in another organization, an [impliednegativepermission](https://github.com/coder/coder/blob/36d9f5ddb3d98029fee07d004709e1e51022e979/coderd/rbac/policy.rego#L172-L192)is used. So the truth table looks like: _how to read this table[here](https://github.com/coder/coder/blob/36d9f5ddb3d98029fee07d004709e1e51022e979/coderd/rbac/README.md#roles)_| Role (example)  | Site | Org  | User | Result ||-----------------|------|------|------|--------|| non-org-member  | \_   | N    | YN\_ | N      || user            | \_   | \_   | Y    | Y      || WorkspaceBan    | \_   | N    | Y    | Y      || unauthenticated | \_   | \_   | \_   | N      |This new role, `WorkspaceCreationBan` is the same truth table conditionas if the user was not a member of the organization (when doing aworkspace create/delete). So this behavior **is not entirely new**.<details><summary>How to do it without a negative permission</summary>The alternate approach would be to remove the implied permission, andgrant it via and organization role. However this would add new behaviorthat an organizational role has the ability to grant a user permissionson their own resources?It does not make sense for an org role to prevent user from changingtheir profile information for example. So the only option is to create anew truth table column for resources that are owned by both anorganization and a user.| Role (example)  | Site | Org  |User+Org| User | Result ||-----------------|------|------|--------|------|--------|| non-org-member  | \_   | N    |  \_    | \_   | N      || user            | \_   | \_   |  \_    | \_   | N      || WorkspaceAllow  | \_   | \_   |   Y    | \_   | Y      || unauthenticated | \_   | \_   |  \_    | \_   | N      |Now a user has no opinion on if they can create a workspace, which feelsa little wrong. A user should have the authority over what is theres.There is fundamental _philosophical_ question of "Who does a workspacebelong to?". The user has some set of autonomy, yet it is theorganization that controls it's existence. A head scratcher 🤔</details>## Will we need more negative built in roles?There are few resources that have shared ownership. Only`ResourceOrganizationMember` and `ResourceGroupMember`. Since negativepermissions is intended to revoke access to a shared resource, then**no.** **This is the only one we need**.Classic resources like `ResourceTemplate` are entirely controlled by theOrganization permissions. And resources entirely in the user control(like user profile) are only controlled by `User` permissions.![Uploading Screenshot 2025-02-26 at 22.26.52.png…]()---------Co-authored-by: Jaayden Halko <jaayden.halko@gmail.com>Co-authored-by: ケイラ <mckayla@hey.com>