Перейти к содержанию

Введение в подсистему умных ролей

В данном разделе представлена основная информация о работе подсистемы умных ролей, её настройках и возможностях.

Умные роли

Умная роль - тип роли в системе, состав которой рассчитывается и обновляется автоматически, а также может содержать в себе не только сотрудников, но и другие роли, имеющие состав (т.е. все типы ролей, кроме контекстных, а также временных). При наличии в умной роли других ролей, её состав формируется на основе сотрудников всех ролей, которые входят в умную роль.

Для создания умных ролей в системе существует объект - генератор умных ролей.

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

Генератор умных ролей

Это объект системы, с помощью которого система производит создание умных ролей, а также определяет, в какие моменты (при срабатывании каких триггеров) умная роль должна быть перерасчитана.

Генератор умных ролей определяет список владельцев умных ролей, по идентификаторам которых уже может определить состав каждой умной роли.

Генераторы умных ролей в системе могут быть реализованы следующими способами:

  1. С помощью карточки типа “Генератор умных ролей”, в которую включены необходимые настройки для создания и своевременного обновления умных ролей.

  2. Программно путем реализации методов генератора кодом на языке C#.

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

Второй способ позволяет использовать все возможности языка программирования C# для достижения необходимо результата, но требует опыта разработки и понимания концепции.

Карточка “Генератор умных ролей”

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

Основная вкладка

Пример основной вкладки карточки:

Карточка "Генератор умных ролей"

Данная карточка имеет следующий настройки:

  • Название - название генератора умных ролей.

  • Описание - описание генератора умных ролей.

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

  • Запрос SQL для получения ролей - запрос к базе данных, который должен возвращать набор ролей по идентификатору владельца умной роли. Может работать как в режиме выборки по одному владельцу, так и в режиме выборки по нескольким владельцам умных ролей. Для того, чтобы запрос работал в режиме выборки по нескольким владельцам, в нём должны использоваться особые плейсхолдеры, которые позволяют задействовать запрос для получения списка ролей для нескольких владельцев умных ролей сразу.

    Список плейсхолдеров:

    • #with_id(<text>) - используется для получения идентификатора владельца умной роли. В режиме множественной выборки заменяется на <text>. Не используется в режиме выборки по одному владельцу умной роли.

    • #when_id(<text>) - используется для сравнения идентификатора владельца умной роли. В режиме множественной выборки заменяется на <text> in <список_идентификаторов>. В режиме выборки по одному владельцу умной роли заменяется на <text> = @CardID.

    • #order_by_id(<text>) - используется для сортировки результата по идентификатору владельца умной роли. В режиме множественной выборки заменяется на ORDER BY <text>. Не используется в режиме выборки по одному владельцу умной роли.

    Note

    Пример запроса с реализованной выборкой по множеству карточек, когда формируется умная роль по подразделениям с руководителем подразделения в качестве состава роли:

    SELECT [HeadUserID] #with_id([ID]) FROM [DepartmentRoles] WITH(NOLOCK) WHERE #when_id([ID]) AND [HeadUserID] is not NULL #order_by_id([ID])

  • Шаблон имени роли - шаблон, по которому определяется имя умной роли. В качестве значения “{0}” подставляется имя владельца умной роли. Может быть использована строка локализации.

  • Запрос SQL на получение всех владельцев умных ролей - запрос к базе данных, который должен возвращать набор всех владельцев умных ролей, созданных указанным генератором умных ролей. Если не задан, то в качестве единственного владельца умной роли будет сам генератор умных ролей.

    Запрос должен возвращать следующие колонки:

    • Идентификатор владельца умной роли (тип Guid).
    • Имя владельца умной роли (тип string).
    • Идентификатор календаря для умной роли (тип Guid). Если возвращает null, то используется календарь по умолчанию.
    • Идентификатор временной зоны для умной роли (тип int). Если возвращает null, то используется временная зона по умолчанию.

    Note

    Пример запроса, когда формируется умная роль по подразделениям:

    SELECT [ID], [Name], [CalendarID], [TimeZoneID] FROM [Roles] WITH(NOLOCK) WHERE [TypeID] = 2

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

    Запрос должен возвращать следующие колонки:

    • Имя владельца умной роли (тип string).
    • Идентификатор календаря для умной роли (тип Guid). Если возвращает null, то используется календарь по умолчанию.
    • Идентификатор временной зоны для умной роли (тип int). Если возвращает null, то используется временная зона по умолчанию.

    Запрос имеет следующие параметры:

    • @CardID - идентификатор владельца умной роли.

    Note

    Пример запроса, когда формируется умная роль по подразделениям:

    SELECT [Name], [CalendarID], [TimeZoneID] FROM [Roles] WITH(NOLOCK) WHERE [TypeID] = 2 AND @CardID = [ID]

  • Скрыть роли - флаг определяет, что созданные данным генератором умные роли будут скрыты.

  • Инициализировать роли - флаг определяет, что умные роли должны быть созданы в момент сохранения генератора умных ролей. Иначе умные роли будут создаваться при срабатывании триггеров по мере необходимости.

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

  • Таблица “Триггеры” - таблица с настройками триггеров, при срабатывании которых система производит обновление списка умных ролей и их состава для определённого набора владельцев умных ролей. Проверка триггеров производится системой при изменении карточек.

    Триггер генератора умных ролей

    Каждый триггер имеет следующие настройки:

    • Название - название триггера.

    • Типы - типы карточек и типы документов, для которых проверка данного триггера выполняется. Наравне с одиночными значениями для выбора доступны группы ссылок с типами “Тип карточки” и “Тип документа”.

    • Обновлять асинхронно - флаг определяет, что при срабатывании триггера обновление ACL должно производиться асинхронно с использованием Chronos. Следует устанавливать, когда ожидается, что запрос на получение карточек для обновления может возвращать большое количество карточек (например, больше 100), или долго выполняться.

    • Обновлять умную роль только проверяемой карточки - флаг определяет, что при срабатывании триггера обновление умной роли должно быть выполнено только для владельца умной роли с идентификатором карточки, запустившей проверку триггера. При установке флага поле Запрос SQL для получения обновляемых карточек недоступно.

    • Запрос SQL для получения обновляемых карточек - запрос к базе данных, который используется для определения списка владельцев умных ролей для обновления при срабатывании триггера. Если запрос не задан, то используется запрос из поля Запрос SQL на получение всех владельцев умных ролей.

      Запрос имеет следующие параметры:

      • @CardID - идентификатор карточки, запустившей выполнение триггера.
    • Проверять условия через оператор “И” - флаг определяет, что для срабатывания триггера необходимо, чтобы каждое условие из списка было выполнено. Иначе достаточно выполнения хотя бы одного условия.

    • Список условий - набор условий, которые проверяются при проверке триггера. Если выполнены одно или все условия, в зависимости от настроек триггера, то система производит запуск обновления умных ролей для набора владельцев умных ролей, определённого данным триггером. Про подсистему условий можно прочитать в разделе Типы условий.

