You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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

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 содержит измененную группу:
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  && *массив групп в которые входит текущий пользователь*
  • No labels