feat(enterprise/coderd): allow system users to be added to groups #18341
Conversation
…tem user so that they can configure quotas
There was a problem hiding this comment.
I'm wondering about this approach. Do we need to add IncludeSystem: true to all these queries just to support the prebuilds system user?
This means someone will need to manually create a group for the prebuilds user and assign it a quota, right?
Wouldn't it be more robust to automatically create a group for the prebuilds system user with a default quota, and allow users to override it if needed? That way, we avoid having to include system users in these queries and reduce the risk of system users leaking into user-facing features.
| -- Filter by system type | ||
| AND CASE | ||
| WHEN @include_system::bool THEN TRUE | ||
| ELSE | ||
| is_system = false | ||
| END |
There was a problem hiding this comment.
nit for readability:
| -- Filter by system type | |
| AND CASE | |
| WHEN @include_system::bool THEN TRUE | |
| ELSE | |
| is_system = false | |
| END | |
| -- Conditionally include system users based on @include_system flag | |
| AND (@include_system OR is_system = false) |
|
The prebuilds user has already leaked into user facing features. Administrators search for prebuilds by specifying the prebuilds user on the workspace list page. For consistency and clarity, I think we should embrace listing and showing the prebuilds user. I like the idea of automatically creating a prebuilds group, but we'll need to decide what a sensible default quota would be if there is such a value that makes sense. |
It’s true that the prebuilds user is already exposed in some user-facing features, like showing prebuilt workspaces, but that might not be the ideal approach 😕 The issue isn’t just about the prebuilds user, it extends to listing all current and future system users.
We already have a precedent with the coder/coderd/database/queries/groups.sql Lines 102 to 109 in 0cdcf89 We could apply the same pattern here: automatically create the prebuilds group with a default quota of 0, and clearly document this behavior along with instructions on how users can update the quota if needed. |
WalkthroughThis change updates the logic for retrieving organization and group members to consistently include system users, such as the prebuilds system user, by default. It introduces a new boolean parameter to control this behavior in both SQL queries and Go code, and updates related tests to expect the presence of system users in member lists. Changes
Sequence Diagram(s)sequenceDiagram
participant API
participant MembersService
participant Database
API->>MembersService: Request organization/group members
MembersService->>Database: Query members (IncludeSystem: true)
Database-->>MembersService: Return all members (including system users)
MembersService-->>API: Return member list with system users
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Could we also add a test case that verifies the behavior when the prebuilds quota is actually used? I'm curious about what QuotaAllowance: 0 means in practice, does this mean prebuild creation will always fail due to no quota, or does 0 represent unlimited/no enforcement?
It would be helpful to have a test that actually attempts to create prebuilds after the group is set up to clarify this behavior and ensure the default quota setting works as intended.
| _, err = s.store.InsertOrganizationMember(ctx, database.InsertOrganizationMemberParams{ | ||
| // Create a "prebuilds" group in the organization and add the system user to it | ||
| // This group will have a quota of 0 by default, which users can adjust based on their needs | ||
| prebuildsGroup, err := s.store.InsertGroup(ctx, database.InsertGroupParams{ |
There was a problem hiding this comment.
Couldn't this be done inside the if !alreadyOrgMember { condition? This way there was no need for all the additional unique violation checks, right? Or am I missing something? 🤔
| @@ -156,7 +156,7 @@ func (api *API) patchGroup(rw http.ResponseWriter, r *http.Request) { | |||
|
|
|||
| currentMembers, err := api.Database.GetGroupMembersByGroupID(ctx, database.GetGroupMembersByGroupIDParams{ | |||
| GroupID: group.ID, | |||
| IncludeSystem: false, | |||
| IncludeSystem: true, | |||
There was a problem hiding this comment.
Do we still need all these IncludeSystem: true cases?
There was a problem hiding this comment.
I think so, because I maintain that the prebuilds user should be visible. If we decide that we should hide the prebuilds user, then we can revert this back to false.
| preExistingMembership bool | ||
| name string | ||
| includePreset []bool | ||
| preExistingOrgMembership []bool |
There was a problem hiding this comment.
I'm a bit confused here, why are we now using a slice of bool in these cases? Could you add a comment here as well as in the test cases?
There was a problem hiding this comment.
The slices of bool allow us to test all the combinations of these scenarios. so in two "test cases", we actually technically have 16 tests.
|
|
||
| if tc.expectUserInGroup != nil && !*tc.expectUserInGroup { | ||
| // Check that the system user is NOT a member of the prebuilds group | ||
| groupMembers, err := db.GetGroupMembersByGroupID(ctx, database.GetGroupMembersByGroupIDParams{ |
There was a problem hiding this comment.
Shouldn't the prebuilds user always be part of the prebuilds group? Or is this the case where an organization doesn't have prebuilds?
There was a problem hiding this comment.
It should. This is a defensive measure against an edge case where such a group happens to already exist.
closes #18274
This pull request makes system users visible in various group related queries so that they can be added to groups. This allows system user quotas to be configured. System users are still ignored in certain queries, such as when license seat consumption is determined.
Summary by CodeRabbit