Вкладка “Валидация”

Пример вкладки “Валидация:

Вкладка валидация

На данной вкладке можно произвести валидацию одного или всех генераторов умных ролей с помощью соответствующих кнопок.

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

Ошибка записываются только при установке флага Включить логирование ошибок. В противном случае ошибки записываются только в серверный лог, при расчёте на сервере, и в лог Chronos, при расчёте в плагине.

Программный генератор умных ролей

Чтобы создать программный генератор умных ролей нужно:

  1. Реализовать класс с интерфейсом ISmartRoleGenerator. Для удобства разработки в качестве основы можно использовать базовый класс SmartRoleGeneratorBase. В нём реализуется логика расчёта списка владельцев умных ролей и списка ролей для каждой умной роли.

  2. Реализовать класс с интерфейсом ISmartRoleGeneratorProvider и зарегистрировать его в контейнере зависимостей с уникальным именем. Данный объект должен вернуть одно или несколько программных генераторов умных ролей, реализованных в пункте 1.

Генерация умных ролей

Система может производить создание и обновление умных ролей несколькими способами:

  1. Синхронно - обновление умных ролей производится в момент непосредственного сохранения объекта, вызвавшего это обновление. Срабатывает, когда изменение затрагивает обновление для небольшого количества умных ролей при срабатывании триггера.

  2. Асинхронно - обновление умных ролей производится в плагине Chronos’а, который выполняет логику обновления. При выполнении асинхронного обновления создается операция в таблице операций. Срабатывает, когда изменение затрагивает обновление для большого количества умных ролей при срабатывании триггера, или если в триггере установлен флаг Обновлять асинхронно.

  3. Полный перерасчёт - расчёт производится асинхронно в отдельном плагине, который запускает полный перерасчёт умных ролей для генератора. Данный режим актуален только для карточек генераторов умных ролей (для программных генераторов его можно реализовать отдельно, при необходимости). Срабатывает при изменении карточки генератора умных ролей, а также при отключении/включении генератора, удалении карточки.

Создание и обновление умных ролей может быть запущено следующими способами:

  1. При создании/изменении/удалении генератора умных ролей. В таком случае расчёт запускается в режиме Полный перерасчёт.

  2. При срабатывании триггера на создание/изменение/удаление карточки.

  3. При срабатывании триггера правила расчёта ACL, которое использует умные роли, и обновляемая карточка запрашивает умную роль с идентификатором владельца, для которого умной роли ещё не было создано.

  4. При изменении состава для роли, которая входит в список ролей для умной роли, вызывается обновление списка сотрудников этой умной роли.

  5. Через расширения можно самостоятельно запускать перерасчёт одного или нескольких генераторов умных ролей для набора владельцев умных ролей или по триггерам. Для этого следует использовать объект ISmartRoleUpdateManager.

  6. Через тайл “Перерасчитать генератор умных ролей” на левой панели карточки “Генератор умных ролей” можно запустить перерасчёт умных ролей для данного генератора. Перерасчёт выполняется синхронно и переходит в асинхронный режим автоматически при необходимости. Тайл доступен администраторам системы.

  7. Через тайл “Пересчитать умную роль” на левой панели карточки “Умная роль” можно запустить перерасчёт этой умной роли по её генератору. Перерасчёт выполняется синхронно. Тайл доступен администраторам системы.

Во всех случаях, где не указано явно, расчёт запускается синхронно, но переводится в асинхронный режим автоматически в случае большого количества изменений.

Back to top