Пример 3. Согласующие подразделений

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

Данный пример состоит из:

1. Доработка типа карточки “Подразделение”.

2. Доработка типа карточки “Договор”.

3. Доработка серверного расширения на сохранение карточки подразделения.

4. Генератор умных ролей “Согласующие подразделений”.

5. Шаблон бизнес-процесса “ACL Example”.

6. Правило расчёта ACL “Роли заданий”.

7. Правило расчёта ACL “Исполнители заданий”.

Доработка типа карточки “Подразделение”

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

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

Для мапинга подразделения и вида документа к идентификатору владельца умной роли используется табличная секция маппинга, добавленная в примере 2.

Доработка типа карточки “Договор”

В карточку договора добавлена новая вкладка “Настройки согласования” и поле “Согласующие подразделения”.

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

Серверные расширения

В данном примере дорабатывается серверное расширение из примера 2.

Расширение дополнительно срабатывает при сохранении карточки подразделения при наличии новых строк в таблице с согласуюшими подразделения.

Шаблон бизнес-процесса “ACL Example”

В систему добавляется шаблон бизнес-процесса с примером процесса согласования.

Данный процесс реализован для типа карточки “Договорной документ” и имеет одну кнопку, запускающую данный бизнес-процесс.

Шаблон процесса:

Данный процесс содержит следующие значимые для примера узлы и действия:

• Узел с действием запуска процесса.

• Узел с действием смены состояния процесса при запуске и скриптом инициализации согласующих процесса. Данный скрипт берёт список согласующих подразделений из карточки договора и по каждому из них получает умную роль по генератору “Согласующие подразделений” для вида карточки “Договор”. Данный набор умных ролей будет использоваться для формирования списка согласующих. Если не одной роли не найдено, то запуск процесса вернёт ошибку.

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

• Узлы с действием смены состояния при согласовании и не согласовании.

• Узел с действием завершения процесса.

Генератор умных ролей “Согласущие подразделений”

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

Идентификатором владельца умной роли является идентификатор строки подразделения с маппингом по видам документов.

Данная карточка имеет следующие запросы и триггеры:

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

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

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

• Триггеры, которые запускают обновление умных ролей в следующих ситуациях:

  

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

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

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

Правило расчёта ACL “Роли зададний”

Данное правило производит расчёт ACL для карточек с типами “Документ” и “Договорной документ” и записывает в ACL роли, на которые были отправлены задания. При этом в ACL записываются как авторы заданий, так и исполнители.

Данное правило расчёта ACL не использует умные роли, но самостоятельно рассчитывает список ролей.

Данная карточка имеет следующие запросы и триггеры:

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

• Триггеры, которые запускают обновление ACL для карточек в следующих ситуациях:

  • При создании заданий, при изменении списка ролей заданий и при завершении заданий.

Правило расчёта ACL “Исполнители зададний”

Данное правило производит расчёт ACL для карточек с типами “Документ” и “Договорной документ” и записывает в ACL сотрудников, которые завершили задание.

Данное правило расчёта ACL не использует умные роли, но самостоятельно рассчитывает список ролей.

Данная карточка имеет следующие запросы и триггеры:

• Запрос на получение всех сотрудников, завершивших задание по идентификатору карточки. Запрос также поддерживает режим множественной выборки.

• Триггеры, которые запускают обновление ACL для карточек в следующих ситуациях:

  • При завершении заданий.