👥 Members and Permissions (User Management)

Member management controls which users can access the system and what they can do. At its core, it is a combination of “user + role + group permission”.

In one sentence

Who can log in, which menus they see, and which environments they can operate are all controlled here in “Members & Permissions”.

🧩 Preset roles: choose an identity first

The system provides two core roles out of the box:

• 👑 Enterprise Admin

  • Typically for company owner / tech lead.
  • Has almost all feature permissions and menu access.
  • Can manage team members, group permissions, billing, and other critical modules.
  • Usually has “all group permissions” and can see all environments.

• 👤 Regular User

  • For operators, testers, outsourced accounts, and daily users.
  • Usually only needs menus related to their own work.
  • Environment visibility is controlled by “group permissions” (see Group Management).

You can add more custom roles in “Role Management”, but these two defaults already cover most common team setups.

🧱 Common operations: tasks around “people”

On the Members (Role Users) page, you can perform:

• ➕ Create user

  • Use “Create new user” to add an account, setting username, nickname, initial password, etc.
  • After creation, assign an appropriate role to this user.

• 🏷 Assign role

  • Select a user in the list and click “Assign role”.
  • Choose target role (Enterprise Admin / Regular User / custom role, etc.).
  • After confirmation, this user’s access follows the new role’s permissions.

• 🟢🟥 Online / Enable / Disable

  • View each user’s current state in the list.
  • Enable/disable by toggling the switch.
  • Disabled accounts can no longer log in or operate the system.

• 🔐 Reset password

  • When users forget passwords or suspect account compromise, use “Reset password” to generate a new one.
  • You can force users to change their password on next login.

• 🗑 Delete user

  • Remove accounts that are no longer needed.
  • Before deletion, confirm that business ownership has been handed over.

• 🧭 Authorize groups

  • Use “Group authorization” to control which environment groups a user can access.
  • Supports two modes:
    • All groups: user can access all environments.
    • Specific groups: user can only access assigned groups.
  • See “Group Management” for more details.

🔐 Three-layer permissions: menu / feature / button

Permission control is roughly three layers, from “visible” to “clickable”:

• 📑 Menu / page permissions

  • Decide which modules appear in the left menu (Environment, Billing, System Management, etc.).
  • In most cases, configuring menu permissions is enough.

• ⚙️ Feature permissions

  • Finer control of operations inside a module, such as:
    • Whether the user can create/delete environments.
    • Whether they can edit groups or authorize users.
    • Whether they can access sensitive pages.
  • Shown as a tree in “Feature Permissions”, where you configure per role.

• 🎛 Button-level permissions

  • Even finer control for specific buttons or entry points.
  • For example: “Reset password button”, “Delete button”.
  • Used by the frontend for button-level authorization.

🚫 Limitations of built-in roles

For security, built-in roles (such as Enterprise Admin and Regular User) have special constraints:

• Core feature permissions of built-in roles are predesigned and cannot be edited in the UI. The UI will show messages such as:
  • “Built-in roles cannot modify feature permissions.”
• If you need custom combinations:
  • Create a custom role based on the built-in role’s concept.
  • Adjust menu / feature / button-level permissions on the custom role instead.

This keeps built-in roles safe by default while still allowing customization via new roles.

⭐ Recommended setup for Regular Users

For most Regular Users, you do not need extremely fine-grained feature/button control. Usually:

• Control visible pages through menu permissions (routes).
  • Expose only the modules they need.
  • Hide irrelevant modules.
• Combine with group permissions to control which environments they can see in Environment Management.

This approach is simple, safe, and low-maintenance.

🧭 Configuration suggestions: building a good permission model

• For a small number of super accounts (Enterprise Admins)

  • Use built-in roles and avoid frequent changes to feature permissions.
  • Combine with full group permissions.

• For most Regular Users

  • Use “Regular User” or a custom role.
  • Focus on menu + group permissions.
  • Usually no need to adjust button-level permissions.

• For very special permission combinations

  • Create custom roles.
  • Configure menu, feature, and button permissions in “Feature Permissions”.
  • Then assign those roles to relevant users.

With “preset roles + group permissions + menu permissions”, you can build a clear, maintainable permission system without heavy configuration overhead.