Repository navigation
UI/API: createAccount without mandatory user #14303
Description
Activity
Thanks for opening your first issue here! Be sure to follow the issue template!
🎯 Triage report
The author proposes making user creation optional when calling
createAccount(e.g. via acreateuserparameter defaulting totruefor backward compatibility), since Accounts and Projects can serve purely organizational roles without requiring a bound user. This would simplify IaC tooling (e.g. Terraform) and root-admin workflows that rely on Projects rather than per-account users.📊 Assessment
Dimension Value Reasoning Type type:new-featureRequests new optional behavior/parameter, not a bug fix. Component component:api,component:UIChange spans the createAccountAPI and the "Add Account" UI form.Severity n/a Not a bug. Labels type:new-feature, component:api, component:UI See reasoning above. Coding agent Needs more info The core idea is clear, but it requires a design decision (API contract/back-compat semantics, UI form changes, validation for accounts with zero users, RBAC implications) before implementation — best handled by a maintainer/committer first. No similar open issues were found via search.
💡 Notes and suggestions
- Key design question for maintainers: should a user-less account be permitted indefinitely, or only transiently (e.g., requiring at least one user before certain operations)? Several downstream flows (login, notifications, quota ownership) assume at least one
UserperAccount. - If pursued, this would touch
CreateAccountCmd/AccountManagerImpl(server-side), thecreateAccountAPI spec/docs, and the UI "Add Account" form inui/src/views/.... - Backward compatibility: defaulting the new parameter to
true(current mandatory behavior) is a reasonable approach to avoid a breaking change, as the author suggests. - Worth cross-referencing with existing Terraform provider issues/requests for decoupled account/user creation if any exist upstream.
Generated by Daily Issue Triage · sonnet50 70.5K · ◷
Add this agentic workflows to your repo
To install this agentic workflow, run
gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9- Key design question for maintainers: should a user-less account be permitted indefinitely, or only transiently (e.g., requiring at least one user before certain operations)? Several downstream flows (login, notifications, quota ownership) assume at least one
The required feature described as a wish
4.22+ with KVM
The createAccount API makes user creation mandatory, and I feel like that coupling should be optional. listAccounts/updateAccount don't directly reference the mandatory user so post-creation they're already decoupled (list does fetch ALL users for the accounts, but the mandatory user isn't special). The "Add Account" UI form also naturally makes the user creation mandatory. A createuser option on createAccount defaulting to true may be appropriate to avoid calling this a breaking change.
The terraform resource for accounts is one example where I find this inconvenient. I don't need the user (or its password) to be part of the tf state of the Account, and Users are their own separate resource in tf. Making the user optional will also make tf import for accounts cleaner (when implemented).
For another example, when adding a new tenant I may choose to create a Domain, an Account, and a Project (owned by the account), all of which serve an organizational unit purpose rather than gating user access (I delete the mandatory user post creation). My root admin users log in using Accounts bound to ROOT, and those Accounts act as simple user group <-> custom role mappings while tenant Projects own the instances/volumes/guest networks/userdata. As a root admin, in the UI the project selector feels a lot cleaner for setting scope than the SSO account selector (using SSO that way leads to massive user sprawl). For another UI example, creating affinity groups doesn't ask the root admin for a target domain/account/project in the form, but using the project selector puts me in an appropriate scope to create the affinity group correctly. This is just my rbac soup, and it's totally possible I'm solving this the wrong way.