Категории пользователей

В UniBPM определено несколько категорий пользователей, различающихся по уровню доступа и управленческим возможностям.

Данный документ описывает модель прикладных прав доступа внутри системы и не относится к ролям Keycloak.

1. Пользователь (User)

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

Доступно

• Задачи, где пользователь назначен Исполнителем (task.assignee);
• Заявки, где он является ответственным (ticket.responsible) или владельцем (ticket.owner);
• Записи, связанные с доступными заявками: Вложения и Лента активности;
• Каталог сервисов с возможностью запуска связанных процессов.

Ограничения

• Нет доступа к списку рабочих пространств;
• Нет возможности изменять настройки процессов или заявок, не связанных с ним напрямую.

2. Участник пространства (Workflow Participant)

Описание
Пользователь, имеющий доступ (Permission) к конкретному пространству.

Доступно

• Создание заявок из доступного рабочего пространства;
• Просмотр, комментирование или изменение заявок в зависимости от уровня доступа: RO, COMMENT, RW, OWNER;
• Просмотр всех заявок пространства, если уровень доступа разрешает чтение.

Ограничения

• RO даёт только чтение;
• COMMENT добавляет возможность комментировать;
• RW добавляет изменение заявок, но не управление настройками и доступами;
• Настройки и доступы пространства доступны только владельцу или участнику с уровнем OWNER.

3. Участник заявки (TicketPermission)

Описание Пользователь, группа или сервисный аккаунт, которому выдан точечный доступ к заявке (TicketPermission).

Доступно

• Просмотр конкретной заявки;
• Комментирование или изменение этой заявки, если это разрешено уровнем READ, COMMENT или EDIT;
• Работа только с той заявкой, на которую выдан доступ.

Ограничения

• Не получает доступ ко всему пространству;
• Не может управлять настройками пространства;
• Не может управлять доступами, если нет отдельного права на управление доступом.

4. Владелец пространства (Workflow Owner)

Описание
Участник пространства, дополнительно обладающий правами управления настройками этого пространства (workflow.owner).

Доступно

• Все права участника пространства;
• Управление конфигурацией пространства (BPMN-модель, экранные формы задач, шаблоны, уведомления и т.п.);
• Добавление участников пространства и разграничение их доступа.

5. Администратор системы (System Administrator)

Описание
Пользователь с административной ролью, указанной в параметре application.admin-role-name
(по умолчанию — ROLE_unibpm-admin).

Доступно

• Полный доступ ко всем пространствам и заявкам;
• Управление пользователями, группами, категориями доступа и системными настройками;
• Доступ к разделу Администрирование.

Управление пользователями и группами

Администратор системы имеет доступ к разделу Администрирование → Пользователи и группы, в котором доступны следующие операции:

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

Особенности интеграции с Keycloak

Если включена фоновая синхронизация пользователей и групп через Keycloak (identity.keycloak.sync-enabled=true), Keycloak является источником истины.

Во время очередной синхронизации:

• локально созданные группы, отсутствующие в Keycloak, архивируются;
• ручные изменения состава групп могут быть перезаписаны данными Keycloak.

Для использования только локального управления пользователями и группами рекомендуется отключить фоновую синхронизацию:

identity.keycloak.sync-enabled=false

При включенном JIT-провижининге пользователи автоматически создаются и актуализируются при успешной аутентификации через Keycloak. Группы при этом должны заранее существовать в локальной БД и могут быть созданы администратором или legacy sync. JIT сопоставляет их с JWT по имени независимо от источника создания и не изменяет источник или метаданные группы. Состав membership пользователя приводится к набору существующих групп из JWT; отсутствующий или пустой claim очищает membership. Ручные добавления и удаления остаются разрешёнными, но могут быть перезаписаны при следующем входе.

Видимость задач

Функционал видимости задач определяет, какие задачи отображаются пользователю в системе UniBPM.

Пользователь может видеть задачи:

• в админ-панели, раздел Задачи;
• в тикета, раздел Задачи.

Общая логика

Каждый пользователь видит только те задачи, к которым у него есть доступ по своей роли.

Техническая реализация

Логика видимости задач реализована на backend-уровне и распределена между двумя основными компонентами:
PermissionServiceImpl и TaskQueryService.

Видимость задач реализована на backend-уровне и определяется комбинацией сервисов:

• PermissionServiceImpl.limitAccess() ограничивает видимость задач в зависимости от роли пользователя.
• PermissionServiceImpl.isWorkflowOwner() определяет, является ли пользователь владельцем одного или нескольких пространств.
• PermissionServiceImpl.applyUserAccessFilters() добавляет фильтры по исполнителю и связанным задачам.
• TaskQueryService.createPermissionSpecification() формирует запросы с фильтрацией по доступу.
• TaskController.getList() вызывает ограничение доступа перед получением списка задач.

Фильтрация выполняется до обращения к базе данных, чтобы исключить отображение недоступных задач.

💡 Примечание

Категории пользователей UniBPM не являются ролями Keycloak.
Keycloak используется для аутентификации и базового разграничения доступа,
тогда как категории пользователей определяют прикладной доступ внутри системы.

📘 Сравнительная таблица