fix!: convert legacy login_type=none users into service accounts - #27182
fix!: convert legacy login_type=none users into service accounts#27182jakehwll wants to merge 14 commits into
login_type=none users into service accounts#27182Conversation
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.
jakehwll
changed the title
login_type=none at creation, grandfather existing userslogin_type=none users into service accounts
…andfather-legacy-login-type-none
github-actions
Bot
added
the
release/breaking
Documentation CheckThis PR deprecates Updates Needed
Notes
Automated review via Coder Agents |
|
🤖 Posted by Coder Agents on behalf of Jake Howell. Closing in favour of #26851, which takes the password-preserving conversion path (keeps emails and existing tokens) instead of converting to service accounts and blanking emails. These two PRs were always mutually exclusive; #26851 is the chosen approach and is being prepared for merge. |
1 participant
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:000544_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=noneusers000544_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 the000544_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.