fix!: convert legacy login_type=none users into service accounts#27182
Draft
jakehwll wants to merge 7 commits into
Draft
fix!: convert legacy login_type=none users into service accounts#27182jakehwll wants to merge 7 commits into
login_type=none users into service accounts#27182jakehwll wants to merge 7 commits into
Conversation
Grandfather existing login_type='none' users instead of converting them. The users_email_not_empty and users_service_account_login_type CHECK constraints make flipping real users to is_service_account=true infeasible without blanking emails, so leave existing accounts untouched and gate only at creation time.
Convert existing non-system login_type='none' users into service accounts (is_service_account=true). The users_email_not_empty CHECK constraint (migration 000433) requires service accounts to have an empty email, so this blanks the email of each converted user. This is a destructive, breaking, one-way migration: original emails are not recoverable.
login_type=none at creation, grandfather existing userslogin_type=none users into service accounts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alternative to #26851 for DEVEX-226. These two PRs are mutually exclusive — only one should land; close the other.
This migration blanks the email address of every converted user and is one-way / irreversible. Original emails are not recoverable. See rationale below.
What this does
Deprecates
login_type=nonein favour of premium service accounts, taking the convert-to-service-account path:000534_legacy_none_to_service_accountsetsis_service_account = trueon legacylogin_type='none'accounts (non-system) and blanks their email to satisfy the schema constraints. System users are left untouched.POST /usersandcoder users createrejectlogin_type=none(and the deprecated--disable-login) unless a service account is requested.How it differs from #26851
login_type=noneuserslogin_type=noneusers000534_legacy_none_to_service_account000534_legacy_none_login_to_passwordBoth share the same creation-gating (
cli/usercreate.go,coderd/users.go) and test updates (coderd/userauth_test.go,coderd/users_test.go).Why the email must be blanked
Migration
000433_add_is_service_account_to_usersenforces:users_email_not_empty:(is_service_account = true) = (email = '')— service accounts must have an empty email.users_service_account_login_type:is_service_account = false OR login_type = 'none'— satisfied, since these users are alreadylogin_type='none'.The email uniqueness indexes were also redefined to exclude empty emails (
WHERE deleted = false AND email != ''), so blanking multiple rows to''does not cause unique-constraint conflicts. Converting these users to service accounts therefore requires clearing their email — hence the destructive, breaking nature of this PR.Decision log
login_type=noneusers onto the premium service-accounts feature ("Outcome 1"), not merely gate new creation.is_service_accountCHECK constraints (migration000433) require an empty email for service accounts. The email uniqueness indexes exclude empty emails, so blanking is safe from a uniqueness standpoint but destroys the original address.downmigration is a documented no-op.cli/usercreate.goandcoderd/users.go, matching test updates, plus the000534_legacy_none_to_service_account.{up,down}.sqlmigration.login_type=noneusers become service accounts and lose their stored email; advise exporting emails beforehand if needed.