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.
Permission-gated UI behavior
Where Permission Gating Applies
- Navigation layer: Side-menu items are shown only when required permissions are present.
- Route layer: Protected routes block direct URL access if the user lacks permission.
- Action/control layer: Buttons and actions (for example Add, Edit, Delete) are conditionally shown/enabled based on permission.
What Users Experience
- Users with read access typically see list/detail views but not write actions.
- Users with create access can usually access create/edit flows (and corresponding read views).
- Users with module * access can perform full management operations, including destructive actions where available.
- If access is denied, users are redirected to unauthorized handling or do not see the feature in navigation.
Typical UI Patterns in Admin Pages
- List pages are available with *.read.
- Create forms require *.create.
- Delete controls are commonly reserved for broader/full module permissions (often *).
- Management utilities (for example role assignment and advanced config flows) require elevated RBAC permissions.
Why This Matters Operationally
- Prevents accidental overreach by limiting visible controls.
- Reduces confusion by exposing only relevant capabilities per role.
- Enforces least-privilege principles in day-to-day administration.
Troubleshooting Missing UI Elements
- Verify active account context (root/home vs child scope).
- Confirm effective role assignments.
- Check required permission for that feature (read, create, or *).
- Re-authenticate to refresh session authorization state.
- Re-test via both navigation and direct URL.
Ready to rethink private cloud?
Lower costs. Simplify operations. Deliver more.