Skip to content

Conversation

@geokat
Copy link
Contributor

@geokat geokat commented Dec 22, 2025

Part of a series (2 stacked PRs) that closes coder/internal#1073

  • PR 1/2
  • PR 2/2 (this one)

Adds a per-organization setting to disable workspace sharing. When enabled,
all existing workspace ACLs in the organization are cleared and workspace
sharing API endpoints return 403 Forbidden.

This complements the existing site-wide --disable-workspace-sharing flag by
providing more granular control at the organization level.

Changes

  • New API endpoints for organization workspace sharing settings:
    • GET /organizations/{org}/settings/workspace-sharing
    • PATCH /organizations/{org}/settings/workspace-sharing
  • CLI commands: coder organizations settings show workspace-sharing
    and coder organizations settings set workspace-sharing
  • When sharing is disabled for an organization:
    • All existing workspace ACLs are cleared (DeleteWorkspaceACLsByOrganization)
    • ACL endpoints (GET/PATCH/DELETE /workspaces/{id}/acl) return 403 Forbidden
    • The org-member role is reconciled to remove sharing permissions
  • Audit logging for settings changes

Implementation notes

  • Considered organization edit --disable-workspace-sharing but chose the settings
    endpoint pattern for extensibility (e.g., future settings like default share level, allowed
    share levels)
  • The setting is stored on the organizations table as workspace_sharing_disabled
  • Disabling sharing is a destructive operation that removes all existing ACL entries
  • Re-enabling sharing does not restore previously cleared ACLs

@geokat
Copy link
Contributor Author

geokat commented Dec 22, 2025

  • New API endpoints for organization workspace sharing settings:
    • GET /organizations/{org}/settings/workspace-sharing
    • PATCH /organizations/{org}/settings/workspace-sharing
  • CLI commands: coder organizations settings show workspace-sharing
    and coder organizations settings set workspace-sharing

Now I'm not sure if we want to expose sharing_disabled as a workspace-sharing setting like I did here or as organization edit --workspace-sharing-disabled=true (which would require creating a whole new organization edit sub-command), or maybe some other way.

It's a UX question but maybe also an authz one: as a setting (the former case) it could be easily guarded with a separate RBAC resource type if necessary (e.g. ResourceWorkspaceSharingSettings) whereas as an organization property (the latter) it would fall under ActionUpdate on ResourceOrganization?

@aslilac
Copy link
Member

aslilac commented Dec 22, 2025

just as a heads up, we usually try to limit prs to about +500 lines. a little bit bigger is fine, but this is significantly over the usual limit, which will make it much harder for us to review quickly/effectively.

@geokat geokat changed the base branch from main to geokat/internal-1073-make-org-member-role-customizable-per-org December 22, 2025 23:47
@geokat
Copy link
Contributor Author

geokat commented Dec 22, 2025

just as a heads up, we usually try to limit prs to about +500 lines. a little bit bigger is fine, but this is significantly over the usual limit, which will make it much harder for us to review quickly/effectively.

My bad, I should have used #21359 as the base branch because these two are stacked. Fixed.

@geokat geokat force-pushed the geokat/internal-1073-implement-option-to-disable-workspace-sharing-per-org branch from 235a287 to 0286e78 Compare December 23, 2025 07:30
ctx := r.Context()
org := httpmw.OrganizationParam(r)

// TODO(geokat): Do we need an rbac.ResourceWorkspaceSharingSettings?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, the check that you've put here is correct. it's an organization attribute.

}

err := api.Database.InTx(func(tx database.Store) error {
//nolint:gocritic // We need to manage a system role.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isn't an actual explanation, this is just a generic "linter please be quite" explanation. what specific permission are we using that needs a system role? why is the user who initiated the request allowed to invoke this action even when they don't have the appropriate permission?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement organization "disable workspace sharing" option

3 participants