Permission-gated UI behavior

VMease WebUI applies RBAC not only at API/route level, but also throughout the user interface. This means what an admin sees in the UI is dynamically filtered by effective permissions.

Back to documentation

Permission-gated UI behavior

Where Permission Gating Applies

  1. Navigation layer: Side-menu items are shown only when required permissions are present.
  2. Route layer: Protected routes block direct URL access if the user lacks permission.
  3. Action/control layer: Buttons and actions (for example Add, Edit, Delete) are conditionally shown/enabled based on permission.

What Users Experience

  1. Users with read access typically see list/detail views but not write actions.
  2. Users with create access can usually access create/edit flows (and corresponding read views).
  3. Users with module * access can perform full management operations, including destructive actions where available.
  4. If access is denied, users are redirected to unauthorized handling or do not see the feature in navigation.

Typical UI Patterns in Admin Pages

  1. List pages are available with *.read.
  2. Create forms require *.create.
  3. Delete controls are commonly reserved for broader/full module permissions (often *).
  4. Management utilities (for example role assignment and advanced config flows) require elevated RBAC permissions.

Why This Matters Operationally

  1. Prevents accidental overreach by limiting visible controls.
  2. Reduces confusion by exposing only relevant capabilities per role.
  3. Enforces least-privilege principles in day-to-day administration.

Troubleshooting Missing UI Elements

  1. Verify active account context (root/home vs child scope).
  2. Confirm effective role assignments.
  3. Check required permission for that feature (read, create, or *).
  4. Re-authenticate to refresh session authorization state.
  5. Re-test via both navigation and direct URL.

Ready to rethink private cloud?

Lower costs. Simplify operations. Deliver more.