chore: scope workspace quotas to organizations #14352
Conversation
Quotas are now a function of (user_id, organization_id). They are still sourced from groups. Deprecate the old api endpoint.
a8ff394 to
61ed7e1
Compare
| apiKeyMiddleware, | ||
| httpmw.ExtractOrganizationParam(api.Database), | ||
| // Intentionally using ExtractUser instead of ExtractMember. | ||
| // It is possible for a member to be removed from an org, in which |
There was a problem hiding this comment.
This is fine here, but longer term, is this behavior desirable to administrators? Is there a default dormancy behavior here or any mechanism to clean up these workspaces?
There was a problem hiding this comment.
It's desirable because the alternative is to forcibly terminate workspaces when a user is removed. A workspace should remain in case:
- Removing the user was an accident
- There is data in the workspace that is valuable before termination
I think we do have some dormant workspace behavior today to eventually delete this. Ideally there is some page of "orphaned" workspaces an admin could go through and clean these up.
But this PR does not address any of that. It just makes sure the quota api call still works in this case. Otherwise the /{workspace} page would fail to load because of this failed api call.
| // defer to the new endpoint using default org as the organization | ||
| chi.RouteContext(r.Context()).URLParams.Add("organization", defaultOrg.ID.String()) | ||
| mw := httpmw.ExtractOrganizationParam(api.Database) | ||
| mw(http.HandlerFunc(api.workspaceQuota)).ServeHTTP(rw, r) |
There was a problem hiding this comment.
Man I wish I could just rip this stuff out 😆
Quotas are now a function of (user_id, organization_id). They are still sourced from groups. Deprecate the old api endpoint.
Closes #14349