Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[UI] "Add Account" form misleads users into creating unintended multi‑account tenants instead of adding users

Ouverte
  • Quelque chose ne va pas ?
#13,975 9 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@DaanHoogland y travaille déjà.

Depuis le 31/8/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

component:UI type:improvement
Component

UI

Affected Version

all versions

Severity

Moderate – causes operational confusion, resource misallocation, and unnecessary support tickets

Description

The current "Add Account" form in the CloudStack UI is a major source of confusion, especially for administrators who are not deeply familiar with CloudStack's account‑user model. The term "Account" is often misinterpreted as a user profile, leading to the unintended creation of separate accounts in the same domain when the actual goal is simply to add a new user to an existing account.

This confusion has real operational consequences, particularly in multi‑tenant environments.

Real‑World Scenario

In our onboarding flow for a new tenant:

  1. We create a parent domain where all contracted resources are allocated.
  2. Inside that domain, we create a single account of type domain admin with one initial user (the primary administrator for that tenant).

This is a standard and correct setup.

However, when the tenant later needs to add a second user (e.g., a regular operator) to the same account, the administrator goes to the UI and clicks the visible "Add Account" button – because that is the only obvious action presented.

They naturally assume they are adding a new user to the current account.

In reality, they are creating a brand new, separate account with its own resource limits, quotas, and isolated resource pool.

Consequences of This Confusion
1. Incorrect Resource Limits

The newly created account uses default limits, which almost never match the contracted quota for the tenant. When the new user logs in, they see a different set of available resources than expected, leading to confusion and support escalations.

2. Unintended Resource Isolation

All resources (VMs, volumes, snapshots, networks) deployed by the new user belong to the new account, not the tenant's primary account. Users within the same tenant are therefore unable to share or even see each other's resources – which violates the expected multi‑user, shared‑resource model within a single account.

Proposed Solution

The UI should clearly distinguish between creating a new tenant account and adding a user to an existing account.

1. Rename / Relabel the Current Button
  • Change the "Add Account" button label to something explicit, such as:
    "New Tenant Account"
  • This signals that the action creates a separate billing/resource entity.
2. Add a Dedicated "Add User" Action
  • Inside the account details view, add a clearly visible button labeled:
    "Add User to this Account"
  • This action would open a simplified form that only asks for:
    • Username
    • Password
    • Confirm password
    • Email
    • First name
    • Last name
    • Timezone
  • The new user would inherit the account's existing role and resource limits.
3. Add a Prominent Warning in the Current Form

Display a clear warning message at the top of the "Add Account" form, e.g.:

⚠️ Warning: Creating a new account creates a separate tenant with its own resource limits and isolated resources. Users in different accounts cannot share VMs or volumes. Networks can be shared between accounts when the appropriate permissions are granted. To add a new user to an existing account, please use the "Add User" option available from the account detail view.

Expected vs. Actual Behavior
Expected Actual
A clear, separate workflow for creating a new tenant vs. adding a user to an existing tenant. Only one unified "Add Account" interface exists, which heavily suggests account creation even when the intent is user addition.
Users within the same account share resources by default. Unintended multiple accounts cause resource fragmentation and isolation.
Related Community Discussions

This confusion has been noted before in the community:

The underlying model is clear: an account owns resources and defines the role; a user is simply a credential to access that account. The UI should reflect this more intuitively.

Additional Context

This is not a bug in the backend logic – the system behaves correctly. The problem is purely a UX/UI design issue that leads to preventable misconfigurations. Improving the interface would:

  • Reduce support overhead.
  • Lower the learning curve for new CloudStack administrators.
  • Prevent accidental multi‑account sprawl in production environments.
Langage dominant
Java
Étoiles
3.1k
Forks
1.4k
Merge moyen
5 j 19 h
PR mergées (30 j)
17

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/cloudstack

Toutes les issues de apache/cloudstack

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.