Book a Demo

Managing visibility and availability of UI elements

Description

Cabinee implements a mechanism for managing the availability of UI elements depending on the user role. An administrator can hide fields, make them read-only, or leave them unrestricted. Settings are applied dynamically and affect only the interface — system logic does not change.

Main advantages of the mechanism:

  • Flexible interface configuration without developer involvement.
  • Centralized management of UI element visibility.
  • The backend stores and returns rules depending on roles.
  • The frontend automatically applies access.
  • Straightforward adaptation to different scenarios and customers.

Where the functionality is located

Admin → Field access.

In this section the administrator:

  • selects a user role,
  • views the list of interface elements,
  • assigns an access policy: Hide / Read only.

After saving, the setting is immediately applied to all users of the selected role.

How the mechanism works on the backend

The backend stores a set of access rules that specify:

  • the user role,
  • the interface element,
  • the policy (Hide or Read only).

The backend provides:

  • accepting and saving new rules,
  • updating existing rules,
  • deleting rules,
  • building the list of rules for the current user,
  • passing these rules to the frontend.

Actual hiding or locking is performed by the frontend based on data from the backend.

How rules are saved (Hide / Read only)

When an administrator selects “Hide” or “Read only”, the system creates a new record in the ui_access_rule table.

The following are saved to the database:

  • the role (for example ROLE_cabinee_general_user),
  • the element (for example SYSMENU:ORGANIZATIONS),
  • the selected policy (HIDE or READONLY).

The rule takes effect immediately.

How rules are deleted (clicking the cross)

If the administrator clicks the cross next to the selected policy, the system deletes the corresponding record from the ui_access_rule table.

After deletion:

  • the restriction stops applying,
  • the element is displayed without restrictions again,
  • on page refresh the frontend no longer hides or locks the element.

How the frontend receives and applies rules

When the interface loads, the frontend requests the current user’s rules. The backend, based on roles, returns a combined list of applicable rules.

The interface:

  • hides elements with the Hide policy,
  • locks elements with the Read only policy.

Limitations of the Read only (READ ONLY) policy

The Read only policy is not applied to all interface elements.

READ ONLY does NOT work for the following elements

1) Menu (System Menu)

  • Menu sections remain available.
  • The user can navigate to sections by clicking.
  • CRUD actions (create / edit / delete) are not blocked.

Example:
In the Persons menu the user can:

  • open the section;
  • create, edit, and delete records;
  • work with edit forms.

2) Ticket buttons

The READ ONLY policy is not applied to the following ticket buttons:

  • Run process
  • Create copy
  • Merge with
  • Move to
  • Delete

The buttons remain clickable and perform their actions.

3) Ticket activity

In ticket activity, the Read only policy:

  • does not block actions;
  • does not restrict user activity.

Where READ ONLY works correctly

The Read only policy is applied and works correctly for elements inside a ticket, including:

  • dropdown lists (Priority, Impact, State, and others);
  • ticket form fields;
  • file upload and file handling;
  • ticket fields;
  • editable ticket attributes.

Overall mechanism flow

The administrator creates or updates a rule. The backend saves it in the database. The user signs in. Keycloak passes the user’s roles. The frontend requests rules for the current user. The backend returns all rules that apply to their roles. The interface hides or restricts UI elements.

Administrator role priority

If the user has the administrator role (cabinee-admin), all restrictions assigned to other roles (for example, cabinee_general_user) are ignored.

What this means

  • The administrator always sees the full UI with no hidden elements.
  • The Hide and Read only policies assigned to other roles are not applied, even if those roles are also present for the user.
  • The administrator receives full access to all:
    • buttons,
    • tabs,
    • menu items,
    • form fields,
    • actions.

Thus, the administrator role is priority, and restrictions of other roles cannot override it.