Для назначения прав по ролям в разных проектах системы можно использовать создание ролей и технологию ролевого назначения прав.
Роль используется для
- настройки прав доступа к узлам структуры хранения данных (для которых заполнен атрибут "Карточка проекта")
- участия в назначении исполнителем на задачи
Задача использования ролей в настройке системы прав - при управлении правами и задачами иметь возможность менять/дополнять персоналии исполнителей, указывая их в участниках проекта (для каждого проекта - свои значения)
ВНИМАНИЕ! Обязательное условие использования технологии ролевого назначения прав - наличие списка Реестр проектов (или его аналога)
Как настроить Реестр проектов для работы ролевого назначения прав
1. Создается отдельный список "Реестр проектов" с привязанным типом элемента (ТЭ) Карточка проекта
ВНИМАНИЕ! Если есть аналогичный список, то новый создавать не надо. Надо его настроить по описанной ниже схеме
2. Атрибуты ТЭ Карточка проекта (или его аналога), необходимые для ролевой настройки прав:
- Папка проекта - Lookup-атрибут (ссылка на элемент списка) системное название атрибута- project_scope_folder
ВНИМАНИЕ! Обязательно использовать именно этот атрибут при создании или добавить этот атрибут в тип элемента-аналог - Атрибуты ролевых участников проекта - Lookup-атрибуты, например "ГИП", "Архитектор" и т.д.
3. В Реестре проектов на каждом элементе заполнить атрибуты "Папка проекта" и атрибуты ролевых участников проекта
Создание и настройка Ролей
1. В списке "Пользователи" в разделе "Роли" добавляется новая запись по кнопке Создать / Роль.
2. Роли присваивается название
3. Для Роли в поле "Атрибут с участниками роли" определяется название атрибута ролевого участника карточки проекта в Реестре проектов, из которого при использовании этой роли будут подтягиваться фамилии людей, выполняющих эту роль
Например:
В двух проектах в карточке есть атрибут ролевого участника проекта "ГИП" и он заполнен разными сотрудниками.
В процессе на этап подписания мы ставим роль "Роль ГИП", и при выполнении процесса в разных проектах задачи будут адресованы разным уполномоченным сотрудникам
4. Для каждого атрибута ролевого участника карточки проекта должна быть создана своя Роль в списке Пользователи/Роли.
Например:
Если в Карточке проекта есть два атрибуты ролевых участников проекта - "ГИП" и "Архитектор", то должно быть создано две соответствующие роли в списке Пользователей.
Что проверить и/или дополнить в настройках структуры хранения документации
1. В системе есть системный атрибут "Карточка проекта", который имеет системное имя project_scope. В настройках атрибута нужно обязательно указать список, который является реестром проектов.
2. На папке проекта, на которой добавлен атрибут project_scope, обязательно должен быть разрыв прав (иначе права на ролевых пользователей в этой папке не будут выданы).
Что дополнить в настройках для работы процессов
1. В структуре хранения данных на узлах, где были указаны исполнители задачи процессов по умолчанию, указать требуемые Роли из списка Пользователи/Роли
Например:
На свойствах папки "Стадия" или "Проект" в атрибуте "Согласующие", который по умолчанию указывает исполнителя этапа проверки документации специалистами, проставляем роли "Роль ГИП", "Роль Архитектор" и пр.
2. У ТЭ Процесс. добавить вычисление атрибута "Карточка проекта" (project_scope). Пример формулы:
Field(Parent(Ref("Вложение процесса"), "Проект", true), "Карточка проекта")
ВНИМАНИЕ! Если в формулах процесса указаны другие ТЭ папок из структуры хранения документации (СХД), к ним надо вручную привязать атрибут "Карточка проекта".
Если в СХД делаются разрывы прав на других ТЭ и права на них назначаются на Роль, то к этим ТЭ тоже необходимо привязать атрибут "Карточка проекта".
Статья посвящена настройкам для работы с функционалом Ролевого пользователя.
1. Реестр проектов
1. Создается отдельный список "Реестр проектов":
- автоматически при разворачивании базовой конфигурации, либо вручную;
- на некоторых площадках этот список уже может быть создан.
2. Создается Lookup-атрибут со ссылкой на список "Реестр проектов"
3. Данный Lookup-атрибут добавляется на те элементы, на которые необходимо назначать ролевых пользователей
4. Значение этого атрибута задается:
- вручную (на уровне ТЭ "Проект");
- либо вычисляется по формуле.
2. Предварительные настройки
1. Добавить атрибут project_scope_folder ("Папка проекта") к Типу Элемента, привязанному к списку "Реестр проектов".
2. Перейти в список "Реестр проектов", на элементе заполнить атрибуты project_scope_folder из СХД и Lookup-атрибуты участников.
3. В СХД указать роли из организационной структуры в Lookup-атрибутах участников процессов.
4. Добавить вычисление атрибута project_scope ("Карточка проекта") к ТЭ "Процесс".
5. Добавить вычисление атрибута project_scope ("Карточка проекта") в автоматизацию ТЭ "Задача".
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 содержит измененную группу:
| Code Block | ||
|---|---|---|
| ||
SELECT FROM public.user_group_membership
WHERE project = *ID проекта* AND group_list *содержит измененную группу* |
- Далее аналогично обновляем scope_read по проекту и principal_access_list:
| Code Block | ||
|---|---|---|
| ||
SELECT FROM public.scope_read WHERE project = *ID проекта* AND principal_access_list *содержит измененную группу* |
2. Алгоритм выбора элементов с проверкой прав на чтение.
Выбираем документы с присоединенными путями и фильтруем по scope_read, используя пересечение access_list с группами текущего пользователя:
| Code Block | ||
|---|---|---|
| ||
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) с учетом группы доступа пользователя:
...
| language | bash |
|---|
...
3. У ТЭ Задача процесса в автоматизации Установить значение поля "Карточка проекта" (project_scope). Пример формулы:
This("Процесс.Карточка проекта")