Ролевая модель¶

В платформе Tessa роли используется повсеместно:

для определения прав
в процессах согласования и задач
при назначении любых заданий
при отправке уведомлений
при замещении
в представлениях
в бизнес-логике и коде
…

В приложении Tessa Client администратор может всегда увидеть роли, существующие в системе.

В платформе существуют следующие типы ролей:

Статическая роль

Привычная всем роль-группа. Ее создает администратор и включает в нее сотрудников.
Сотрудник

Неожиданно, но сотрудник тоже является ролью. Обычно он единственный входит в ее состав, но, как только у него появляется заместитель - он тоже входит в состав этой роли.
Подразделение

Любое подразделение является ролью, т.к. является группой. Включает в себя всех сотрудников данного подразделения.
Контекстная роль

Это вычисляемая роль, состав которой зависит от контекста, т.е. от карточки, для которой она вычисляется. Например, в роль “Автор документа” будут входить разные сотрудники для разных карточек - тот, кто является автором данной конкретной карточки.

Important

Все вычисляемые роли рассчитываются сервисом Chronos, который должен быть корректно установлен и настроен.
Динамическая роль

Это тоже вычисляемая роль, но она не зависит от контекста. Она вычисляется с указанной администратором периодичностью и в зависимости от вложенной в нее логики может сильно упроситить процесс внедрения. Пример - роль “Все сотрудники”, поставляемая с системой. В нее автоматически попадает любой сотрудник, который есть в справочнике сотрудников.
Метароль

Также вычисляемая роль, но ее генератором является карточка специального типа - “Генератор метаролей” (Tessa Client→Администратор→Прочее→Генераторы метаролей). В отличие от динамической роли, генератор может создавать множество ролей сразу. С типовым решением приходит генератор ролей вида “Подразделение (все)”. Он генерирует роли, в которые попадают все сотрудники подразделения и всех дочерних подразделений вплоть до листов. Такие роли мы называем Агрегатные (включающие всех сотрудников подразделения).
Временная роль(роль задания)

Эта роль не видна в приведенном выше представлении. Она используется, например, когда назначается задание на контекстную роль, например, “Инициатор согласования”. Система вычисляет эту роль, получает список пользователей в ней и создает временную роль, в которую включает этих людей. Роль существует только пока существует это задание. Аналогичным образом создается временная роль, когда отправляется задание нескольким людям в режиме альтернативного исполнения - система объединяет указанных людей во временную роль.

Контекстная роль¶

Зависит от карточки.
Задаётся через SQL.

