Управление видимостью и доступностью UI-элементов

Описание

В UniBPM реализован механизм управления доступностью UI-элементов в зависимости от роли пользователя. Администратор может скрывать поля, делать их доступными только для чтения или оставлять без ограничений. Настройки применяются динамически и влияют только на интерфейс — логика системы не изменяется.

Основные преимущества механизма:

Гибкая настройка интерфейса без участия разработчиков.
Централизованное управление видимостью UI-элементов.
Backend хранит и отдаёт правила в зависимости от ролей.
Frontend автоматически применяет доступы.
Лёгкая адаптация под различные сценарии и заказчиков.

Где находится функциональность

Админ → Доступ к полям.

В этом разделе администратор:

выбирает роль пользователя,
просматривает список элементов интерфейса,
назначает политику доступа: Скрыть / Только чтение.

После сохранения настройка сразу применяется ко всем пользователям выбранной роли.

Как работает механизм на backend

Backend хранит набор правил доступа, где указано:

роль пользователя,
элемент интерфейса,
политика (Скрыть или Только чтение).

Backend обеспечивает:

приём и сохранение новых правил,
обновление существующих правил,
удаление правил,
формирование списка правил для текущего пользователя,
передачу этих правил на frontend.

Реальное скрытие или блокировка выполняется фронтендом на основе данных от backend.

Как сохраняются правила (Скрыть / Только чтение)

Когда администратор выбирает “Скрыть” или “Только чтение”, система создаёт новую запись в таблице ui_access_rule.

В базу сохраняются:

роль (например ROLE_unibpm_general_user),
элемент (например SYSMENU:ORGANIZATIONS),
выбранная политика (HIDE или READONLY).

Правило начинает действовать сразу же.

Как удаляются правила (нажатие на крестик)

Если администратор нажимает на крестик рядом с выбранной политикой, система удаляет соответствующую запись из таблицы ui_access_rule.

После удаления:

ограничение перестаёт действовать,
элемент снова отображается без ограничений,
фронтенд при обновлении страницы больше не скрывает и не блокирует элемент.

Как frontend получает и применяет правила

При загрузке интерфейса frontend отправляет запрос на получение правил текущего пользователя. Backend, основываясь на ролях, возвращает объединённый список применимых правил.

Интерфейс:

скрывает элементы с политикой Скрыть,
блокирует элементы с политикой Только чтение.

Ограничения политики «Только чтение» (READ ONLY)

Политика «Только чтение» применяется не ко всем элементам интерфейса.

READ ONLY НЕ работает для следующих элементов

Разделы меню остаются доступными.
Пользователь может переходить в разделы по клику.
CRUD-действия (create / edit / delete) не блокируются.

Пример:
Меню Persons пользователь может:

открывать раздел;
создавать, редактировать и удалять записи;
работать с формами редактирования.

2) Ticket buttons

Политика READ ONLY не применяется к следующим кнопкам тикета:

Run process
Create copy
Merge with
Move to
Delete

Кнопки остаются кликабельными и выполняют действия.

3) Ticket activity

В активности тикета политика «Только чтение»:

не блокирует действия;
не ограничивает пользовательскую активность.

Где READ ONLY работает корректно

Политика «Только чтение» применяется и корректно работает для элементов внутри тикета, включая:

выпадающие списки (Priority, Impact, State и др.);
поля формы тикета;
загрузку и работу с файлами;
поля заявки;
редактируемые атрибуты тикета.

Общая схема работы механизма

Администратор создаёт или обновляет правило. Backend сохраняет его в базе данных. Пользователь входит в систему. Keycloak передаёт роли пользователя. Frontend запрашивает правила для текущего пользователя. Backend возвращает все правила, относящиеся к его ролям. Интерфейс скрывает или ограничивает UI-элементы.

Приоритет роли администратора

Если у пользователя есть роль администратора (unibpm-admin), то все ограничения, назначенные для других ролей (например, unibpm_general_user), игнорируются.

Что это означает

Администратор всегда видит полный UI без скрытых элементов.
Политики «Скрыть» и «Только чтение», назначенные для других ролей, не применяются, даже если эти роли тоже присутствуют у пользователя.
Администратор получает полный доступ ко всем:
- кнопкам,
- вкладкам,
- пунктам меню,
- полям формы,
- действиям.

Таким образом, роль администратора является приоритетной, и ограничения других ролей не могут ее перекрыть.