Статья посвящена настройкам для работы с функционалом Ролевого пользователя.

1. Предварительные настройки

1. Добавить атрибут project_scope_folder ("Папка проекта") к Типу Элемента, привязанному к списку "Реестр проектов".

2. Перейти в список "Реестр проектов", на элементе заполнить атрибуты project_scope_folder из СХД и Lookup-атрибуты участников.

3. В СХД указать роли из организационной структуры в Lookup-атрибутах участников процессов.

4. Добавить вычисление атрибута project_scope ("Карточка проекта") к ТЭ "Процесс".

5. Добавить вычисление атрибута project_scope ("Карточка проекта") в автоматизацию ТЭ "Задача".

2. Реестр проектов

1. Создается отдельный список "Реестр проектов":

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

2. Создается Lookup-атрибут со ссылкой на реестр проектов
3. Данный Lookup-атрибут добавляется на те элементы, на которые необходимо назначать ролевых пользователей

4. Значение этого атрибута задается:

• вручную ("Проект");
• либо вычисляется по формуле ("Стадия"/"Раздел"/"Задача" и т.д.).

3. Настройка ролевого пользователя

1. Состав ролевых пользователей для проекта осуществляется на списке "Реестры проектов" в отдельных атрибутах (Мульти Lookup).

2. В организационную структуру добавляется новый ТЭ "Ролевой пользователь".

Ролевой пользователь — это группа пользователей, привязанная к проекту (например, Архитекторы, Инженеры и т.д.).

3. В ТЭ "Ролевой пользователь" есть обязательный атрибут Lookup-атрибут со ссылкой на реестр проектов, где задается состав ролевой группы на проекте.

4. Структура БД

1. Cоздаются таблицы расшифровок функциональных групп и ролевых пользователей для Lookup-атрибутов (user_group_membership) со столбцами:

• id (guid) — идентификатор расшифровки;

• source (guid) — ID элемента;

• field (guid) — ID Lookup-атрибута; 

• project (guid) — ID проекта;

• group_list (guid[]) — список пользователей/групп;

• principal_list (guid[]) — список пользователей/групп для расшифровки.

2. Для таблицы scope_read применяются следующие столбцы:

• id (guid) — идентификатор;
• project (guid) — ID проекта;
• principal_access_list (guid[]) — список групп с правами на чтение;
• access_list (guid[]) — список групп/пользователей, имеющих доступ.

3. Алгоритмы работы

1. Алгоритм пересчета при изменении составов ролевых пользователей в проекте.

• Для заданного ID проекта и ID атрибута ищем элементы в user_group_membership, где project соответствует проекту и group_list содержит измененную группу:

SELECT FROM public.user_group_membership 
WHERE project = *ID проекта* AND group_list  *содержит измененную группу*

• Далее аналогично обновляем scope_read по проекту и principal_access_list:

SELECT FROM public.scope_read WHERE project = *ID проекта* AND principal_access_list *содержит измененную группу*

2. Алгоритм выбора элементов с проверкой прав на чтение.

Выбираем документы с присоединенными путями и фильтруем по scope_read, используя пересечение access_list с группами текущего пользователя:

SELECT FROM public.document d
INNER JOIN public.list_item_path lip on (d.id = lip.id)
INNER JOIN public.scope_read sr on (lip.scope_read = sr.id)
WHERE sr.access_list && *массив групп в которые входит текущий пользователь*

3. Алгоритм поиска по Lookup-атрибутам.

Выбор документов через соответствующий поиск по Lookup (ugm.field соответствует нужному Lookup) с учетом группы доступа пользователя:

SELECT FROM public.document d
INNER JOIN public.list_item_path lip on (d.id = lip.id)
INNER JOIN public.user_group_membership ugm on (ugm.source = d.id AND ugm.field = *ID лукапа* )
WHERE ugm.principal_list  && *массив групп в которые входит текущий пользователь*