SELECT #distinct #top_1 t.ParticipantID, FIO
FROM   participants t WITH(NOLOCK)
WHERE  t.CardID = #context_card_id
  AND  (t.RoleID = #role_id OR t.RoleName = #role_name)
  #and_user_id_is(t.ParticipantID)

Возвращает:

Режим списка: список пользователей, входящих в роль (ID и имя пользователя или только ID). Передаются параметры ContextCardID, RoleID, RoleName.

Note

Этот режим используется, например, при отправке задания на эту роль - системе нужны ВСЕ пользователи, которые в нее входят.

Бинарный режим: признак вхождения пользователя в роль (да / нет). Передаются параметры ContextCardID, RoleID, RoleName, CurrentUserID.

Note

Этот режим используется, например, при вычислении прав. Пользователь открывает карточку - входит ли он в роль “Автор документа” или нет? Остальные пользователи роли, даже если есть - систему не интересуют.

Формирование запроса:

Оператор #context_card_id всегда заменяется на параметр @ContextCardID. Это идентификатор карточки.
Оператор #distinct заменяется на distinct в режиме списка и на пустую строку в бинарном режиме.
Оператор #top_1 заменяется на пустую строку в режиме списка и на top 1 в бинарном режиме.
Оператор #role_id всегда заменяется на параметр @RoleID. Это идентификатор контекстной роли.
Оператор #role_name всегда заменяется на параметр @RoleName. Это имя контекстной роли.
Оператор #and_user_id_is работает следующим образом:
- Режим списка: выражение удаляется от #and_user_id_is до закрывающейся круглой скобки.
- Бинарный режим: выражение заменяется на AND t.ParticipantID = @CurrentUserID

Формирование запроса в бинарном режиме:

Указывается @CurrentUserID помимо @ContextCardID, @RoleID и @RoleName.
Позволяет системе оптимизировать проверку: входит ли пользователь в роль для карточки (проверяется минимум каждый раз при доступе к КД).

Контекстная роль:

Используется при расчете маршрута согласования или исполнения карточки, при направлении уведомлений.
Роль “фиктивная”: вычисляется каждый раз в момент использования, и именно возвращённым пользователям назначаются задания, направляются уведомления и т.д.
Состав роли меняется непредсказуемо. Пример: нельзя назначить на роль задание, не разворачивая роль в список пользователей, т.к. рабочее место (показывающее список заданий для пользователя) должно иметь возможность сделать JOIN к этому списку.
Физически хранится в таблице с пустым списком пользователей.

При назначении задания на контекстную роль она заменяется ролью задания. Роль задания имеет другой ID, имя контекстной роли, ссылку на контекстную роль в качестве родительской роли и вычисленный состав роли для карточки, на которую назначено задание. Поле с типом роли в таблице с заданиями указывает, что это контекстная роль, а не роль задания. При завершении задания роль задания удаляется, а в истории завершения указывается, что задание было назначено на роль “UserName (RoleName)”, например, “Иванов И.И. (Инициатор)”, причём тип роли указывается как контекстная роль.

Примеры ролей¶

Согласующие - возвращает список пользователей, у которых есть задание на согласование.
Инициатор согласования(входит в поставку) - возвращает пользователя, являющегося инициатором согласования. Например, в маршруте согласования можно прописать “Согласующий1, затем Согласующий2, затем Инициатор”. Тогда в момент, когда Согласующий2 завершит согласование, система посчитает эту роль, возьмёт пользователя-инициатора и отправит ему задание.

Динамическая роль¶

Задаётся через SQL.
Возвращает список пользователей, входящих в роль: ID и имя.
Пересчитывается в соответствии с настройками (период пересчёта или cron).
Можно использовать без ограничений, т.к. всегда существует физический список пользователей, входящих в роль (в БД). На роль можно назначать права и отправлять задания.

Примеры ролей¶

Ивановы - возвращает список пользователей с фамилией, начинающейся с “Иванов”.
```
SELECT t.ID, t.FullName
FROM   PersonalRoles t WITH(NOLOCK)
WHERE  t.FullName LIKE 'Иванов%'
```
Пользователи, у которых сегодня ДР. Обновляется каждый день, используется при нотификации.
Мужчины
Женщины

Статическая роль¶

Состав роли: пользователи, вручную добавленные администратором в роль (IsDeputy = false), и их заместители в настоящий момент (IsDeputy = true).
Статические роли связаны иерархически.
Информация по замещению редактируется пользователями и хранится в таблице замещений:
- ID и имя пользователя-заместителя
- ID и имя замещаемого пользователя
- ID и название роли, для которой выполняется замещение
- MinDate - дата начала временного замещения или DateTime.MinValue, если замещение не зависит от даты.
- MaxDate - дата окончания временного замещения или DateTime.MaxValue, если замещение не зависит от даты.
Для замещения система выполняет пересчёт состава роли (периодический и по требованию):
- Удаляет тех заместителей, чьё время закончилось (не входит в интервал MinDate…MaxDate) или для кого информация была удалена из таблицы замещений.
- Добавляет тех заместителей, которые отсутствовали в составе роли, но для которых есть запись в таблице замещений и текущее время попадает в интервал MinDate…MaxDate.

Подразделение (департамент)¶

Разновидность статической роли.
Состав определяется администратором.
Задаёт вхождение пользователей в департаменты.
Составляет иерархию, отдельную от обычных статических ролей.
Обладает дополнительным набором атрибутов. Пример: глава департамента (ссылка на пользователя).
Департаменты как роли очень удобны. Это позволяет использовать департаменты как для назначения прав, так и для отправки заданий, уведомлений и прочего.
Замещение аналогично статической роли.

Сотрудник (пользователь)¶

Important

Сотрудник, он же пользователь, это персональная роль. Является разновидостью статической роли для которой может быть задано замещение. У пользователя имеются дополнительные поля, хранящие специфичную для пользователя информацию. Рекомендуется ссылаться на таблицу PersonalRoles, а не на общую таблицу Roles.

Разновидность статической роли.
Соответствует каждому пользователю.
Создаётся системой.
По умолчанию в состав роли включён соответствующий пользователь (с тем же ID, то есть ссылка на саму роль).
Заместители временно включаются в состав роли (см. статическую роль).
Используется для назначения прав и заданий, отправки уведомлений и замещения, связанного с конкретным пользователем. Т.о. всё, что можно сделать с ролью, можно сделать и с пользователем.
Роли не связаны иерархически, но пользователи видят персональные роли, специальным образом упорядоченные в иерархическом справочнике ролей.

Генератор ролей и метароли¶

Генератор ролей:

Не является ролью и хранится отдельно от справочника ролей.
Имеет название и настройки (период пересчёта или cron).
Позволяет при помощи одного SQL генерировать множество ролей - т.н. метаролей. Метароли создаются с указанием обратной ссылки на генератор.

SQL возвращает метароли и входящих в них пользователей (включая текущих заместителей):

role_id (GUID, INT или VARCHAR)	role_name (string)	user_id (GUID)	user_name (string, необязательное)
1	Мужчины	5	Сидоров Ю.В.
1	Мужчины	6	Васечкин С.Т.
2	Женщины	1	Квочкина А.С.
2	Женщины	2	Пятачкова М.У.

При обработке такого SQL-запроса система:

Создаст в справочнике ролей две новых метароли: Мужчины и Женщины.
Включит в них соответствующих пользователей.
Обновит состав метаролей, которые возвращены запросом, но уже были созданы ранее.
Удалит состав метаролей, которые не возвращены запросом, но уже были созданы ранее. Сами метароли не удаляются, т.к. отсутствие пользователей в роли может быть временным и не эквивалентно отсутствию роли (а вместе с тем и всех записей, которые ссылаются на роль).
Каждому из role_id, заданных произвольно, поставит в соответствие “свой” идентификатор, запомнит соответствие и добавит в справочник ролей метароли со “своими” идентификаторами. Сохранённая информация о связи с role_id позволит обновлять и переименовывать метароли, а также ссылаться на них по ID (который не изменится после очередной генерации).
Система сохраняет результаты запроса во временную таблицу и делает её JOIN со справочником ролей для определения имени пользователя, который будет записан в справочник.

Метароли могут включаться в интерфейс выбора роли из справочника путём их группирования по названию генератора ролей.

Если в качестве user_id указать NULL (например, вследствие LEFT JOIN), то по такой строке не будет создано пользователей, но будет создана метароль. Если в результате выполнения SQL генератора будет возвращена метароль, во всех строках с которой указаны user_id, равные NULL, то метароль будет создана без пользователей.

Агрегатная роль¶

Метароль, в которую входят пользователи исходной роли и всех дочерних ролей вплоть до листов без повторений.
Работает для всех иерархических ролей (статических ролей и департаментов).

Временная роль (роль задания)¶

Создаются для конкретного списка пользователей. Имя роли может быть сгенерировано из имён пользователей в списке.
Принадлежат конкретному заданию и только ему. Нельзя повторно использовать в других заданиях.
Автоматически удаляются системой при удалении / завершении задания и при удалении карточки.
В истории завершённого задания вместо ссылки на роль задания указывается ссылка на персональную роль пользователя, завершившего задание.
Пользовательские таблицы не должны ссылаться через Foreign Key на роль задания.
Роль обычно создаётся в пользовательских расширениях перед созданием задания.

Например, через хэлпер CreateTaskRole:

Guid userID1 = ... ;                  // ID пользователей, которых нужно добавить в роль
Guid userID2 = ... ;
IRoleRepository repository = ... ;    // API ролевой модели
IUnityContainer container = ... ;     // Unity-контейнер на серверной стороне, содержащий объект сессии ISession
CardTask task = ... ;                 // создаваемое задание, которое требуется назначить на роль

// создаём роль задания с двумя заданным пользователями и текущим пользователем
PersonalRole user1 = await repository.GetPersonalRoleAsync(userID1);
IRoleUser user2 = (await repository.GetRoleAsync(userID2)).ToRoleUser();
IRoleUser currentUser = new RoleUser(container.Resolve<ISession>().User);
TaskRole taskRole = RoleHelper.CreateTaskRole(user1, user2, currentUser);

// записываем роль вместе с её составом в базу данных.
await repository.InsertAsync(taskRole);

// указываем, что задание назначено на роль
task.RoleID = taskRole.ID;
task.RoleName = taskRole.Name;        // эта строка необязательна, но ускоряет создание задания

// после сохранения карточки с заданием task сервис карточек будет производить управление созданной ролью
// поэтому нельзя повторно использовать роль для другого задания!

Замещение и временное включение в роль.¶

В каждой карточки роли есть раздел Заместители (таблица RoleDeputies в схеме), где система хранит информацию о замещениях.

При этом замещение может быть неактивным или только на определенный период. Система периодически пересчитывает состав роли, исходя из информации в разделе “Заместители”.

Note

Например, если Иванов замещает Сидорова в роли “Руководители департаментов”, начиная с 15 января 2023 года и до 20 января 2023 года, то до наступления этой даты Иванов в состав роли не попадет. Однако, как только указанная дата наступит - система включит Иванова в состав роли “Руководителя департаментов” и удалит его оттуда, когда период замещения закончится.

Important

Все замещения рассчитываются сервисом Chronos, который должен быть корректно установлен и настроен.

Important

Не рекомендуется настраивать замещение непосредственно из карточки роли. В системе есть существенно более удобный механизм - карточка Мои замещения. Администраторы могут настраивать замещения пользователей непосредственно из карточки пользователя.

Параметр “Скрывать при выборе”¶

Для ролей типов Сотрудник, Подразделение, Статическая роль, Контекстная роль, Динамическая роль, Метароль есть возможность отключить возможность выбора роли в ссылочных элементах управления (например, при формировании маршрута согласования), для этого нужно установить параметр скрывать при выборе.