image1

© Syntellect 2020


1. Введение

TESSA – система документооборота, предназначенная для построения сложных процессов обработки документов. Система предназначена для работы в сложных условиях и специально оптимизирована для работы на слабых каналах связи.

1.1. Архитектура и физические компоненты системы

Система представляет из себя т. н. "трехзвенку". Пользователи запускают клиентское приложение TessaClient, которое при запуске подключается к серверу приложений TESSA. Сервер приложений взаимодействует с базой данных, обеспечивает аутентификацию пользователей и взаимодействие с клиентскими приложениями.

image183

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

Также система может быть развернута в режиме кластеризации серверов приложений.

1.2. Программные компоненты системы

  • Tessa Applications – специальное приложение, которое устанавливается на все клиентские компьютеры. Может устанавливаться централизованно групповыми политиками домена. Управляет приложениями TessaClient, TessaAdmin и обеспечивает их установку и обновление по сети. Также обеспечивает обработку ссылок на объекты системы.

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

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

  • Tessa Admin – клиентское приложение, рабочее место администратора системы, предназначенное для управления конфигурацией системы.

  • Сервис Chronos - сервис, устанавливается обычно на сервере приложений, обеспечивает рассылку уведомлений, расчёт ролей и замещений и любые действия, которые выполняются по расписанию.

  • Сервер приложений Tessa - серверная часть платформы, устанавливается как веб-сервис на сервере Windows или Linux (с версии 3).

  • СУБД – на нем располагается база данных Tessa.

1.3. Аутентификация пользователей

Система обеспечивает прозрачную интеграцию с доменом Active Directory. При запуске клиентского приложения пользователь без ввода дополнительных параметров аутентифицируется системой как соответствующий пользователь домена и применяются соответствующие настройки профиля в системе Tessa.

Также в Tessa доступна аутентификация с помощью логина/пароля Tessa (указанных в справочнике сотрудников).

Администратор системы в карточке пользователя в справочнике сотрудников указывает тип входа в систему (Пользователь Windows/Пользователь Tessa), а также учетные данные (доменная учетная запись или логин/пароль пользователя Tessa), чтобы система могла идентифицировать пользователя (см Заведение нового пользователя/администратора в системе). Для безопасности хранения паролей сотрудников с типом входа Пользователь Tessa, в системе сохраняется хэш пароля.

Также возможен ручной ввод логина/пароля (учетной записи домена или локальной (на сервере приложений) учетной записи, или же логина/пароля пользователя Tessa).

1.4. Разворачивание системы - рекомендации

Настоятельно рекомендуется, при разворачивании системы обеспечить раздельные физические или виртуальные серверы для сервера приложений Tessa и для СУБД, где располагается база данных Tessa.

1.5. Системные требования

Требования к аппаратной конфигурации

Указаны примерные в расчёте на среднюю активность пользователей и могут отличаться в зависимости от нагрузки и развернутой конфигурации.
100 пользователей
Требования к серверу приложений:

Процессор: 4 ядра, 2GHz и выше
Оперативная память (RAM): 8Gb и более
Система хранения данных (HDD/SSD): от 200Gb

Требования к серверу баз данных:

Процессор: 4 ядра, 2,5GHz и выше
Оперативная память (RAM): 16Gb и более
Система хранения данных (HDD/SSD): от 300Gb, рекомендуется RAID, не менее 200 IOPS

1000 пользователей
Требования к серверу приложений:

Процессор: 8 ядер и более, 2GHz и выше
Оперативная память (RAM): 16Gb и более
Система хранения данных (HDD/SSD): от 200Gb

Требования к серверу баз данных:

Процессор: 12 ядер и более, 3GHz и выше
Оперативная память (RAM): 32Gb и более
Система хранения данных (HDD/SSD): от 1Tb, рекомендуется RAID, не менее 500 IOPS

Требования к программной конфигурации

Tessa может быть установлена на сервер Windows или Linux. За подробными требованиями к конфигурации серверов Windows и конфигурации клиентских компьютеров обратитесь к руководству по установке сервера приложений на Windows. Для установки сервера приложений на Linux обратитесь к руководству по установке сервера приложений на Linux.

2. Работа с Tessa Applications и приложениями

2.1. Настройка рабочего места и приложение Tessa Applications

На рабочем месте пользователя нужно установить:

  1. Для Windows 7 SP1 должен быть установлен .NET Framework 4.0 или выше. Для Windows 8.1 требования отсутствуют. Windows 10 должна быть обновлена минимум до версии 1607 (номер сборки 10.0.14393), или любая версия старше.

  2. Приложение Tessa Applications из комплекта поставки.

Приложение Tessa Applications выполняет следующие функции:

  • Выполняет логин и получает с сервера Tessa список доступных пользователю приложений.

  • Позволяет одновременно подключаться к разным серверам Tessa.

  • Устанавливает приложения в профиль пользователя.

  • При запуске приложения проверяет обновления и обновляет приложения.

  • В том числе обновляет само себя.

  • Открывает ссылки tessa://…​

В процессе установки необходимо будет указать адрес для подключения к серверу Tessa. Обычно он имеет вид https://servername/tessa.

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

Приложение Tessa Applications показывает доступные пользователю приложения. Предварительно приложения должны быть опубликованы администратором на сервере. Если пользователь администратор – то ему доступны и рабочее место администратора Tessa Admin, и рабочее место пользователя Tessa Client. Если у пользователя нет прав администратора, то по умолчанию ему доступно только рабочее место пользователя Tessa Client.

Второй важной задачей приложения является обработка ссылок на объекты СЭД Tessa. Если на компьютере установлен Tessa Applications, то при открытии ссылок вида tessa://tessaclient.tessa/…​ (так выглядят ссылки Tessa) – объект, на который ведет ссылка, откроется в приложении Tessa Client. При этом Tessa Applications и сам Tessa Client могут быть не запущены в момент открытия ссылки – они запустятся автоматически.

Также запустить Tessa Applications или сразу приложения Tessa Client/Tessa Admin можно с помощью ссылок: tessa://tessaappmanager, tessa://tessaclient.alias, tessa://tessaadmin.alias, где alias - это псевдоним сервера для запуска нужного приложения.

Псевдоним сервера должен совпадать со значением параметра ServerCode, указанном в конфигурационном файле сервера (более подробно см. Руководство по установке СЭД Tessa). Если данные значения не совпадают, то некорректно будет работать обработка ссылок Tessa для открытия карточек и файлов.

Если при запуске Tessa Applications не смог авторизоваться на сервере при использовании Windows-аутентификации (Kerberos\NTLM), то он выдаст приглашение на ввод логина\пароля.

Основное окно Tessa Applications выглядит следующим образом:

image176

Также, запущенное приложение видно в системном трее. Запускать приложения можно как из основной формы, так и из значка в трее:

image177

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

Если пользователю доступно только одно приложение, то оно запускается автоматически при запуске Tessa Applications.
Пользователь обязательно должен быть предварительно занесен в справочник сотрудников Tessa (см. Заведение нового пользователя/администратора в системе).

Также, если приложение уже запущено, есть возможность запустить второй экземпляр приложения: удерживая клавишу Ctrl нажать на приложение; или же с помощью контекстного меню - нажав правую кнопку мыши на приложении и выбрав "Запустить второй экземпляр приложения".

Речь идет только про ссылки, обрабатываемые "толстым" клиентом. Для легкого web-клиента ссылки имеют привычный формат https://servername/tessa/web/…​;.

Ссылки, с которыми умеет работать система, имеют вид:

tessa://tessaclient.tessa?param1=value1&param2=value2

В структуру ссылки входят:

  • Алиас приложения, для которого предназначается ссылка.

  • Код сервера. Определяет, для какого сервера будет запущено приложение.

  • Список параметров.

Существуют несколько типов ссылок:

  • Ссылка на карточку.

  • Ссылка на файл.

  • Ссылка на версию файла.

  • Ссылка на узел дерева.

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

При помощи механизма расширений можно определять новые типы ссылок.

В случае перехода пользователем по ссылке, Tessa Applications определяет по коду сервера и алиасу приложения, для какого приложения надо выполнить ссылку, и передаёт этому приложению соответствующую команду с набором параметров. Если ссылка не содержит кода сервера, то считается, что используется сервер, отмеченный в Tessa Applications как сервер по умолчанию. Если приложение не запущено, оно будет запущено автоматически. Tessa Applications также может быть не запущено в момент открытия ссылки - оно также запустится автоматически.

2.3. Публикация приложений

Публикация всех приложений выполняется автоматически при установке Tessa на этапе выполнения Setup.bat или Upgrade.bat. Описанные ниже способы публикации используются, если необходимо опубликовать какие-либо изменения в приложении (например, проектные клиентские расширения).

Публикация приложений может осуществляться двумя способами:

  1. При помощи специальных параметров запуска приложений и Tessa Applications. В этом случае приложения самостоятельно подключаются к серверу, указанному в параметрах командной строки или конфигурационном файле приложения и публикует само себя. Такой метод работает только для Windows. Этот подход описан в данном разделе.

  2. При помощи утилиты командной строки tadmin. Такой подход работает и на Windows и на Linux. Сначала приложение упаковывается в формат jcard при помощи команды PackageApp, а затем публикуется на сервере при помощи административного импорта.

Пример публикации TessaClient.

Откройте папку в командной строке Applications\TessaClient.

Выполните команду, заменив SERVER_NAME на сетевое имя сервера приложений:

TessaClient.exe /publish /a:https://SERVER_NAME/tessa

Приложение подключится к серверу, указанном в параметре /a, выполнит логин при помощи Windows-аутентификации и опубликует приложение, если логин успешен и у пользователя есть права администратора. Если сервер не задан, то будет использоваться сервер, указанный в конфигурационном файле приложения app.json.

Разрядность публикуемого приложения определяется автоматически, в папке "TessaClient" это 64-битная версия, в папке "TessaClient32" - 32-битная версия. Вы можете явно переопределить разрядность как 32-битную ключом /32bit, как 64-битную - ключом /64bit.
Разрядность доступных пользователю для скачивания приложений определяется исходя из разрядности операционной системы или настройки "Архитектура приложений" в карточке сотрудника (установить настройку может администратор, см. Заведение нового пользователя/администратора в системе).

Аналогичный пример для публикации TessaAdmin.

Откройте папку в командной строке Applications\TessaAdmin.

Выполните команду, заменив SERVER_NAME на сетевое имя сервера приложений:

TessaAdmin.exe /publish /a:https://SERVER_NAME/tessa /admin

Параметр /admin публикует приложение с установленным флажком "Только для администраторов".

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

При публикации можно указать логин/пароль по которыми будет производиться аутентификация. Пример такой публикации для Tessa Admin:

TessaAdmin.exe /publish /u:Admin /p:password /a:https://SERVER_NAME/tessa /admin

Так же примеры команд для публикации приложений есть в файлах publish_admin_demo.bat и publish_client_demo.bat для Tessa Admin и Tessa Client соответственно. Они находятся в папке "Applications" сборки платформы. Подробный список параметров можно найти в разделе Параметры командной строки приложений.

Опубликованные приложения становятся карточками системы специального типа "Приложение".

Список опубликованных приложений можно посмотреть в Tessa Client, вкладка Администратор, представление Прочее - Приложения. В представлении отображен список карточек всех опубликованных приложений:

image177 4

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

image177 5
При изменении приложении и/или их расширений необходимо повторять публикацию, чтобы Tessa Applications мог обновить данные на рабочем месте пользователя.

Каждый раз при запуске приложения Tessa Applications получает с сервера информацию о списке файлов, опубликованных на сервере, и хеши от их контента. Далее проверяются локальные файлы приложения в профиле пользователя, если они отличаются по составу или хэшу - с сервера получаются необходимые файлы и обновляются\создаются\удаляются локальные файлы.

Tessa Applications умеет обновлять сам себя. Для этого нужно опубликовать приложение Tessa Applications (TessaAppManager.exe) на сервере как любое другое приложение. При запуске Tessa Applications проверяет наличие обновлений на сервере по умолчанию (отмечен звёздочкой в списке серверов). Если обновление есть, то оно загружается, затем Tessa Applications перезапускается.

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

Отключить автообновление Tessa Applications у конкретного пользователя можно, выставив на вкладке "Серверы" соответствующий флаг:

image177 7
Выставление данного флага никак не влияет на обновление приложений на любых серверах.

2.3.1. Публикация Deski

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

О том, как пользователи могут скачать и установить Deski описано в Руководстве пользователя. А чтобы пользователи смогли скачать данное приложение, оно должно быть опубликовано.

Установщик Deski не требует прав администратора.

Публикация Deski выполняется автоматически при установке Tessa на этапе выполнения Setup.bat или Upgrade.bat, используя консольную команду tadmin. Если система была установлена вручную без задействования скриптов или же автоматическая публикация по каким-то причинам не прошла, то опубликовать Deski можно вручную с помощью консольной утилиты tadmin, используя команду PackageWebApp.

Чтобы опубликовать приложения Deski для любых операционных систем, можно создать bat файл со следующим содержанием:

Tools\tadmin PackageWebApp "DeskiSetup\Windows\en-US\x86\TessaDeski.msi" /out:app\deski.win32.en.jcard "/n:Windows 32 bit" /d:$Common_WebApplications_Description_Win32 /lang:en /os:Windows

Tools\tadmin PackageWebApp "DeskiSetup\Windows\ru-RU\x86\TessaDeski.msi" /out:app\deski.win32.ru.jcard "/n:Windows 32 bit" /d:$Common_WebApplications_Description_Win32 /lang:ru /os:Windows

Tools\tadmin PackageWebApp "DeskiSetup\Windows\en-US\x64\TessaDeski.msi" /out:app\deski.win64.en.jcard "/n:Windows 64 bit" /d:$Common_WebApplications_Description_Win64 /lang:en /os:Windows /64bit

Tools\tadmin PackageWebApp "DeskiSetup\Windows\ru-RU\x64\TessaDeski.msi" /out:app\deski.win64.ru.jcard "/n:Windows 64 bit" /d:$Common_WebApplications_Description_Win64 /lang:ru /os:Windows /64bit

Tools\tadmin PackageWebApp "DeskiSetup\Linux\x64\deski.zip" /out:app\deski.linux64.jcard "/n:Linux 64 bit" /d:$Common_WebApplications_Description_Linux64 /os:Linux /64bit

Tools\tadmin PackageWebApp "DeskiSetup\macOS\deski.zip" /out:app\deski.macos.jcard "/n:macOS" /d:$Common_WebApplications_Description_macOS /os:macOS /64bit

Tools\tadmin ImportCards app /a:https://SERVER_NAME/tessa /u:admin /p:admin /e

rd /S /Q app

Посмотреть карточки опубликованных приложений можно в Tessa Client, вкладка Администратор → Прочее → Приложения Web.

2.4. Подключение к другому серверу Tessa

В случае, если пользователю требуется доступ на разные сервера Tessa (например, один - рабочий, второй - тестовый), то необходимо в Tessa Applications добавить нужный сервер:

  1. Перейти на вкладку Сервер и нажать на кнопку Добавить:

    image177 1

    В окне добавления сервера укажите псевдоним и адрес тестового веб сервиса Tessa:

    image177 2

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

    Псевдоним сервера должен совпадать со значением параметра ServerCode, указанном в конфигурационном файле сервера (более подробно см. Руководство по установке СЭД Tessa). Если данные значения не совпадают, то некорректно будет работать обработка ссылок Tessa для открытия карточек и файлов.
  2. В результате в Tessa Applications вы увидите доступные приложения с разных серверов:

    image177 3
Для отображения приложений добавленного сервера необходимо, чтобы они были опубликованы на сервере и у вас были права доступа к данным приложениям (см. Руководство по установке СЭД Tessa).

Также добавить новый сервер в Tessa Applications можно с помощью специальных ссылок (см. Ссылки для добавления/изменения/удаления серверов в Tessa Applications).

Настройки подключения к серверам Tessa Applications хранятся в xml файле - application_catalogs.xml. Если Tessa Applications установлен в режиме для пользователя, то файл можно найти по пути: C:\Users\<UserName>\AppData\Roaming\tessa\settings\application_catalogs.xml. Если же Tessa Applications установлен в режиме для всех пользователей, то данный файл хранится в папке установки: C:\Program Files\Syntellect\Tessa Applications\app\application_catalogs.xml.

При запуске Tessa Applications считывает настройки подключений к серверам из данного файла. Имя пользователя и пароль (если они указаны для сервера) хранятся в данном файле в зашифрованном виде.

2.5. Права доступа к приложениям

По умолчанию для опубликованных приложений установлены следующие права доступа:

  • Tessa Client - приложение доступно всем сотрудникам;

  • Tessa Admin - доступно Администраторам системы (т.е пользователям, в карточке сотрудника которых установлен уровень доступа - Администратор).

Настроить права доступа к приложениям можно с помощью карточек приложений. В Tessa Client, вкладка Администратор, представление Прочее - Приложения отображен список карточек всех опубликованных приложений:

image177 4

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

image177 5

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

Флаг Только для администраторов выставляется в случае, если приложение должно быть доступно только Администраторам системы (как, например, приложение Tessa Admin).

Независимо от настроенных прав доступа к приложениям, Администратору системы всегда будут доступны все опубликованные приложения.

2.6. Группировка приложений

При необходимости опубликованные приложения можно сгруппировать (для удобства отображения в Tessa Applications).

В карточке приложения (Tessa Client, вкладка Администратор, представление Прочее - Приложения) в поле Группа для нужных приложений указываем название группы.

После обновления в Tessa Applications приложения будут сгруппированы. Можно выбрать группировку по серверам или по группам:

image177 6

2.7. Ссылки для добавления/изменения/удаления серверов в Tessa Applications

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

  • Для добавления/изменения одного из серверов в Tessa Applications используется ссылка в следующем формате:

    tessa://tessaappmanager?Action=ServerParam&Alias=alias&Path=path&UserName=username&Password=password&IsDefault=true

    • Alias - алиас сервера, который добавляется/изменяется, например: prod;

    • Path - адрес сервера, например: https://tessa-server/tessa;

    • UserName - имя пользователя, если аутентификация не доменная;

    • Password - пароль (указывается, если было задано имя пользователя);

    • IsDefault - true, если сервер назначается основным (т.е. тем, с которого Tessa Applications будет загружать обновления для себя самого). Если не основной - false.

      Все параметры необязательны, однако имеет смысл указать хотя бы один параметр при изменении сервера, и хотя бы Alias/Path при добавлении нового сервера.
  • Для удаления сервера в Tessa Application используется ссылка в следующем формате:

    tessa://tessaappmanager?Action=RemoveServer&Alias=alias

    • Alias - алиас удаляемого сервера.

2.8. Работа удаленных пользователей

Необходимо сразу заметить, что все приложения, включая Tessa Applications – взаимодействуют с сервером приложений по протоколу https (обычно это 443 порт).

Например, внутри локальной сети предприятия сервер Tessa доступен по пути https://tessa-ecm/tessa. Один из сотрудников работает из внешней сети, и у него нет доступа к этому адресу. Администраторы настроили сеть таким образом, что извне Tessa доступна по пути https://tessa.company.ru/tessa. В этом случае удаленному пользователю необходимо в Tessa Applications добавить новый сервер с адресом подключения https://tessa.company.ru/tessa (см Подключение к другому серверу Tessa или Ссылки для добавления/изменения/удаления серверов в Tessa Applications).

Однако самым безопасным способом доступа извне к серверу Tessa является доступ через VPN в сеть предприятия и затем уже доступ в Tessa поверх VPN.

2.9. Изменение расположения папки для загруженных приложений

Настройка расположения папки для загруженных приложений производится в конфигурационном файле %appdata%\tessa\settings\application_catalogs.xml в параметре t:AppPath, по умолчанию указана папка %localappdata%\tessa.

В параметре можно указать любой путь к папке загруженных приложений (подпапка applications от заданного пути) с учётом переменных окружения (%appdata%, %localappdata% и др.), в т.ч. указать путь, не являющийся частью переносимого профиля %appdata%.

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

Приложение Tessa Applications скачивается и обновляется по пути, указанному в конфигурационном файле %ProgramFiles(x86)%\Syntellect\Tessa Applications\TessaAppLauncher.exe.config в параметре LocalAppPath, по умолчанию это папка %LocalAppData%\tessa (подпапка appmanager, appmanager_update и др.). Путь также можно переопределить в переменной окружения %Tessa.LocalAppPath%. Эта настройка работоспособна только для версии Tessa Applications 3.5.0 (и выше), установленной через msi-пакет (а не путем обновления с предыдущей версии).

2.10. Параметры командной строки приложений

Tessa Admin и Tessa Client

Параметр

Описание

/a

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

/u

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

/p

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

/publish

Инициирует процесс публикации приложения.

/q

Включает режим тихой публикации, при которой на экран не выводится сообщений, отключается GUI и окно входа (если требуются логин/пароль), а любые ошибки и сообщения логируются. Используется только вместе с параметром /publish.

/64bit

Указывает, что публикуемое приложение использует 64-битную архитектуру. Если не указан этот ключ или /32bit, то используется фактическая разрядность процесса с запускаемым файлом. Используется только вместе с параметром /publish.

/32bit

Указывает, что публикуемое приложение использует 32-битную архитектуру. Если не указан этот ключ или /64bit, то используется фактическая разрядность процесса с запускаемым файлом. Используется только вместе с параметром /publish.

/admin

При публикации приложения устанавливает признак "только для администраторов".

/link

Запуск для обработки ссылки. В параметр передаются только параметры ссылки после ?., например: TessaClient.exe "/link:Action=MyAction&Param1=value1". Удобно для отладки.

Tessa Applications

Параметр

Описание

/a

Задаёт базовый адрес подключения. Используется только вместе с параметром /publish.

/u

Позволяет явно задать имя пользователя для аутентификации на сервере. Используется только вместе с параметром /publish, иначе игнорируется.

/p

Позволяет явно задать пароль для аутентификации на сервере. Используется только вместе с параметром /publish, иначе игнорируется.

/publish

Инициирует процесс публикации приложения.

/q

Включает режим тихой публикации, при которой на экран не выводится сообщений, отключается GUI и окно входа (если требуются логин/пароль), а любые ошибки и сообщения логируются. Используется только вместе с параметром /publish.

/64bit

Указывает, что публикуемое приложение использует 64-битную архитектуру. Если не указан этот ключ или /32bit, то используется фактическая разрядность процесса с запускаемым файлом. Используется только вместе с параметром /publish.

/32bit

Указывает, что публикуемое приложение использует 32-битную архитектуру. Если не указан этот ключ или /64bit, то используется фактическая разрядность процесса с запускаемым файлом. Используется только вместе с параметром /publish.

/link

Запуск для обработки ссылки. В параметр передается ссылка целиком, например: TessaAppManager.exe "/link:tessa://server.alias?Action=MyAction&Param1=value1".

/autostart

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

2.11. Логирование

Полезно знать, где располагаются файлы логов Tessa Applications. Определяются они файлом NLog.config рядом с выполняемыми файлами TessaAppLauncher.exe (располагается в папке установки, по умолчанию "%ProgramFiles(x86)%\Syntellect\Tessa Applications\") и TessaAppManager.exe (при первичной установке располагается в папке установки, по умолчанию "%ProgramFiles(x86)%\Syntellect\Tessa Applications\app", если были обновления Tessa Applications, то в папке профиля пользователя %APPDATA%\tessa\appmanager). Там же определяется уровень логирования (по умолчанию логируются только ошибки).

По умолчанию логирование настроено в текстовые файлы и журнал приложений Windows. Текстовые файлы:

  • %APPDATA%\tessa\logs\AppManager.txt

  • %APPDATA%\tessa\logs\AppLauncher.txt

2.12. Настройки приложений

У приложений есть конфигурационные файлы, в которых хранятся некоторые настройки, которые могут быть полезны в тех или иных случаях. Ниже описаны данные настройки и в каких случаях имеет смысл их менять. Конфигурационные файлы app.json и расположены рядом с соответствующими выполняемыми файлами.

Включение аппаратного ускорения при выводе на экран

Включение данной настройки может исправить ошибки совместимости с приложениями, которые организуют терминальные сессии. Для включения аппаратного ускорения при выводе на экран в desktop-приложениях TessaClient, TessaAdmin и Tessa Applications в конфигурационном файле app.json в параметре SoftwareRendering необходимо указать true.

Включение данной настройки замедляет работу приложения, но может исправить ошибки совместимости с приложениями, которые организуют терминальные сессии. Используйте настройку с осторожностью, только в ситуации, когда она исправляет существующие ошибки, и предварительно убедившись в её работоспособности на компьютерах пользователей. Если эта настройка включена, то также установите настройку FadeAllowed равную false в том же конфигурационном файле.
Включение библиотеки для работы с современными сканерами

В конфигурационном файле app.json параметр NewTwainDSM определяет, будет ли использоваться библиотека twaindsm.dll (значение true), предоставляющая доступ к новым версиям API TWAIN для работы с современными сканерами, или же используется библиотека twain_32.dll (значение false), которая обеспечивает лучшую совместимость со старыми моделями сканеров.

Значение по умолчанию false также подходит для большинства современных сканеров. Установите значение true только в том случае, если наблюдаются проблемы с некоторыми сканерами.

Прочие параметры приложений.

2.12.1. Tessa Client

Параметр Пример значения Описание

RemoteAddress

https://localhost/tessa

Адрес сервера приложений с установленными сервисами Tessa

FadeAllowed

true

Включить затемнение при неактивном окне приложения (может быть полезным при работе в терминале).

ExtensionTracingMode

Off

Режим трассировки

2.12.2. Tessa Admin

Параметр Пример значения Описание

RemoteAddress

https://localhost/tessa

Адрес сервера приложений с установленными сервисами Tessa

2.12.3. Scheme Editor

Параметр

Пример значения

Описание

connectionStrings

<add name="default" connectionString="Server=.\SQLEXPRESS;Database=tessa;Integrated Security=false;User ID=sa;Password=password;Connect Timeout=200; Pooling=True; Max Pool Size=200; MultipleActiveResultSets=False" providerName="System.Data.SqlClient" />

Строка подключения к базе данных, с которой работают сервисы Tessa

3. Механизмы разграничения доступа

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

Дискреционная безопасность

Дискреционная безопасность - это уровень доступа (Пользователь/Администратор), который задается в карточке сотрудника. Используется в следующих случаях:

  • Для приложений, опубликованных как "административный". Например, Tessa Admin, опубликованный с параметром /admin будет доступен только сотрудникам с уровнем доступа Администратор.

  • Для карточек с флагом "административный". Т.е. сотруднику с уровнем доступа Администратор будут доступны все глобальные настройки (правая панель – меню Настройки), редактирование всех типов ролей, объектов маршрутов (шаблоны этапов, группы, вторичные процессы, методы расширений).

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

    Пользователю также можно выдать права на редактирование карточек сотрудников и подразделений, за исключением редактирования карточек сотруников с административным доступом. Как это настроить описано в разделе Выдача прав пользователям на создание карточек сотрудников.
  • Администратор может закрывать сессии других сотрудников.

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

  • Администратору доступен просмотр истории действий.

  • Администратор может восстанавливать удаленные карточки или удалять их окончательно (см. Работа с удаленными карточками).

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

Ролевая безопасность
  • По роли определяется доступ к разным объектам системы, которые не являются административными: к карточкам документов (по правилам доступа), к замещениям других сотрудников, к шаблонам карточек и файлов, к кнопкам маршрутов и др.

  • По вхождению в ту или иную роль пользователь видит представление со списком каких-то объектов (например, реестр документов и основную информацию по документам, отображенную в колонках).

  • По роли определяется видимость задач, а видимость задач в свою очередь влияет на возможность открыть карточку и подписывать в ней файлы; эти права выдаются "мимо" правил доступа. Более подробно см. раздел Система прав доступа к карточкам, включенным в типовое решение.

4. Заведение нового пользователя/администратора в системе

Для того, чтобы сотрудник мог войти в систему, должно выполняться следующее условие:

  • Для сотрудника должна быть заведена карточка в справочнике сотрудников и в ней должен быть указан его аккаунт (если тип входа в систему - Пользователь Windows или Пользователь LDAP) или логин/пароль (если тип входа в систему - Пользователь Tessa).

4.1. Создание карточки сотрудника

Для того чтобы завести нового пользователя в системе и тем самым дать ему доступ к приложениям, рабочим местам и представлениям необходимо создать карточку нового сотрудника с помощью правого меню "Создать карточку → Роли → Сотрудник":

image173

В карточке сотрудника необходимо указать: Фамилию, Имя и Отчество. Краткое и полное имя можно не указывать, тогда система сгенерирует их самостоятельно в формате Фамилия И. О. и Фамилия Имя Отчество соответственно. Далее выбрать Тип входа в систему и, в зависимости от выбранного типа, заполнить данные для доступа в систему:

  • Пользователь Windows - указать доменный аккаунт в формате домен\имя пользователя;

  • Пользователь LDAP - указать аккаунт;

  • Пользователь Tessa - указать логин, пароль и повтора пароля.

А также выбрать Уровень доступа - Обычный или Администратор.

image174

Поле Архитектура приложений определяет то, какие приложения (32-разрядные или 64-разрядные) будут скачиваться приложением Tessa Applications, когда опубликованы приложения обеих разрядностей.

  • Значение Автоматически соответствует архитектуре, которое известно для Tessa Applications новой версии 3.5.0 (или старше), но для предыдущих его версий архитектура определяется как 32-разрядная.

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

  • Значение предпочитать 64-битные приложения - аналогично использует 64-разрядные приложения кроме того случая, когда Tessa Applications новой версии (3.5.0 или старше) явно сообщает серверу, что ОС пользователя является 32-разрядной.

Узнать какой разрядности запускаются у пользователя приложения можно из Истории действий в записи "Вход в систему". Значение "неизвестно" означает, что приложение, выполнившее вход, не передало информацию по разрядности.

Также в карточке сотрудника можно указать электронную почту (если сотруднику нужно получать уведомления) и Язык уведомлений по умолчанию.

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

Блок Синхронизация с Active Directory / LDAP используется для отображения информации по синхронизации, а также запуска ручной синхронизации (более подробно см. Синхронизация с Active Directory / LDAP).

После того, как все необходимые данные сотрудника заполнены, нужно нажать кнопку "Сохранить" в левом меню системы.

image175

В течение 30 минут (после добавления сервисом Chronos сотрудника в роль "Все сотрудники") новый пользователь получит доступ к рабочему месту и представлениям, доступным пользователям по умолчанию. Вы можете перезапустить сервис Chronos, чтобы пересчёт роли выполнился сразу же (в течение 1-2 минут).

Загрузить большое количество Сотрудников в Tessa можно с помощью синхронизации с Active Directory / LDAP или утилиты tadmin.

4.2. Выдача прав пользователям на создание карточек сотрудников

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

  • Пользователь не может создавать сотрудников с административным доступом,

  • Пользователь не может копировать карточки сотрудников,

  • Пользователь не может редактировать карточки сотрудников с административным доступом.

Для назначения доступа на создание/редактирование карточек сотрудников необходимо тип карточки "Сотрудник" добавить в настройки типового решения (правое меню → Настройки → Типовое решение → добавить строку в таблицу "Типы карточек").

После того, как тип карточки "Сотрудник" добавлен в типовое решение, для него начинают работать типовые правила доступа. Т.е. никто, даже администратор, не сможет создавать/редактировать сотрудников, пока не будут настроены соответствующие правила доступа.

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

image380

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

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

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

Помимо прав на создание/редактирование карточек сотрудников таким же образом можно выдать права на карточки подразделений.

5. Синхронизация с Active Directory / LDAP

5.1. Описание модуля

Модуль предназначен для синхронизации с Active Directory / LDAP карточек Сотрудников, Подразделений и Статических ролей.

Модуль не входит в типовую поставку и приобретается отдельно.
Начиная с версии 3.3 синхронизация совместима с протоколом LDAPv3.

Посмотреть информацию о доступных модулях, включённых в лицензию можно в приложении Tessa Admin, раздел "Информация":

image337

Данный модуль может выполнять:

  • периодическую синхронизацию данных в указанные моменты времени;

  • синхронизацию данных по запросу пользователя (вручную).

Модуль синхронизирует:

  • Карточки Сотрудников:

    • ФИО,

    • Логин,

    • Email,

    • Телефон,

    • Мобильный телефон,

    • Домашний телефон,

    • IP телефон,

    • Факс,

    • Должность.

Маппинг полей (тип объекта person / user):

Параметр в Active Directory / LDAP

Параметр в Tessa ([таблица].[поле])

Описание

sAMAccountName / uid

PersonalRoles.Login

Логин пользователя.

sn

PersonalRoles.LastName

Фамилия.

middleName

PersonalRoles.MiddleName

Отчество.

givenName

PersonalRoles.FirstName

Имя.

cn

PersonalRoles.FullName

Полное имя.

facsimileTelephoneNumber

PersonalRoles.Fax

Факс.

telephoneNumber

PersonalRoles.Phone

Телефон.

homePhone

PersonalRoles.HomePhone

Домашний телефон.

mobile

PersonalRoles.MobilePhone

Мобильный телефон.

IpPhone

PersonalRoles.IPPhone

IP телефон.

title

PersonalRoles.Position

Должность.

userAccountControl

PersonalRoles.LoginTypeID

Тип входа пользователя (Active Directory/LDAP/Отключен).

name

Roles.Name

Название.

whenChanged / modifyTimestamp

Roles.AdSyncWhenChanged

Дата изменения объекта.

distinguishedName

Roles.AdSyncDistinguishedName

Уникальное имя объекта.

Фамилия, имя и отчество берутся из указанных выше параметров или на основании параметров cn, name, displayName (если параметры из таблицы пусты).

  • Карточки Подразделений:

    • Название подразделения,

    • Глава подразделения,

    • Сотрудники, входящие в подразделение.

Маппинг полей (тип объекта organizationalUnit):

Параметр в Active Directory / LDAP

Параметр в Tessa ([таблица].[поле])

Описание

managedBy

DepartmentRoles.HeadUserID

Руководитель подразделения

description

Roles.Description

Описание объекта.

whenChanged / modifyTimestamp

Roles.AdSyncWhenChanged

Дата изменения объекта.

distinguishedName

Roles.AdSyncDistinguishedName

Уникальное имя объекта.

  • Карточки Статических ролей:

    • Имя роли,

    • Описание роли,

    • Сотрудники, входящие в статическую роль.

Маппинг полей (тип объекта group / ipausergroup / posixgroup):

Параметр в Active Directory / LDAP

Параметр в Tessa ([таблица].[поле])

Описание

name

Roles.Name

Название.

description

Roles.Description

Описание объекта.

whenChanged / modifyTimestamp

Roles.AdSyncWhenChanged

Дата изменения объекта.

distinguishedName

Roles.AdSyncDistinguishedName

Уникальное имя объекта.

Если в Active Directory / LDAP удален (или заблокирован) сотрудник, удалены подразделение или группа, то после синхронизации в соответствующих карточках Tessa выставится флаг "Скрывать при выборе". В карточке Сотрудника, помимо этого, поменяется тип входа на "Вход воспрещён".

5.2. Автоматическая синхронизация

Для автоматической синхронизации необходимо включить основной плагин AdSyncPlugin и плагин периодической синхронизации AdSyncRecurrentPlugin, выставив в соответствующих конфигурационных xml файлах disabled="false". Все конфигурационные файлы плагинов сервиса Chronos хранятся в папке Chronos\Plugins\Tessa\configuration. Более подробно про плагины см. в разделе Настройка плагинов Chronos.

Затем необходимо настроить конфигурационный файл Chronos\app.json, добавив в раздел "Settings" строки, указанные ниже.

Для запуска синхронизации должны быть заполнены следующие параметры: AdSync.Server, AdSync.User, AdSync.Password. Остальные параметры являются опциональными и заполняются при необходимости.

Список настроек:

Параметр

Пример значения

Описание

"AdSync.Server"

"192.168.0.1"

Контроллер домена.

"AdSync.Port"

389

Порт контроллера домена. По умолчанию 389.

"AdSync.TimeoutMilliseconds"

0

Таймаут на подключение к контроллеру домена. По умолчанию 0 - без ограничений.

"AdSync.UserDomain"

"domain"

Домен пользователя, может отличаться от серверного, например, пользователь входит в домен test.test.com, а контроллер домена находится на test.com.

"AdSync.User"

"administrator"

Логин пользователя в домене. Можно передать как domain\administrator и не использовать параметр AdSync.UserDomain.

"AdSync.Password"

"Master1234"

Пароль пользователя, используется вместе с "ADSync.User".

"AdSync.UseSSL"

false

Использовать SSL шифрование.

"AdSync.ConnectionAttemptCount"

10

Количество попыток соединения с реферальными серверами. По умолчанию 10.

"AdSync.ConnectionAttemptIdle"

10

Пауза между попытками соединения с реферальными серверами в секундах. По умолчанию 10.

"AdSync.SkipReferral"

false

Отключение поиска по всем реферальным серверам.

"AdSync.SkipReferralList"

["DC=ForestDnsZones,DC=company,DC=com", "DC=DomainDnsZones,DC=company,DC=com"]

Отключение поиска по списку реферальных серверов.

"AdSync.SkipSystemPartitions"

true

Игнорирование системных разделов, таких как ForestDnsZones, DomainDnsZones, Configuration.

Далее необходимо открыть карточку "Синхронизация AD / LDAP" (правое меню в Tessa Client - "Настройки→Синхронизация AD / LDAP") и заполнить eё:

image338
  • В поле "Группа синхронизации сотрудников" указывается DN группы, из которой будут синхронизироваться сотрудники. В случае, если поле не заполнено, будут синхронизированы все сотрудники из корневых элементов;

  • Флаг "Не переименовывать статические роли" позволяет не изменять имя роли в соответствии с именем в LDAP для созданных в системе статических ролей;

  • В таблице "Корневые элементы синхронизации (OU)" указываются OU, которые вместе с иерархией дочерних переносятся в карточки Подразделений, а элементы – в карточки Сотрудников/Статических ролей. Задаются в формате DN. Можно выбрать тип объекта для синхронизации;

  • Блок "Периодическая синхронизация" отвечает за периодическую синхронизацию и позволяет отключить синхронизацию конкретных видов карточек;

  • Блок "Ручная синхронизация" позволяет запустить ручную синхронизацию конкретных типов объектов.

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

    Если ни один корневой элемент не задать, синхронизация Сотрудников, Подразделений и Статических ролей работать не будет.

Автоматическая синхронизация будет выполняться сервисом Chronos с периодом, указанным в плагине AdSyncRecurrentPlugin. По умолчанию плагин запускается раз в сутки в полночь.

5.3. Ручная синхронизация

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

Предварительно необходимо выполнить все настройки, описанные в разделе Автоматическая синхронизация (кроме включения плагина AdSyncRecurrentPlugin).

Запустить полную синхронизацию Сотрудников, Подразделений или Статических ролей можно открыв карточку настроек "Синхронизация AD / LDAP" и нажав на соответствующие кнопки в блоке "Ручная синхронизация":

image339

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

Также, при необходимости, можно выполнить синхронизацию отдельного объекта, т.е. конкретной карточки Сотрудника, Подразделения или Статической роли. Открыв нужную карточку необходимо раскрыть блок "Синхронизация с Active Directory / LDAP", нажав левой кнопкой мыши на названии блока. По умолчанию во всех карточках он свёрнут.

image340

В раскрывшемся блоке есть следующие поля:

image341
  • Дата последней синхронизации - дата и время последней синхронизации текущей карточки;

  • Дата последнего изменения - дата и время последнего изменения текущего объекта в Active Directory / LDAP;

  • Уникальное имя (DN) - уникальное имя объекта в Active Directory / LDAP;

  • Active Directory / LDAP ID - идентификатор объекта в Active Directory / LDAP;

  • Синхронизация отключена - флаг для отключения синхронизации текущей карточки;

  • Синхронизируется независимо от корневых элементов - флаг для синхронизации, даже если объект не принадлежит к дереву корневых элементов;

  • Кнопка "Запустить ручную синхронизацию" - кнопка для запуска ручной синхронизации текущей карточки.

В случае, если необходимо связать уже созданные в Tessa Подразделения, Сотрудников или Статические роли, то можно заполнить поле "Уникальное имя (DN)" и выполнить ручную синхронизацию. Синхронизация найдет запись в домене по указанному DN и свяжет записи между собой. Связывание выполняется по атрибуту objectGuid.

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

5.4. Алгоритм работы синхронизации

После того, как операция синхронизации была создана вручную или периодическим плагином Chronos (AdSyncRecurrentPlugin), её подхватывает плагин AdSyncPlugin, который обрабатывает операции раз в 30 секунд (по умолчанию, настраивается в configuration/AdSyncPlugin.xml).

В первую очередь проверяется возможность перерасчёта ролей (раздел Активные операции). Если плагин не смог взять эксклюзивную блокировку (потому что длительное время выполнялась другая операция с ролями, такая как пересчёт замещений), то в лог пишется предупреждение, работа плагина при этом завершается (до следующего запуска).

После взятия блокировки из операции извлекается тип операции: синхронизация отдельной карточки или всех объектов.

  1. Если выполняется синхронизация отдельной карточки (например, по кнопке в карточке сотрудника):

    1. Для заданного типа проверяются все объекты с заполненным DN, но пустым AdSyncID, и выполняется поиск соответствий для объектов в системе и в Active Directory / LDAP.

    2. После этого по AdSyncID синхронизируемой карточки запрашивается объект из Active Directory / LDAP.

    3. После получения объекта выполняется синхронизация значений его свойств.

  2. Если выполняется синхронизация всех объектов:

    1. Проверяются все объекты с заполненным DN, но пустым AdSyncID, и выполняется поиск соответствий для объектов в системе и в Active Directory / LDAP.

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

    3. Если принадлежат, то выполняется синхронизация выбранных в настройках объектов.

    4. После того, как рекурсивно будет пройден весь лес Active Directory / LDAP, проверяются объекты в системе, у которых выставлен флаг "Синхронизируется независимо от корневых элементов". Такие объекты синхронизируются как отдельные карточки (см выше).

    5. После завершения синхронизации, если не было никаких ошибок, происходит скрытие элементов, которые не были обновлены системой, - такие объекты считаются удалёнными в домене, и поэтому для них устанавливается флаг "Скрывать при выборе", фактического удаления не происходит.

6. Роли

Роли используются для отправки заданий и для назначения прав доступа.

Для каждой роли в системе создается отдельная карточка. В системе Tessa предусмотрено несколько типов ролей:

  • Сотрудник - карточка сотрудника;

  • Подразделение - в составе роли подразделения указываются сотрудники. Можно создать любую древовидную структуру подразделений, указывая "Родительское подразделение" в карточке подразделения;

  • Статическая роль - статическая роль, в состав которой добавляются нужные сотрудники. Может использоваться для настройки прав доступа или отправки заданий на всех сотрудников роли;

  • Контекстная роль - роль, зависящая от контекста карточки. Например, в типовом решении есть настроенные контекстные роли: Руководитель Инициатора (сотрудник, являющийся руководителем подразделения, в которое входит Инициатор процесса согласования); Автор документа (сотрудник, указанный в карточке документа в поле "Автор") и т.д.

    Некоторые факты о контекстной роли: при отправке задания на контекстную роль, система автоматически создает временную роль, куда включает вычисленных по SQL запросу контекстной роли сотрудников; при попытке пользователем создания карточки, система в правилах доступа не учитывает контекстные роли (т.к. пока нет карточки - нет контекста); нельзя предоставлять доступ к представлениям и отчетам для контекстных ролей (т.к. нет контекста карточки).
  • Метароль - роль, автоматически создаваемая генератором метаролей по заданному запросу. Пример генератора метаролей, входящий в типовую конфигурацию - "Агрегатные роли" - для каждого подразделения, имеющего дочерние подразделения, автоматически создается метароль с названием Имя_подразделения (все). В роль входят все сотрудники текущего подразделения, а также все сотрудники всех дочерних подразделений. Можно создать свои генераторы метаролей (более подробно о генераторе ролей можно посмотреть в Руководстве разработчика).

  • Динамическая роль - роль, автоматически пересчитываемая по указанному SQL запросу плагином сервиса Chronos. Например, роль "Все сотрудники".

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

Просмотреть список всех карточек ролей можно из рабочего места Администратора, представление – Роли:

image159

6.1. Создание новой роли

Создать новую роль в системе можно с помощью правого меню системы: Создать карточку – Роли – выбрать тип создаваемой роли.

Создание карточки нового сотрудника описано в разделе Заведение нового пользователя/администратора в системе.

Загрузить большое количество Сотрудников, Подразделений и Статических ролей в Tessa можно с помощью синхронизации с Active Directory / LDAP, а с помощью утилиты tadmin можно загрузить Сотрудников и Подразделения.

6.2. Пересчёт ролей

Пересчёт состава роли выполняется для динамический ролей и метаролей сервисом Chronos с заданным в карточке роли периодом.

Метароли автоматически создаются/пересчитываются с помощью генератора метаролей. Карточки генераторов метаролей можно найти на рабочем месте Администратор → Прочее → Генераторы метаролей.

В карточке динамической роли и генератора метаролей есть следующие настройки пересчёта:

image397
  • Период в секундах - частота пересчёта роли, указывается, если не заполнено поле "Выражение Cron". Пересчёт будет выполнен при запуске сервиса Chronos и далее с указанной частой.

  • Выражение Cron - расписание запуска пересчёта, указывается, если не заполнено поле "Период в секундах". Более подробно описание формата Cron можно посмотреть по ссылке.

  • Запланировать пересчёт при запуске сервиса Chronos - если пересчёт запланирован по выражению Cron, то при запуске или перезапуске сервиса Chronos пересчёт выполняется сразу же только в том случае, если включена эта опция. Если пересчёт выполняется по указанному периоду, то при запуске сервиса пересчёт выполняется, независимо от этой опции.

    Например, выражение Cron может быть "в начале каждого часа с 8 утра до 8 вечера каждого дня". Если сервис Chronos запущен в 13:15, то первый пересчёт произойдёт в 14:00, если флаг не выставлен. С установленным флагом пересчёт будет сразу же, а потом по расписанию, т.е. в 14:00, в 15:00 и т.д.

  • Кнопка Пересчитать роль сейчас/Пересчитать генератор метаролей сейчас - рассчитывает динамическую роль/метароли в текущий момент. Расчёт может занять какое-то время, в зависимости от данных в БД, от сложности SQL запроса в роли, от нагрузки системы и т.п.

    Кнопку можно нажать и при параллельно работающем сервисе Chronos, и без него. Если Chronos параллельно считает какую-то другую роль, то расчёт по кнопке будет запущен после того, как Chronos закончит работу.

    Как и в случае расчёта в Chronos, в представлении "Администратор → Прочее → Активные операции" будет отображена операция с типом «Расчёт ролей» и с названием, например, «Динамическая роль: Все сотрудники».

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

Замещения в ролях пересчитываются плагином DeputiesRecalc с периодом, заданным в настройках данного плагина. Вручную запустить пересчёт заместителей из Tessa Client не получится, необходимо дождаться выполнения плагина, перезапустить сервис Chronos, или выполнить команду пересчёта ролей в консольной утилите tadmin.

Пересчёт всех или отдельных ролей, а также заместителей может выполняться с помощью команды ManageRoles консольной утилиты tadmin.

6.3. Особенности работы замещений

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

  • Каждый сотрудник может самостоятельно настроить себе заместителей (см. Руководство пользователя).

  • Замещение может быть постоянное или на указанный период.

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

  • Заместитель в системе может работать параллельно с замещаемым сотрудником.

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

  • Если заместитель взял задание в работу, то оно становится не доступно основному исполнителю.

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

  • Заместитель получает все права доступа замещаемой роли, в том числе права доступа к представлениям, права на чтение/редактирование карточек, расширенные права доступа, права на отчеты, права, выдаваемые этапом маршрута и т.д.

    Заместитель по типу роли "Сотрудник" (когда указаны ФИО замещаемого или одна из служебных ролей "Лично я"/"Все роли и подразделения") получает уровень доступа замещаемого сотрудника. Т.е. если Пользователя указать заместителем Администратора, то на период замещения такой Пользователь станет Администратором, в том числе с доступом к рабочему месту Администратора и приложению Tessa Admin (если оно опубликовано).
  • Замещения во временной роли "Исполнители задания" (например, когда отправляется одна общая типовая задача на несколько сотрудников) не пересчитываются. Т.е. если добавить заместителя после отправки такой задачи, то заместитель не увидит этого задания. Ему будут доступны только новые такие задания. Аналогична и обратная ситуация в такой временной роли: при окончании срока замещения, заместитель автоматически из этой роли не удалится.

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

  • Замещения не наследуются. Если, например, настроена следующая связка замещений: Сотрудник 1 → Сотрудник 2 → Сотрудник 3, то Сотрудник 1 получит права только Сотрудника 2, но не получит прав Сотрудника 3. Права Сотрудника 3 будут только у Сотрудника 2.

6.4. Добавление заместителей

Добавление заместителей доступно для следующих типов ролей:

  • Сотрудник;

  • Департамент;

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

Рекомендуется использовать Карточка "Мои замещения" для настройки замещений, где можно настроить замещения в том числе по контекстным и динамическим ролям.

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

image160

В открывшемся окне указать заместителя и срок замещения:

image161
  • Заместитель – сотрудник, кому станут доступны задания текущего сотрудника/департамента/роли;

  • Замещаемый пользователь – замещаемый сотрудник. Если в данном поле указан сотрудник, то все задания этого сотрудника (Новые и взятые В работу) будут доступны заместителю. Если поле оставить пустым, то заместителю будут доступны только Новые задания сотрудника/департамента/роли (задания, взятые В работу каким-либо сотрудником, не будут доступны заместителю).

  • Замещение доступно – флаг для включения/отключения замещения;

  • Постоянное замещение – флаг выставляется, если текущее замещение не ограничено сроком;

  • Начало/Окончание замещения – срок замещения указывается, если это не постоянное замещение.

Таким образом, для каждой роли можно добавить несколько заместителей. Для удаления заместителя – выбрать заместителя и нажать кнопку Удалить в области Заместители.

При добавлении заместителя в колонке Активно по умолчанию установлено "нет". Периодический сервис на сервере приложений (Chronos) в указанные сроки замещения добавляет заместителя в состав роли. При этом в поле "Пользователи и заместители" этот пользователь появляется, а в таблице с замещениями колонка "Активно" переключается на "да". Сервис Chronos обрабатывает роли с периодичностью несколько минут, поэтому замещение включается ("Активно" переключается на "да") спустя некоторое время.

Указанным заместителям в указанные сроки будут доступны все задания замещаемого сотрудника.

Задания, которые были отправлены на временную роль "Исполнители задания" (т.е. роль, сформированную при отправке одной задачи на несколько исполнителей) не будут доступны заместителям, т.к. список заместителей для таких задач рассчитывается в момент отправки задачи. Однако, новые задачи, отправляемые на роль "Исполнители задания" (где в составе роли и текущий сотрудник) будут доступны указанным заместителям.
Заместитель помимо прав на исполнение заданий получит все права доступа замещаемого сотрудника/роли (т.е. права на просмотр отчетов, создание/редактирование карточек, просмотр реестров и т.д.). Таким образом, если замещение назначено на роль, то заместитель получит права, доступные для данной роли. Если замещение назначено на сотрудника, то заместитель получит права, доступные только данному сотруднику (исключая права, назначенные на роли, в которые входит этот сотрудник).

6.5. Карточка "Мои замещения"

Для каждого пользователя системы настраивать замещения можно с помощью карточки "Мои замещения" (дополнительная вкладка в карточке сотрудника):

image161 1

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

  • Кто может редактировать - можно указать сотрудников, кому будет доступно редактирование заместителей текущего сотрудника;

  • Заместители - раздел для добавления заместителей. Для добавления новой строки нажать на кнопку "Добавить", откроется форма добавления замещения:

image161 2

  • Список ролей – список ролей, для которых настраивается замещение. В данном поле могут быть указаны: Статические роли, Контекстные роли, Подразделения, а также обобщающие роли:

    • Все статические роли - замещение на задания, назначенные на любые статические роли, в которые входит текущий сотрудник;

    • Все роли и подразделения - замещение на все задания, назначенные на текущего сотрудника и на все типы ролей, в которые входит сотрудник;

    • Все подразделения - замещение на все задания, назначенные на подразделения, в которые входит текущий сотрудник;

    • Лично я - замещение на все задания, назначенные на текущего сотрудника;

При указании в поле "Список ролей" значений Лично я, Все роли и подразделения или <ФИО сотрудника> - заместитель помимо прав на исполнение заданий получит все права доступа замещаемого сотрудника/роли (т.е. права на просмотр отчетов, создание/редактирование карточек, просмотр реестров и т.д.). Таким образом, если замещение назначено на роль, то заместитель получит права, доступные для данной роли. Если замещение назначено на сотрудника, то заместитель получит права, доступные только данному сотруднику (исключая права, назначенные на роли, в которые входит этот сотрудник).
  • Заместители – список сотрудников, кому будут доступны все задания указанных ролей текущего сотрудника;

  • Замещение доступно – флаг для включения/отключения замещения;

  • Постоянное замещение – флаг выставляется, если текущее замещение не ограничено сроком;

  • Начало/Окончание замещения – срок замещения указывается, если это не постоянное замещение.

Таким образом, для сотрудника можно добавить несколько заместителей на разные роли:

image161 3

Заместителям будут доступны как новые задания, так и задания, взятые в работу основным исполнителем.

Задания, которые были отправлены на временную роль "Исполнители задания" (т.е. роль, сформированную при отправке одной задачи на несколько исполнителей) не будут доступны заместителям, т.к. список заместителей для таких задач рассчитывается в момент отправки задачи. Однако, новые задачи, отправляемые на роль "Исполнители задания" (где в составе роли и текущий сотрудник) будут доступны указанным заместителям.

6.6. Настройки сотрудника

В каждой карточке сотрудника есть вкладка Мои настройки. Все настройки, указанные на данной вкладке каждый пользователь может менять себе сам (правая панель системы - кнопка Мои настройки).

У Администратора есть права для изменения настроек любого пользователя. Настройки поделены на несколько вкладок:

image161 7

Вкладка "Мои настройки"

  • Общие настройки:

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

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

    • Отключить все всплывающие уведомления - все всплывающие уведомления будут отключены (такие уведомления обычно отображаются в правом нижнем углу экрана). Это настройка не затрагивает уведомления email и другие виды уведомлений;

    • Разрешить предпросмотр через несколько внешних программ - разрешить предпросмотр одновременно через несколько внешних программ (на разных вкладках). Настройка не затрагивает встроенный предпросмотр или веб-браузер.

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

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

  • Обсуждения

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

    • Не показывать индикатор сообщений при запуске - скрыть индикатор при запуске Tessa Client, индикатор появится при поступлении новых сообщений.

  • Типовое решение:

    • Отключить всплывающие уведомления по заданиям - отключает периодически всплывающие уведомления о том, что доступны новые задания;

  • Настройки учетной записи:

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

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

      image161 8

Вкладка "Уведомления:

image161 10

  • Отписаться от типов уведомлений – это поле позволяет отписаться от выбранных типов уведомлений. В списке недоступны скрытые типы уведомлений.

  • Правила уведомлений – таблица для добавления правил уведомлений. Чтобы добавить новую строку необходимо нажать на кнопку "Добавить", откроется форма добавления правила:

image161 11

Также уже добавленное правило можно удалить, выделив его и нажав кнопку "Удалить". При добавлении новой строки необходимо заполнить поля (обязательные поля отмечены символом *):

  • Название – в этом поле указывается понятное для пользователя название правила.

  • Типы уведомлений – тут указываются типы уведомлений, для которых работает это правило. При поиске доступны все типы уведомлений, кроме скрытых и глобальных.

  • Запретить – если в этом поле стоит флаг, то правило запрещающее, если флага нет, то разрешающее.

  • Описание – в этом поле указывается описание текущего правила. Заполняется автоматически, недоступно для редактирования.

  • Список условий – таблица для добавления условий. Чтобы добавить новую строку необходимо нажать на кнопку "Добавить", откроется форма добавления условия:

image161 12

Для добавления условия следует заполнить поле тип условия и связанное с этим типом дополнительное поле. Список дополнительных полей указан в таблице:

Тип условия

Дополнительное поле

По автору

Сотрудники – в этом поле указываются сотрудники, по которым будет выполняться данное условие, если они являются авторами карточки

По инициатору

Сотрудники – в этом поле указываются сотрудники, по которым будет выполняеться данное условие, если они являются инициаторами процесса

По контрагенту

Контрагенты – в этом поле указываются контрагенты, по которым будет выполняться данное условие

По поздразделению

Подразделения – в этом поле указываются подразделения, по которым будет выполняться данное условие;

Проверять подразделение автора – если в этом поле стоит флаг, условие выполняется, если автор карточки находится в данном подразделении;

Проверять подразделение инициатора – если в этом поле стоит флаг, условие выполняется, если инициатор процесса находится в данном подразделении;

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

По состоянию документа

Состояния - в этом поле указываются состояния, по которым будет выполняться данное условие

По типу документа

Типы документов - в этом поле указываются типы документов, по которым будет выполняться данное условие

По маршруту

Режим работы подсистемы маршрутов - в этом поле указывается режим работы подсистемы маршрутов:

  1. Маршруты не используются;

  2. Маршруты используются;

  3. Маршруты используются и процесс активен;

  4. Маршруты используются и процесс не активен.

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

Если выставлен флаг в поле "Инвертировать условие", то условие будет обратное правилу. То есть, если, например, стоит условие по контрагенту и выбран некий контрагент "ООО Альбатрос", а также стоит флаг "Инвертировать условие", то условие будет работать для всех контрагентов, кроме указанного.

Вкладка "Боковые панели"

  • "Боковые панели" – настройка вызова правой/левой боковых панелей в веб-клиенте по нажатию левой кнопкой мыши, а не по наведению курсора.

Вкладка "Web клиент"

  • "Боковые панели" – настройка вызова правой/левой боковых панелей в веб-клиенте по нажатию левой кнопкой мыши, а не по наведению курсора.

Вкладка "Персонализация"

  • "Область заданий" - настройка цвета кубика заданий в зависимости от различных параметров.

Сам для себя изменить настройки Администратор может или в своей карточке сотрудника, или с помощью вызова окна настроек из правой панели системы - кнопка Мои настройки.

image161 9

В открывшемся окне все настройки аналогичны настройкам в карточке сотрудников.

С помощью кнопки "Мои настройки" → "Настройки новых пользователей" открывается диалог настроек, аналогичный диалогу "Мои настройки", но применяемый для всех новых сотрудников. Новыми считаются любые сотрудники, создаваемые после установки настроек.

7. Настройки типового решения

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

Настройка выполняется через карточку настроек (в рабочем месте Tessa Client), доступную только администраторам и открываемую из правой боковой панели через пункт "Настройки → Типовое решение".

image126

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

7.1. Основная информация

Настройки типового решения разделены на следующие вкладки:

image127

Вкладка "Общие настройки":

  • Прямой порядок в листе согласования - выбор способа отображения информации по циклам согласования в автоматически формируемом листе согласования (пример показан ниже);

  • Скрыть комментарий для варианта завершения "Согласовать" - в заданиях типового процесса согласования для варианта завершения "Согласовать" скрыть поле для ввода комментария. При этом для варианта "Не согласовать" ввод комментария будет доступен.

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

  • Типы карточек - типы карточек, для которых будут использоваться различные возможности типового решения (подробное описание см. далее).

  • Расширения безопасности - дополнительные расширения безопасности (более подробно в руководстве разработчика).

  • Настройки системы:

    • Язык уведомлений по умолчанию - язык отправляемых системой почтовых уведомлений по умолчанию (в случае, если язык не установлен в карточке сотрудника);

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

Вкладка "Дополнительно":

image398
  • Ограничения при добавлении - таблица, в которой указываются права пользователям на добавление этапов маршрута в маршрут карточки документа.

  • Расширенные настройки типов заданий, используемых в подсистеме маршрутов - таблица для добавления типов заданий, которые будут использоваться для этапа "Типизированное задание".

Более подробно подсистема маршрутов описана в разделе Маршруты документов.
  • Настройки задач - таблица для добавления сотрудников, которые имеют право на отправку заданий от имени руководителей (более подробное описание и примеры описаны в руководстве далее):

    • Руководители - список руководителей, от имени кого указанным ролям будет доступно отправлять задачи;

    • Роли, которые могут отправлять задачи - список ролей (сотрудники, департаменты, роли), которые смогут отправлять задачи от имени указанного руководителя.

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

    image414

    Если на доработке согласуемые файлы были отредактированы пользователем (как правило, Инциатором), то в активном цикле отобразится отредактированная версия в виде виртуального файла. Таким образом в любой момент кликнув на такой виртуальный файл можно посмотреть то, как выглядел согласуемый документ после редактирования на данном цикле:

    image415

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

    image416
    Если тип документа не добавлен в данную таблицу, то группировки по циклам по умолчанию не будет, однако пользователи смогут включать её самостоятельно в открытой карточке документа с помощью контекстного меню в секции файлов "Группировка - > По циклу согласования". При этом выбранная пользователем группировка сохраняется только для текущей открытой карточки. После переоткрытия карточки в секции файлов группировки не будет.
    Настроенная группировка файлов по циклам не будет работать, если в Tessa Admin для контрола списка файлов в типе карточки указана иная группировка по умолчанию, т.к. она приоритетней настроек в данной таблице. Однако пользователь сможет самостоятельно в открытой карточке документа выбрать нужную ему группировку для просмотра списка файлов, например, группировку по циклам. При этом выбранная пользователем группировка сохраняется только для текущей открытой карточки. После переоткрытия карточки в секции файлов снова будет отображена группировка по умолчанию.
    • Тип карточки/документа - выбираются типы карточек или документов, для которых необходимо включить автоматическую группировку по циклам.

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

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

      • Все файлы - данный режим отображает абсолютно все файлы, которые есть в списке файлов.

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

      • Файлы текущего цикла - данный режим отображает только файлы на текущем цикле, остальные файлы скрыты от пользователя (скрыты только для удобства работы с секцией файлов, при необходимости пользователь может поменять режим на "Все файлы"). Данный режим удобно использовать во время согласования документа и для документов с завершенным маршрутом, например, в состояниях "На согласовании", "На подписании", "Согласован" и т.д. При открытии карточки по умолчанию пользователи в данном режиме будут видеть только актуальную информацию по последнему циклу - копии согласующих, а также виртуальные файлы тех версий документов, которые были отредактированы именно в этом цикле (обычно файлы редактируются/добавляются на этапе доработки).

7.2. Порядок записей в листе согласования

Настройка "Прямой порядок в листе согласования" позволяет задать прямой порядок циклов согласования и записей внутри цикла. Опция применяется и для обычного и для печатного листа согласования в процессе согласования.

image128
image129

7.3. Типы карточек, включенные в типовое решение

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

image418

В Tessa используется следующая терминология:

  • Тип карточки – тип карточки, описанный как отдельный тип в Tessa Admin, со своей отдельной структурой (набором полей) и внешним видом.

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

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

image134
При использовании типов документов для типа карточки должны быть включены соответствующие поля из секции DocumentCommonInfo.

Типы документов создаются как элементы справочника типов документов. Создать можно или с помощью правого меню "Создать карточку –> Справочники → Тип документа" или нажать на иконку с изображением карандаша в представлении "Администратор → Типовое решение → Типы документов":

image131

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

Настройки типа документа:

image132

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

image133

Подробное описание настроек типов документов/карточек в следующих разделах.

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

  • Входящий – имеет поле для ввода контрагента - отправителя.

  • Исходящий – имеет поле для ввода контрагента – получателя.

  • Договорной документ – является базой для любых документов, где есть сумма, валюта, и контрагент. Обычно это договор, ДС, акт, счёт-фактура и т.д.

  • Документ – база для внутренних документов.

Все базовые типы карточек имеют общие поля, которые не используются в типовом решении и добавлены для удобства. Если они не находят применения в конкретном внедрении – их можно просто скрыть в настройках формы типа карточки в Tessa Admin.

image135

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

Еще раз обращаем внимание, что типы карточек и базовые типы документов предоставляются для удобства и могут меняться или не использоваться в каждом конкретном решении. Можно настраивать собственные типы карточек в Tessa Admin и включать их в типовое решение.

7.4. Выделение номера

В данном разделе будет использоваться следующая терминология:

  • Актуальный номер - тот номер, который на текущий момент отображается в карточке в контроле Нумератор (это может быть основной, проектный или регистрационный номер). Для карточек, включённых в типовое решение, актуальный номер также отображается в дайджесте карточки (в заголовке вкладки и в истории действий), если для типа карточки не определена настройка "Формат дайджеста".

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

  • Проектный номер - номер проекта карточки, который обычно отображается в карточке до её регистрации.

  • Регистрационный номер - итоговый постоянный номер, который присваивается карточке обычно после регистрации документа.

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

image136

В данном контроле отображается актуальный номер, а именно:

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

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

При этом с технической точки зрения используются следующие типы номеров, которые хранятся в базе данных в указанных колонках:

  • Primary - используются поля Number/FullNumber/Sequence в секции DocumentCommonInfo, где хранится актуальный номер карточки (это может быть основной, проектный или регистрационный номер).

  • Secondary - используются поля SecondaryNumber/SecondaryFullNumber/SecondarySequence в секции DocumentCommonInfo, где хранится проектный номер.

Данную логику отображения номеров можно переопределить. Подробней см. раздел Нумератор. А также на форму карточки можно вывести дополнительный контрол, который отобразит Secondary номер (т.е. проектный номер, если карточка уже зарегистрирована).

В зависимости от того, используются ли для типа карточки типы документов, открыв карточку настроек типового решения (правое меню → Настройки → Типовое решение) или карточку типа документа (вкладка Администратор → Типовое решение → Типы документов) можно настроить нумерацию для документа.

Нумерация настраивается в соответствующих блоках полей, выделенных на картинке ниже. Блок для настройки регистрационного номера появляется только при выставлении флага "Использовать регистрацию":

image136 1

Настройки нумерации в блоке "Регистрация" отвечают за настройку регистрационного номера.

Верхняя группа настроек нумератора отвечает за номер, который:

  • Является проектным номером в том случае, если для типа документа используется также и регистрационный номер (такой пример показан на рисунке выше).

  • Является основным номером, если для типа документа не используется регистрационный номер (т.е. если флаг "Использовать регистрацию" снят, или при выставленном флаге в поле "Автоматически выделять номер" указано значение "Не выделять").

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

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

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

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

Существуют следующие настройки выделения номера:

image137
  • Автоматическое выделение номера - настройки способа автоматического выделения номера.

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

      • При создании - номер выделяется в момент создания карточки. При этом в карточке последовательности данный номер будет отображаться в блоке "Зарезервированные номера", т.е. это временный резерв до тех пор, пока пользователь не сохранит карточку (тогда номер станет занятым) или не закроет карточку без сохранения (тогда номер освободится).

      • При сохранении (если не заполнен) - номер выделится при первом сохранении карточки в случае, если пользователь вручную не указал свой номер.

      • Не выделять - не выделять номер автоматически.

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

      • Выделять - номер будет автоматически выделен и присвоен карточке при регистрации.

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

  • Выделять из последовательности - поле для ввода шаблона имени последовательности.

    Каждая последовательность – это одна последовательность номеров. Последовательность обычно начинает отсчёт номеров с единицы. Это можно изменить, указав первый номер в таблице интервалов у карточки последовательности с указанным именем. Карточку можно открыть в справочнике "Прочее → Последовательности" в рабочем месте "Администратор", или, если карточки ещё нет, там её можно создать. Также управление номерами возможно в программных расширениях.

    При указании имени последовательности можно указывать различные плейсхолдеры, такие как {yyyy} – год (см. ниже). Например, если указана последовательность с именем Incoming_{yyyy}, то в момент выделения номера система определит дату документа, возьмет оттуда год, сформирует точное имя последовательности "Incoming_2020" и выделит оттуда номер. Это позволяет начинать нумерацию заново каждый год, месяц, никогда, и т.д.

    Если разные типы карточек используют последовательность с одним и тем же именем – они будут иметь общую нумерацию.

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

  • Формат полного номера - настройки формирования полного номера, тут могут быть указаны разные префиксы и суффиксы для номера, в том числе эти данные могут получаться из плейсхолдеров. Для корректного формирования номера должен присутствовать плейсхолдер вида {n}. При помощи программных расширений можно реализовывать собственные плейсхолдеры.

    Например, по формату номера Исхпр-{00000n}/{yyyy} будут формироваться номера вида: Исхпр-000001/2020, Исхпр-000002/2020…​ Исхпр-001279/2020 и т.д.

    Если номер превышает количество нулей в строке плейсхолдера, т.е. для строки {00000n} это номера 1000000 и старше, то номера продолжают выделяться и увеличиваться, но нулями уже не дополняются.
  • Разрешить выделять вручную - разрешает использование меню поля с номером – выделить и освободить номер, при этом пользователь должен обладать данными правами в соответствии с настроенными правилами доступа.

  • Освобождать номер при удалении - номер будет освобожден в последовательности в случае, если карточка документа будет окончательно удалена.

    Если в настройках типа карточки указан флаг "Удалять в корзину", то при удалении карточки пользователем она будет удаляться в корзину (в представление "Удалённые карточки"), номер при этом не освобождается. Номер освобождается только при окончательном удалении карточки, если выставлена данная настройка (подробней см. Работа с удаленными карточками). Если флаг "Удалять в корзину" не указан, то карточки удаляются без возможности восстановления, и номер освобождается сразу же; мы не рекомендуем снимать этот флаг. Также администратор может удалить карточку без возможности восстановления, независимо от указанного флага, зажав клавишу [Alt] перед нажатием на кнопку удаления карточки в левом меню.

Доступные плейсхолдеры:

Плейсхолдер Описание

{yyyy}

Номер года документа, например 2012.

{00000n}

Используется только для номера. Позволяет дополнять номер нулями до нужной длины.

{yy}

Последние две цифры номера года.

{MM}

Номер месяца вида "06".

{MMM}

Номер месяца вида "Jun".

{MMMM}

Номер месяца вида "June".

{dd}

Номер дня "03".

{M}

Номер месяца "6".

{d}

Номер дня "3".

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

Пример

Допустим, вы используете нумератор с именем вида Входящие-{YYYY}-{f:MainInfo.FolderName}. В карточке у вас есть поле "Папка" (MainInfo.FolderId, FolderName), где вы выбираете папку из номенклатуры дел. Если поле не заполняется автоматически сразу при создании карточки (специальным расширением), а должно выбираться регистратором, то для корректной работы в данном случае необходимо настроить:

  • выделение номера при сохранении;

  • поле сделать обязательным.

В таком случае регистратор создаст карточку (без номера), заполнит поле Папка, сохранит карточку и при этом автоматически выделится корректный номер из нумератора с именем вида Входящие-2015-ПИСЬМА, т.е. все будет корректно работать и серия номеров будет для каждой папки своя.

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

При создании карточки типового решения автоматически заполняются поля:

  • Регистратор - сотрудник, создавший карточку,

  • Дата создания - текущие дата / время,

  • Тип документа - тип текущего документа, например, "Служебная записка".

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

7.4.1. Карточка последовательности

Все карточки последовательностей можно найти в представлении Администратор → Прочее → Последовательности и тут же с помощью кнопки на панели инструментов можно создать новую карточку.

image136 2

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

Карточка последовательности содержит следующие поля:

image136 3
  • Название последовательности - название последовательности, по которой определяется, из какой именно последовательности будет выделен номер в той или иной карточке документа. Подробней см. раздел Выделение номера.

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

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

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

image136 4

В данном примере следующей карточке будет выделен номер 3, далее 4, 15, 28, 29 и т.д.

Редактирование интервалов в карточке последовательности никак не влияет на выделенные номера в карточках документов и может привести к дублям в нумерации. Например, добавив интервал "3-4", если есть карточки документов с такими номерами, они там так и останутся.
Редактирование полей номера (подробней см. Руководство пользователя) в карточке документа никак не влияет на свободные интервалы в карточке последовательности.

7.5. Регистрация

В зависимости от того, используются ли для типа карточки типы документов, открыв карточку настроек типового решения (правое меню → Настройки → Типовое решение) или карточку типа документа (вкладка Администратор → Типовое решение → Типы документов) можно включить типовую возможность регистрации документов, благодаря которой:

  • Появится возможность настроить регистрационную нумерацию.

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

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

Регистрация – это перевод карточки в состояние "Зарегистрирован" с возможным опциональным выделением регистрационного номера и задействованием его в качестве актуального номера в документе. Пользователю нужны права на осуществление этой операции, которые настраивается в карточке вторичного процесса.

Регистрацию удобно использовать, когда необходимо:

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

  • Выделить постоянный номер после регистрации - регистрационный номер, который отличается от проектного номера.

При регистрации документа, по которому завершен процесс (например, документ согласован), карточка переводится в состояние "Зарегистрирован". По документу, процесс по которому не завершен, при регистрации сначала отзывается процесс, а затем уже карточка регистрируется.

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

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

7.6. Использование задач

Если в настройках типа карточки\документа стоит флаг "Использовать типовой процесс отправки задач", то по этому типу карточки можно будет отправлять задачи. При этом пользователю все равно нужны права на создание задач (см. ниже). Также в настройках типа карточки в Tessa Admin должен стоять флаг "Использовать задания".

image139

Если стоит флаг "Отключить проверку даты для подзадач", то будет отключена проверка даты при создании подзадачи. По умолчанию система ограничивает возможную дату завершения подзадачи по правилу:

  • Если родительская задача не просрочена, то ее дата завершения + 1 рабочий день.

  • Если просрочена, то текущая дата + 1 рабочий день.

7.7. Настройка представления со списком доступных авторов

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

image140

Из примера (см. изображение) видно, что задачи от имени "Васильева В.В." могут отправлять сотрудники "Петров П.П." и "Соколов С.С.". Так же подобные настройки справедливы не только для персональных ролей, но и для департаментов, а так же любых других ролей, кроме контекстных. Подобная настройка указана во второй строке, которая позволяет любому сотруднику, входящему в департамент "Бухгалтерия", отправлять задания от имени пользователей "Набоков Н.П." и "Пенкин И.В.".

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

image141

7.8. Использование маршрутов

Под маршрутами в Tessa понимаются:

  • Подсистема маршрутов - функциональность, позволяющая администраторам быстро и просто настроить процесс для документа. Это гибко настраиваемые по шаблонам процессы для согласования, исполнения, подписания, регистрации документов и др. При этом можно пользователям позволить редактировать маршрут - добавлять/удалять/редактировать этапы. Простой пример использования подсистемы маршрутов пользователями описан в Руководстве пользователя. Примеры настройки маршрутов администраторами системы описаны в данном руководстве в разделе Маршруты документов.

  • Конструктор бизнес-процессов с использованием действий группы "Маршруты" - маршрут, разработанный с помощью Конструктора бизнес-процессов и использующий действия, аналогичные этапам подсистемы маршрутов, т.е. Согласование, Подписание, Настраиваемое задание и т.д.

Конструктор бизнес-процессов - это модуль системы Tessa, позволяющий с помощью визуального редактора настроить бизнес-процесс любой сложности. Могут использоваться подпроцессы, версии шаблонов процессов, синхронные и асинхронные переходы между этапами, запуск по любому событию в системе, а также множество прочих возможностей, позволяющих настроить процесс под любые требования, при этом пользователи могут визуально отслеживать ход процесса. А действия группы "Маршруты" позволяют администраторам быстро и просто настроить маршруты, имеющие в себе массу возможностей типовых этапов, например: отправка типовых задач с возможностью создания сколь угодно большого дерева подзадач; отправка заданий на согласование с возможность делегирования, бесконечно вложенного уровня запроса дополнительного согласования, запроса комментариев, а также прочие возможности подсистемы маршрутов.

Маршрут, разработанный с помощью Конструктора бизнес-процессов и запущенный по документу выглядит следующим образом:

image422
Процесс, разработанный с помощью Конструктора бизнес-процессов и не использующий действия группы "Маршруты" не попадает под данную терминологию, и для таких процессов не надо включать указанные ниже настройки.

Подключить систему маршрутов можно для карточек, включённых в типовое решение. В зависимости от того, используются ли для типа карточки типы документов, открыв карточку настроек типового решения (правое меню → Настройки → Типовое решение) или карточку типа документа (вкладка Администратор → Типовое решение → Типы документов) в соответствующем блоке настроек включается система маршрутов:

image421

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

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

  • Скрыть вкладку "Маршрут" - не отображать вкладку "Маршрут" в карточке документа. Актуально, если в проектном решении информацию о маршруте отображают в ином виде, а также используются альтернативные способы добавления пользователями согласующих в маршрут.

  • Использовать маршруты в бизнес-процессах - выставляется в случае, если для документа разработан маршрут инструментами Конструктора бизнес-процессов с использованием действий группы "Маршруты". Флаг скрывает таблицу "Этапы маршрута", расположенную на вкладке "Маршрут" и тайлы: Запустить процесс, Действия → Вернуть документ на доработку, Действия → Отменить процесс, Действия → Отозвать процесс, Другие → Показать скрытые этапы.

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

При включении системы маршрутов, т.е. установке флага Использовать маршруты, в карточку данного типа добавляется вкладка "Маршрут", содержащая информацию о маршруте и возможности для управления процессом (при использовании подсистемы маршрутов).

Снятие флага в настройках, при наличии в системе карточек этого типа, для которых был начат процесс, может привести к негативным последствиям.

7.8.1. Автоматическое согласование

Если в типе документа (или в настройках типового решения для типа документа) включены маршруты, то есть возможность настроить автоматическое согласование документов. В случае если установлен флаг "Автоматически согласовывать просроченные задания согласования", система будет сама завершать задания, просроченные на срок равный или более, чем указан в настройках. Так же система будет уведомлять о том, что документ будет автоматически согласован, с указанием даты планируемого автоматического согласования. Срок уведомлений так же указывается в настройках. Если срок уведомлений не указан, то система не будет предупреждать о планируемом автоматическом согласовании.

image184
image185

Задания будут согласовываться от пользователя "System", с указанием комментария, указанного в настройках, или с комментарием по умолчанию, если необходимая строка в настройках не указана.

Для функционирования автоматического согласования, необходимо, чтобы сервис "Chronos" был запущен и настроен, а также в папке плагина сервиса "Chronos" присутствовал файл лицензии (см. Замена лицензии).

7.9. Использование системы обсуждений

Подключить систему обсуждений можно для карточек, включёных в типовое решение. В зависимости от того, используются ли для типа карточки типы документов, открыв карточку настроек типового решения (правое меню → Настройки → Типовое решение) или карточку типа документа (вкладка Администратор → Типовое решение → Типы документов) в соответствующем блоке настроек включается ситема обсуждений:

image417
Более подробно функциональность обсуждений описана в Руководстве пользователя.
  • Использовать систему обсуждений - подключить систему обсуждений для данного типа карточки/документа. При выставлении флага в карточке документа в правой области заданий будут отображаться голубые кубики с информацией по трём последним обсуждениям в данной карточке.

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

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

8. Шаблоны файлов и плейсхолдеры

8.1. Карточка шаблона файла

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

Создать новый шаблон файла можно с помощью правого меню системы - Создать карточку - Справочники - Шаблон файла:

image141 1

Будет открыта новая карточка шаблона файла. Необходимо заполнить следующие поля:

  • Название - название шаблона файла;

  • Группа - группа, в которую входит шаблон (не обязательно для заполнения). Группы могут использоваться для логической группировки шаблонов (при выборе их из карточки документа), например, группа "Письма":

    image141 3
  • Тип шаблона - карточка или представление. Указывается, где будет использоваться данный шаблон (для конкретных карточек документов или для представлений);

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

  • Доступно ролям - список сотрудников/ролей, которым будет доступно создание файлов по данному шаблону;

  • Типы/Представления - в зависимости от выбранного Типа шаблона в данном поле указывается список типов документов или список представлений, для которых будет использоваться данный шаблон файла;

  • Алиасы плейсхолдеров - можно определить алиас с заданным названием, затем он подставляется в текст документа вместо плейсхолдера алиаса (более подробное описание см. в разделе Алиасы плейсхолдеров);

  • Выполнить компиляцию - кнопка, которая производит компиляцию скриптов в тексте файла (если тип файла поддерживает скрипты) и расширений для данного шаблона.

  • Файлы - секция для добавления шаблонного файла. Для одного шаблона можно добавить только один файл.

image141 2

Шаблонный файл может быть только одним из следующих типов: docx, xlsx (xlsm, если с макросами), html или txt.

При формировании файла по шаблону из карточки документа или представления, вместо плейсхолдеров будут подставлены данные из полей карточки/представления (или данные из связанных таблиц).

Непосредственно в имени файла, приложенного к шаблону, также можно прописывать любые плейсхолдеры и алиасы, которые будут заменены в имени файла. При формировании имени открываемого файла символы, некорректные для файловой системы (такие как кавычки, двоеточия и др.) будут заменены на подчёркивание _, но, если файл прикладывается к карточке, то имя сохраняется как есть. Расширение файла не должно содержать плейсхолдеры. Примеры: Договор-{f:DocumentCommonInfo.FullNumber}.docx, {*alias} {$LocalizationString}.xlsx.

Плейсхолдеры необходимо вставить непосредственно в текст самого документа - docx, xlsx, html или txt.

Новые шаблоны файлов станут доступны для использования только после перезапуска пользователем Tessa Client.

Просмотреть список всех шаблонов файлов в системе можно из рабочего места Администратора, папка Прочие - Шаблоны файлов:

image141 4

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

image141 7

В Типовом решении можно посмотреть пример настроенных шаблонов печати:

  • В формате docx - Протокол совещания;

  • В формате html - Мои задания;

  • В формате xlsx - Мои задания (Excel), Протокол совещания (Excel).

8.2. Алиасы плейсхолдеров

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

image141 8
Имя алиаса не должно содержать пробельных символов или переводов строк (по диапазонам Unicode). Рекомендуется указывать алиасы английскими буквами.
Пример

Например, в документе есть строка: Тема документа: {*subject}. И в списке алиасов шаблона есть строка:

subject f:DocumentCommonInfo.Subject trim

Тогда при разборе выражения будет выполняться замена плейсхолдеров для строки: Тема документа: {f:DocumentCommonInfo.Subject trim}.

Алиасы работают для любых плейсхолдеров, в т.ч. для плейсхолдеров таблиц и плейсхолдеров, добавленных в расширениях.

8.3. Расширения

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

image141 31

Во вкладке "Расширения" есть следующие кнопки:

  • Выполнить компиляцию - кнопка, которая производит компиляцию скриптов в тексте файла (если тип файла поддерживает скрипты) и расширений для данного шаблона.

  • Выполнить компиляцию всех шаблонов файлов - кнопка, которая производит компиляцию скриптов в тексте файла и расширений для всех шаблонов файлов.

Во вкладке "Расширения" есть следующие виды сценариев расширений:

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

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

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

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

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

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

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

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

Более подробно о функционале расширений замены плейсхолдеров можно посмотреть в Руководстве разработчика.

8.4. Плейсхолдеры

Описанные в данном разделе плейсхолдеры используются во множестве мест, например:

Не все типы плейсхолдеров могут быть использованы в указанных местах. В шаблонах файлов могут быть использованы все типы плейсхолдеров.

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

Плейсхолдер Описание

Плейсхолдер {f:…​}

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

Плейсхолдер {t:…​}

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

Плейсхолдер {task:…​}

Аналогичен плейсхолдеру {f:…​}, но позволяет вывести значение из полей текущего задания.

Плейсхолдеры {fv:…​} и {tv:…​}

Аналогичны плейсхолдерам {f:…​} и {t:…​} (соответственно), но позволяют отобразить результаты выполнения представления с заданным алиасом, в данных по таблицам.

Плейсхолдеры {info:…​} и {tinfo:…​}

Аналогичны плейсхолдерам {f:…​} и {t:…​} (соответственно), но позволяют отобразить данные из переданной в контекст обработки плейсхолдеров дополнителной информации.

Плейсхолдер-объявление {#alias placeholder}

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

Плейсхолдеры {n}, {0n}, {00n} и др.

Используется для вывода номера строки в таблице, или номер элемента списка.

Дополнительные плейсхолдеры

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

Скалярное значение (одну строку) возвращают плейсхолдеры {f:…​} и {fv:…​}, а также плейсхолдеры {t:…​} и {tv:…​}, если используются с параметром separate by (separator string) (т.е. все значения списка объединяются в одну строку с указанным разделителем).

8.4.1. Плейсхолдер {f:…​}

Плейсхолдер {f:…​} - универсальный плейсхолдер, который позволяет вывести значение из любого поля карточки, а также соединить любое поле карточки с данными любых других таблиц, чтобы вывести значение из этих таблиц.

Примеры использования:

  1. {f:DocumentCommonInfo.AuthorName} – автор документа, это поле карточки AuthorName из секции DocumentCommonInfo.

    Если какой-то секции или поля нет (не удалось выполнить выборку), то вместо плейсхолдера подставляется пустая строка (см. ниже пример).
  2. {f:DocumentCommonInfo.AuthorID-(UserID)\->RoleUsers.ID\->DepartmentRoles.ID\->Roles.Name} – сложная выборка "Департамент автора", которая соединяет поле карточки AuthorID из секции DocumentCommonInfo (т.е. идентификатор автора документа) с данными из таблиц RoleUsers, DepartmentRoles и Roles (в указанной последовательности), чтобы получить название департамента.

    Посредством стрелок -> определяется способ соединения таблиц:
    • Section1.Field1->Section2.Field2:
      Система возьмет текущее значение поля карточки Section1.Field1 и использует его для выборки поля Field2 из таблицы Section2 по условию Section2.ID = Section1.Field1. Например, если в карточке есть ссылка на сотрудника в каком-то поле, то вы можете выбрать из справочника сотрудников его адрес электронной почты: DocumentCommonInfo.AuthorId->PersonalRoles.Email.

      Эквивалентная выборка
      select Field2 from Section2 where Id = Section1.Field1
    • Section1.Field1=>Section2.Field2:
      Аналогично предыдущему, но строка из связанной таблицы выбирается по RowId. Это нужно, если поле ссылается на строку в дочерней секции (справочника или другой карточки).

      Эквивалентная выборка
      select Field2 from Section2 where RowId = Section1.Field1
    • Section1.Field1-(KeyField)->Section2.Field2:
      Также выбирает значение из таблицы Section2, но выборка строки происходит по полю KeyField.

      Эквивалентная выборка
      select Field2 from Section2 where KeyField = Section1.Field1
      Если сложная выборка вернёт более одной строки, то данные строки будут выведены через точку с запятой. Например, плейсхолдер {f:OutgoingRefDocs.DocID->DocumentCommonInfo.FullNumber} выведет полные номера документов, с которыми связан текущий: Дпр-00004; Исх-00001; П-000231.
  3. В плейсхолдере также можно через ещё одно двоеточие дописать строку форматирования, например: {f:DocumentCommonInfo.CreationDate:dd/MM/yyyy HH\:mm} (разделитель между часами и минутами выводится с эскейп-символом \:, более подробное описание см. в разделе Плейсхолдер {t:…​}, Возможные параметры форматирования, п. 10).

    Будет подставлена дата создания карточки из поля CreationDate, отформатированное как "dd/MM/yyyy HH:mm" (день.месяц.год часы:минуты, т.е. 18.02.2016 12:01). Строка форматирования используется для преобразования значения поля в строку стандартными для .NET средствами (актуально для значений, отличных от строки, например, дата/время или число).

  4. Также значения данного плейсхолдера можно отсортировать, выбрать уникальный distinct или применить иное форматирование (кроме группировки - group by). Описание возможностей аналогично плейсхолдеру {t:…​}, см. Возможные параметры форматирования в плейсхолдере.

8.4.2. Плейсхолдер {t:…​}

Плейсхолдер {t:…​} нужен для вывода нескольких значений в виде таблицы или списка, где каждая строка (или элемент списка) содержит одну или несколько колонок (для списка это просто несколько значений рядом).

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

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

{t:Секция1.Поле1->Секция2.Поле2 distinct top 5 group by Секция2.Поле3, Секция1.Поле4 order by Секция1.Поле5 desc, Секция2.Поле6 format as (* [$LocalizedString]: [0]) separate by (;\n) utc trim task:custom format}

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

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

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

Возможные параметры форматирования в плейсхолдере:

  1. Секция1.Поле1->Секция2.Поле2 - аналогично плейсхолдеру {f:…​}, т.е. таблиц может быть несколько, их можно объединять по ID ->, по RowID =>, по любой другой колонке - (ParentRowID) ->.

  2. distinct - определяет, что в результаты запроса попадут только строки, которые были определены как отличающиеся в результатах запроса. Аналогично запросу SQL вида select distinct. Это позволяет, например, вывести только фамилии исполнителей, которые отличаются между собой.

  3. top N - указываем, что требуется выбрать не больше, чем заданное количество строк из результатов. Например, top 10 для вывода первых десяти или top 1 для вывода первой строки (независимо от их количества).

  4. group by Секция2.Поле3, Секция1.Поле4 - позволяет указать, по каким ключевым колонкам строки будут объединяться между собой. По умолчанию (когда выражение group by не указано) объединение выполняется по Секция1.RowID, где Секция1 - это первая заданная секция. В выражении может быть опущено название секции, тогда будет использоваться первая заданная секция.

    Например, group by ParentRowID будет группировать строки по колонке Секция1.ParentRowID. Если запрос к базе данных вернёт больше одной строки с одними и теми же значениями ключевой колонки ParentRowID (в этом примере), то эти значения будут объединяться в пределах группы (строки таблицы) через символ разделителя (по умолчанию точка с запятой) по аналогии с выводом плейсхолдера {f:…​}. Например, будет отображена одна строка таблицы Иванов И.И.; Петров П.П. и другая строка Сидоров С.С. (т.к. первые две строки из результатов запроса имели одинаковый ParentRowID, а третья строка имела отличающийся ParentRowID).

  5. order by Секция1.Поле5 desc, Секция2.Поле6 - указание сортировки, которая выполняется при запросе данных из SQL. Если указано несколько колонок, то выполняется сначала сортировка по первой колонке, затем по второй. Необязательное слово desc указывает, что сортировка выполняется по убыванию, а asc - по возрастанию (по умолчанию). В примере выполняется сначала сортировка строк результата по колонке Секция1.Поле5 по убыванию, а затем в пределах одинакового значения в Поле5 - по колонке Секция2.Поле6 по возрастанию. Если секцию не указать, то будет выполнена сортировка по колонке первой таблицы.

    Например, order by Order указывает, что сортировка будет выполнена по колонке Секция1.Order. Указание сортировки особенно удобно для упорядоченных коллекционных секций карточки. Если выражение order by не задано, то сортировка будет произведена по результирующей колонке по возрастанию, в примере это Секция2.Поле2.

  6. format as (format string) - указывает, что каждое значение при выводе должно быть дополнительно отформатировано с учётом строки формата format string. Строка формата соответствует такой строке в стандартном выражении String.Format в .NET, где вместо фигурных скобок участвуют квадратные. В такой строке могут быть встроенные строки локализации.

    Например, format as (* [$LocalizedString]: [0]) аналогично вызову String.Format("* {$LocalizedString}: {0}", value), где подстрока {$LocalizedString} будет заменена на строку локализации, а {0} - это позиция для выводимого значения value. Символы \n соответствуют переводу строки.

  7. separate by (separator string) - определяет формат строки-разделителя separator string между несколькими значениями в пределах одной группы (для плейсхолдера {f:…​} это будут любые несколько значений). По умолчанию используется разделитель "; ", т.е. "точка с запятой и пробел". Символы \n соответствуют переводу строки. Разделитель ;\n означает, что между значениями будут вставлены точка с запятой и перевод строки. Например:

    Иванов И.И.;

    Петров П.П.;

    Сидоров С.С.

  8. utc - если значение, возвращаемое плейсхолдером, является датой (соответствует типам SQL: Date, DateTime, DateTime2), то оно выводится без приведения к локальному времени пользователя, который генерирует документ по шаблону. При выводе дат по умолчанию выводятся дата и время, приведённые к локальному времени, для типов SQL DateTime и DateTime2. Указание utc позволяет не выполнять корректировку времени в соответствии с часовым поясом пользователя. Тип данных SQL Date по умолчанию выводится как только дата (без времени), при этом не выполняется приведение к локальному времени, т.е. настройка utc работает по умолчанию и игнорируется при явном указании.

  9. trim - после окончательного формирования строки, которая заменяет плейсхолдер, удаляются начальные и конечные символы пробелов, табуляций и переводов строк (в соответствии с определением таких символов в таблицах Unicode). Например, из строки `Иванов И.И.; Петров П.П. ` будет удалён конечный пробел.

  10. task - позволяет получить данные не из основной карточки, а из карточки задания.

  11. custom format - дополнительное форматирование, выводимое в конце выражения плейсхолдера после двоеточия. Например, для вывода типа SQL DateTime как дата и время без секунд, можно использовать строку dd.MM.yyyy HH\:mm. Разделитель между часами и минутами выводится с эскейп-символом \:. Если нужен символ \, то его следует задвоить \\. Указанное значение аналогично использованию форматирования типов данных .NET через IFormattable.ToString(), в этом примере: dateTimeValue.ToString("dd.MM.yyyy HH:mm", CultureInfo.InvariantCulture).

Если в выражениях плейсхолдера двоеточие используется в месте, не предусмотренном стандартным форматированием, например: format as (value: [0]), то при отсутствии явно заданной строки форматирования "custom format" требуется завершить определение плейсхолдера двоеточием, т.е. так, будто бы строкой "custom format" является пустая строка. Например: {t:OutgoingRefDocs.DocID->DocumentCommonInfo.AuthorName format as (Автор: [0]):}. Аналогично и для плейсхолдеров {f:…​}, {fv:…​}, {tv:…​}.

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

8.4.3. Плейсхолдер {task:…​}

Плейсхолдер {task:…​} - аналогичен плейсхолдеру {f:…​}, но в отличие от него позволяет вывести значение из задания, такие как текущий исполнитель, автор, дата создания, плановая дата завершения и т.д., а также соединить любое из этих полей с данными любых других таблиц, чтобы вывести значение из этих таблиц.

Примеры использования:

  1. {task:AuthorName} – автор задания. Это поле AuthorName из объекта задания.

  2. {task:AuthorID-(UserID)\->RoleUsers.ID\->DepartmentRoles.ID\->Roles.Name} – сложная выборка "Департамент автора" задания, которая соединяет поле AuthorID из объекта задания (т.е. идентификатор автора задания) с данными из таблиц RoleUsers, DepartmentRoles и Roles (в указанной последовательности), чтобы получить название департамента.

Описание возможностей плейсхолдера идентично плейсхолдеру {f:…​} (см. Возможные параметры форматирования в плейсхолдере), за исключением следующих отличий:

  1. Вместо конструкции Секция1.Поле1->Секция2.Поле2 используется конструкция Поле1->Секция2.Поле2, где Поле1 может принимать одно из следующих значений:

    • Created - дата создания задания;

    • CreatedByID - идентификатор пользователя, создавшего задание;

    • CreatedByName - имя пользователя, создавшего задание;

    • Modified - дата последнего изменения задания;

    • ModifiedByID - идентификатор пользователя, внесшего последние изменения в задание;

    • ModifiedByName - имя пользователя, внесшего последние изменения в задание;

    • Planned - плановая дата завершения задания;

    • InProgress - дата взятия задания в работу;

    • AuthorID - идентификатор автора задания;

    • AuthorName - имя автора задания;

    • RoleID - идентификатор роли исполнителя задания;

    • RoleName - имя роли исполнителя задания;

    • UserID - идентификатор пользователя, взявшего задание в работу;

    • UserName - имя пользователя, взявшего задание в работу;

  2. Не поддерживает использование параметра task.

8.4.4. Плейсхолдеры {fv:…​} и {tv:…​}

Аналогичны плейсхолдерам {f:…​} и {t:…​} (соответственно), но позволяют отобразить результаты выполнения представления с заданным алиасом, в данных по таблицам.

Примеры:

  1. {tv:АлиасПредставления.КолонкаПредставления->Секция1.Поле1 top 5 with param АлиасПараметра НастройкиПараметра group by Колонка2, Колонка3 order by Колонка4 desc, Колонка5 format as (* [$LocalizedString]: [0]) separate by (;\n) utc trim:custom format}

Возможные параметры форматирования в плейсхолдере:

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

  2. КолонкаПредставления - название колонки, возвращаемое представлением, которая будет отображена в плейсхолдере, если не задана конструкция ->Секция1.Поле1.

  3. ->Секция1.Поле1 - плейсхолдеру {f:…​}, можно делать сложную выборку данных из различных таблиц, которые можно объединять по ID ->, по RowID =>, по любой другой колонке - (ParentRowID) ->. Основное отличие, что в качестве первого значения для объединения используется значение из КолонкаПредставления.

  4. top N - указывает, что требуется выбрать не больше, чем заданное количество строк из результатов. Если представление поддерживает пейджинг, то выбирается первая страница размером в N строк. Если представление не поддерживает пейджинг, то будут выбраны все строки, после чего заданное количество строк будет отображено, а остальные строки - игнорированы.

  5. with param АлиасПараметра НастройкиПараметра - указывает алиас параметра представления, в который будет передано значение, в зависимости от настроек параметра. Настройки параметра могут быть следующими:

    • Без настроек параметра (with param АлиасПараметра) - в качестве значения параметра подставляется идентификатор текущей карточки, для которой генерируется шаблон. Если шаблон генерируется из представления, то передается идентификатор текущего пользователя.

    • value ЗначениеПараметра (with param АлиасПараметра value ЗначениеПараметра) - в качестве параметра передается константа, указананя в ЗначениеПараметра. Система конвертирует указанное значение в тип параметра (в случае невозможности конвертации, система выдаст ошибку). Если необходимо указать в качестве значения параметра строку с пробелами, то эту строку необходимо заключить в двойные кавычки "…​", при этом для использования символа двойных кавычек внутри пишутся две двойные кавычки "".

      Если в качестве значения параметра используется идентификатор, то его следует писать без фигурных скобок.
      Если данный плейсхолдер задан в тексте документа, то в значении параметра нельзя использовать символы фигурныъ скобок {}.
    • from АлиасПлейсхолдера (with param АлиасПараметра from АлиасПлейсхолдера) - в качестве параметра передается значение из плейсхолдера-объявления с указаным алиасом плейсхолдера (см. Плейсхолдер-объявление {#alias placeholder}). Данную конструкцию можно использовать в следующих ситуациях:

      1. Для передачи значения плейсхолдера строкового типа ({f}, {fv} и т.д.) в качестве параметра представления. Можно использовать как в плейсхолдере {fv}, так и {tv}. Пример передачи в качестве параметра PartnerID идентификатора контарегнта из секции DocumentCommonInfo, из поля PartnerID:

        • Плейсхолдер-объявление - {#Parner f:DocumentCommonInfo.PartnerID}

        • Использование в параметре плейсхолдера - {…​ with param PartnerID from Partner …​}

      2. Для передачи значения табличного плейсхолдера ({t}, {tv} и т.д.) из родительской таблицы в дочернюю. Можно использовать только в плейсхолдере {tv} и только, если для родительской таблицы используется плейсхолдер-объявление. В такой ситуации в качестве АлиасПлейсхолдера пищется АлиасПлейсхолдера.ИмяПоля Пример передачи из родительской таблицы Performers значения Email как параметр в дочернюю таблицу:

        • Плейсхолдер-объявление родительской таблицы - {#Performers t:Performers.UserID->PersonalRoles.*}

        • Использование в параметре плейсхолдера дочерней таблицы - {…​ with param PartnerID from Performers.Email …​}

  6. group by Колонка2, Колонка3 - группировка строк в плейсхолдере {tv:…​} по названиям колонок, возвращаемых представлением. Если группировка не указана, то строки не группируются и возвращаются в том виде и в том же порядке, в котором их возвращает представление.

  7. order by Колонка4 desc, Колонка5 - сортировка, выполняемая в представлении по заданным колонкам. Сортировка выполняется средствами самого представления, а задаваемые колонки - это алиасы колонок, способ сортировки по которым определяется в представлении. Необязательное слово "desc" указывает, что сортировка выполняется по убыванию, а "asc" - по возрастанию (по умолчанию). Если выражение не указано, то выполняется сортировка по умолчанию, заданная в метаинформации представления #view.

  8. format as (* [$LocalizedString]: [0]) - форматирование каждого возвращаемого значения. Аналогично выражению format as для плейсхолдеров {f:…​} и {t:…​}.

  9. separate by (;\n) - указание разделителя между несколькими значениями в пределах группы (строки таблицы для {tv:…​}) или для всех возвращённых значений в плейсхолдере {fv:…​}. Аналогично выражению separate by для плейсхолдеров {f:…​} и {t:…​}.

  10. utc - вывод значения без корректировки по часовому поясу пользователя. Форматирование дат и корректировка часового пояса работает аналогично плейсхолдерам {f:…​} и {t:…​}.

  11. trim - удаление начальных и конечных пробельных символов. По аналогии с выражением в {f:…​} и {t:…​}.

  12. custom format - дополнительное форматирование. По аналогии с выражением в {f:…​} и {t:…​}.

8.4.5. Плейсхолдеры {info:…​} и {tinfo:…​}

Аналогичны плейсхолдерам {f:…​} и {t:…​} (соответственно), но позволяют отобразить данные из переданной в контекст обработки плейсхолдеров дополнителной информации.

Пример:

{tinfo:Ключ1.Ключ2.Ключ3 top 5 order by Ключ4 desc, Ключ5 format as (* [$LocalizedString]: [0]) separate by (;\n) utc trim:custom format}

  1. Ключ1.Ключ2.Ключ3 - определяет путь в переданном Info к требуемой информации. При испльзовании плейсхолдреа {tinfo:…​} по одному из ключей должен быть передан список объектов. При использовании {info:…​}, аналогично плейсхолдеру {f:…​}, можно использовать несколько таблиц, например Ключ1.Ключ2.Ключ3->Секция1.Поле1.

  2. top N - указываем, что требуется выбрать не больше, чем заданное количество строк из результатов. Например, top 10 для вывода первых десяти или top 1 для вывода первой строки (независимо от их количества).

  3. order by Ключ4 desc, Ключ5 - указание сортировки, которая выполняется при запросе данных из Info. В качестве ключей следует указывать ключ относительно пути до элемента списка. Например, если список хранится по пути Ключ1.Ключ2, то значение для сортировки берется Ключ1.Ключ2.Ключ4. Если указано несколько ключей, то выполняется сначала сортировка по первому ключу, затем по второму. Необязательное слово desc указывает, что сортировка выполняется по убыванию, а asc - по возрастанию (по умолчанию).

  4. format as (format string) - указывает, что каждое значение при выводе должно быть дополнительно отформатировано с учётом строки формата format string. Строка формата соответствует такой строке в стандартном выражении String.Format в .NET, где вместо фигурных скобок участвуют квадратные. В такой строке могут быть встроенные строки локализации.

    Например, format as (* [$LocalizedString]: [0]) аналогично вызову String.Format("* {$LocalizedString}: {0}", value), где подстрока {$LocalizedString} будет заменена на строку локализации, а {0} - это позиция для выводимого значения value. Символы \n соответствуют переводу строки.

  5. separate by (separator string) - определяет формат строки-разделителя separator string между несколькими значениями в пределах одной группы (для плейсхолдера {f:…​} это будут любые несколько значений). По умолчанию используется разделитель "; ", т.е. "точка с запятой и пробел". Символы \n соответствуют переводу строки. Разделитель ;\n означает, что между значениями будут вставлены точка с запятой и перевод строки. Например:

    Иванов И.И.;

    Петров П.П.;

    Сидоров С.С.

  6. utc - если значение, возвращаемое плейсхолдером, является датой (соответствует типам SQL: Date, DateTime, DateTime2), то оно выводится без приведения к локальному времени пользователя, который генерирует документ по шаблону. При выводе дат по умолчанию выводятся дата и время, приведённые к локальному времени, для типов SQL DateTime и DateTime2. Указание utc позволяет не выполнять корректировку времени в соответствии с часовым поясом пользователя. Тип данных SQL Date по умолчанию выводится как только дата (без времени), при этом не выполняется приведение к локальному времени, т.е. настройка utc работает по умолчанию и игнорируется при явном указании.

  7. trim - после окончательного формирования строки, которая заменяет плейсхолдер, удаляются начальные и конечные символы пробелов, табуляций и переводов строк (в соответствии с определением таких символов в таблицах Unicode). Например, из строки `Иванов И.И.; Петров П.П. ` будет удалён конечный пробел.

  8. custom format - дополнительное форматирование, выводимое в конце выражения плейсхолдера после двоеточия. Например, для вывода типа SQL DateTime как дата и время без секунд, можно использовать строку dd.MM.yyyy HH\:mm. Разделитель между часами и минутами выводится с эскейп-символом \:. Если нужен символ \, то его следует задвоить \\. Указанное значение аналогично использованию форматирования типов данных .NET через IFormattable.ToString(), в этом примере: dateTimeValue.ToString("dd.MM.yyyy HH:mm", CultureInfo.InvariantCulture).

8.4.6. Плейсхолдер-объявление {#alias placeholder}

Особый тип плейсхолдеров, который состоит из двух частей:

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

  • placeholder - любой другой плейсхолдер, кроме плесхолдера-объявления и плейсхолдера {n}. Само значение плейсхолдера рассчитывается только в момент обращения к нему.

Укаазанный placeholder может быть как табличным плейсхолдером (плейсхолдеры {t}, {tv} и т.д.), так и строковым плейсхолдером (плейсхолдеры {f}, {fv} и т.д.). Если данный плейсолдер является табличным, то в качестве поля таблицы или имени колонки представления, откуда берутся данные, в этом табличном плейсхолде ставится символ "*". Строковые плейсхолдеры пишутся без изменений Примеры:

  • {#Partner f:DocumentCommonInfo.PartnerID}

  • {#Performers t:Performers.UserID->PersonalRoles.*}

  • {#LinkedDocs tv:LinkedDocuments.* with param LinkedDocID}

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

  • {#Reports t:ProtocolReports.* top 5 order by Order}

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

  • {t:Reports.Subject}

  • {t:Reports.PersonName}

  • {t:Reports.PersonID->PersonalRoles.Email}

При этом каждому плейсхолдеру {t} внутри таблицы будут подставлены все настройки плейсхолдера из алиаса (в данном примере - top 5 order by Order).

Другой способ использования данного типа плейсхолдеров, это использования этих плейсхолдеров в качестве значения параметра для плейсхолдеров {fv} и {tv}. Более подробно про данный способ использования алиаса смотрите в разделе Плейсхолдеры {fv:…​} и {tv:…​}.

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

8.4.7. Плейсхолдеры {n}, {0n}, {00n} и др.

При использовании в строке таблицы (или в элементе списка) данный плейсхолдер выводит номер строки. Это удобно для вывода номера строки отдельной колонкой.

Пример

{n} - {t:OutgoingRefDocs.DocDescription order by Order}

Выведет информацию по ссылкам на другие документы с указанием номера каждой ссылки:

  1. - Дпр-0003

  2. - И-0002

Указание {00n} дописывает нули до определённой длины, т.е. номер "5" выводит как "005".

8.4.8. Дополнительные плейсхолдеры

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

  • Плейсхолдеры для вывода текущей даты/времени:

    • {date} - заменяется на текущую дату/время. В параметрах плейсхолдера можно указать формат отображения, например: {date:dd/MM/yyyy}.

    • {yyyy} - заменяется на четырехзначное указание года, например 2018.

    • {yy} - заменяется на двухзначное указание года, например 17.

    • {M} - заменяется на числовое обозначение текущего месяца, например 6.

    • {MM} - заменяется на числовое обозначение текущего месяца, например 06.

    • {MMM} - заменяется на текстовое обозначение текущего месяца (3 символа), например Jun.

    • {MMMM} - заменяется на текстовое обозначение текущего месяца, например June.

    • {dd} - заменяется на обозначение текущего дня, например 03.

    • {d} - заменяется на обозначение текущего дня, например 3.

      Например, плейсхолдеры {dd}.{MM}.{yyyy} заменятся на текущую дату в формате 28.03.2018.

  • {cardDigest} - заменяется на дайджест текущей карточки.

  • {$LocalizationString} - такой плейсхолдер заменяется на строку с алиасом LocalizationString, локализованную для языка текущего пользователя.

    Например, строка {$ApprovalHistory_Header} заменяется на "Approval history" для англоязычных пользователей и на "Лист согласования" для русскоязычных пользователей.

  • {userID} - заменяется на идентификатор текущего пользователя (выполняющего генерацию файла по шаблону), например: ffe132a8-23fc-4a5b-ac75-70e0b7854c59.

  • {userName} - заменяется на имя текущего пользователя, например: Иванов И.И.

  • {serverCode} - заменяется на текущий код сервера (полезно при формировании ссылок tessa://), например: prod.

  • {instanceName} - заменяется на текущее имя экземпляра сервера (полезно при формировании ссылок tessa://), например: tessa. Зарезервировано для будущих нужд, не рекомендуется использовать.

  • {sessionID} - заменяется на идентификатор текущей сессии, например: dde132a8-23fc-4a5b-ac75-70e0b7854c59.

  • {cardID} - заменяется на идентификатор карточки (для которой генерируется файл по шаблону), например: 12d8cf28-9902-4dfd-8cbc-0f8a4d994691.

  • {cardLink} - заменяется на ссылку tessa:// на открытие текущей карточки, например: tessa://tessaclient.prod?Action=OpenCard&ID=12d8cf28-9902-4dfd-8cbc-0f8a4d994691&Name=Карточка.

  • {webCardLink} - аналогично {cardLink}, только заменяется на ссылку для открытия карточки в легком клиенте.

  • {webAddress} - заменяется на ссылку на базовый адрес веб-клиента с завершающим слешом, т.е. на https://address.org/tessa/web/.

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

    <a href="{webAddress}views/ef0523b2-7fad-45d4-a44d-cac7ea392ced">Ссылка на узел дерева "Мои задания"</a>

    Идентификатор узла можно узнать в Tessa Admin, вкладка Рабочие места - выбрать нужный узел в дереве и далее, в свойствах в параметре Id скопировать идентификатор выбранного узла.

  • {appLink} и {webAppLink} - заменяется на ссылку на приложение (толстый и лёгкий клиент соответственно). Используется, например, для отправки уведомления на почту сотрудникам с информацией об окончании срока действия пароля.

  • {passwordExpires} - генерируется из карточки сотрудника, заменяется на срок окончания действия пароля у сотрудника. Срок вычисляется следующим образом: "Дата и время последнего изменения пароля" в карточке сотрудника + "Срок действия пароля" в карточке Настройки сервера. Используется для отправки уведомления на почту сотрудникам с информацией об окончании срока действия пароля.

  • {link:Action} - заменяется на ссылку tessa:// с указанием действия (по умолчанию OpenCard для открытия карточки или файла), например: tessa://tessaclient.prod?Action=Parameter

  • {text:any text} - заменяется на текст, заданный в параметрах. Если текст содержит двоеточие, то в плейсхолдер следует завершить на двоеточие, например: {text:some text: other text:}

8.5. Шаблонизация текста

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

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

  • Шаблоны файлов - для текстовых и html документов;

  • Уведомления - тема и текст уведомления в карточке Уведомления;

  • Конструктор процессов - настройки действий Уведомление, Добавить файл по шаблону, Задание, Группа заданий;

Все скрипты в тексте имеют доступ к следующему набору параметров:

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

  • textBuilder - объект типы StringBuilder, в который записывается итоговый текст. Уникальный для каждой группы или строки.

Система поддерживает следующие конструкции для вставки скриптов в текст:

  • <# …​ #> - вставка скрипта в текст.

Пример, когда вставка части текста выполняется только при определенном условии.

Приветствую, <# if (context.Session.User.IsAdministrator()) { #>многоуважаемый, <# } #> {userName}.

Другой пример с использованием циклов.

Приветствую: <# foreach (Dictionary<string, object> item in context.Info.Get<List<object>>("Items"))
{ #>
многоуважаемый, <# textBuilder.Append(item["Name"]); #>
<# } #>.
  • <#= …​ #> - вставка результата выражения в итоговый текст.

Аналогичный пример со вставкой через условие, но только через выражение.

Приветствую, <#= context.Session.User.IsAdministrator() ? "многоуважаемый, " : string.Empty #> {userName}.
  • <## ... ##> и <##= ... ##> - конструкции, аналогичные описанным выше, но их скрипты выполняются только при инициализации таблицы (см. Обработка таблиц), во всех остальных ситуациях данный скрипт игнорируется.

Важной особенностью данного функционала является то, что для строк и групп с плейсхолдерами (обрамлены в <_row>…​</row> и <_group>…​</_group> соответственно) скрипты генерируются отдельно и вызываются при генерации каждой отдельной строки или группы. Это позволяет в свою очередь видоизменять каждую строку и группу таблицы по отдельности.

8.5.1. Обработка таблиц

В данном пункте рчеь идет о таблицах с табличными плейсхолдерами, которые обромлены в <_row>…​</_row> и <_group>…​</_group> конструкции.

При наличии внутри таблицы скриптов, система генерирует для нее 2 скрипта:

  • Скрипт инициализации таблицы

  • Скрипт генерации строки/группы

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

При формировании данного скрипта все конструкции вида <# ... #> и <#= ... #> игнорируются, как будто их вообще и нет в тексте. Вместо них используются конструкции <## ... ##> и <##= ... ##> для написания скриптов.

Однако, в большинстве случаев в этом нет необходимости, т.к. система получит плейсхолдеры из самого текста таблицы. Данные скрипты могут быть полезны в ситуациях, когда плейсхолдеры для строк генерируются скриптами (внутри <# ... #> или <#= ... #>) или если есть желание или необходимость выделить первый плейсхолдер для расчёта сортировок, группировок и т.д. в отдельный плейсхолдер, результат которого выводится не должен.

Пример:

Таблица:
<_row><##= "{t:Секция1.Поле1 top 5 Секция1.Поле3 order by Секция1.Поле4 desc, Секция2.Поле6}"
##>
	{t:Секция1.Поле6}
	<# if {условие) { #>{t:Секция1.Поле8}<# } else { #>{t:Секция1.Поле7\->Секция2.Поле8}<# } #>
</_row>

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

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

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

Таблица:
<_group>
	{t:Секция1.Поле1}
	<# if (условие_на_проверку_типа_строки) { #>
	<_row>
		{t:Секция1.Поле1} | {t:Секция1.Поле2}
	</_row>
	<# } else { #>
	<_row>
		Дополнительный текст в данной строке: {t:Секция1.Поле3} | {t:Секция1.Поле4}
	</_row>
<# } #>
</_group>

Пример, убираем всю строку, если условие не выполнено:

Таблица:
<_row><# if (необходимое_условие_для_строки) { #>
	{t:Секция1.Поле6}
	<# if {условие) { #>{t:Секция1.Поле8}<# } else { #>{t:Секция1.Поле7\->Секция2.Поле8}<# } #>
<# } #></_row>

8.6. Особенности шаблонных файлов для представлений

В шаблоне файла для представления в плейсхолдерах {fv:…​} и {tv:…​} можно не указывать алиас представления, т.к. это будет выбранное представление (т.е. представление, из которого формируется файл по шаблону). При этом, при формировании файла по шаблону, будет учитываться предварительно настроенная фильтрация в представлении.

В случае, если мы указываем представление в плейсхолдере {fv:…​} или {tv:…​} (т.е. плейсхолдеры заданы для одного представления, а формироваться файл по шаблону будет из другого представления), то данное представление будет выгружено без учета параметров (т.е. без учета фильтрации в представлении). Данный функционал (выгрузка представления с учетом фильтрации), при необходимости, можно реализовать с помощью дополнительных расширений (см. Руководство Администратора).

Любые скаляры (т.е. плейсхолдеры, которые возвращают одно значение, см. Плейсхолдеры) также можно использовать в шаблонных файлах для представлений. Плейсхолдеры {f:…​}, {t:…​} будут выполнены в контексте карточки текущего сотрудника, то есть {f:PersonalRoles.Name} - вернет имя текущего сотрудника. Для плейсхолдеров {fv:…​} и {tv:…​} в параметр, указанный в with param, передается идентификатор текущего пользователя.

8.7. Примеры создания шаблонов файлов в формате docx

Пример docx шаблонного файла, в котором указаны плейсхолдеры, представлен на рисунке ниже (слева). Сформированный из карточки входящего документа по данному шаблону файл представлен на рисунке справа:

image141 5

В docx шаблонных файлах может использоваться плейсхолдер {t:…​} для вывода значений в таблицу, в виде списка или нумерованного списка.

Рассмотрим конкретные примеры:

  1. Пример вывода данных в виде нумерованного списка:

    Выведем список карточек, на которые ссылается текущая карточка, с указанием после запятой автора карточки.

    В файле .docx добавим строку: {t:OutgoingRefDocs.DocID->DocumentCommonInfo.FullNumber}, автор {t:OutgoingRefDocs.DocID->DocumentCommonInfo.AuthorName}
    Далее преобразуем данную строку в нумерованный список:

    image141 19

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

    image141 20
  2. Аналогично можно вывести данные в виде списка:

    image141 21
  3. Следующий пример - выведем те же данные, но в виде таблицы:

    Добавим в docx документ новую таблицу с тремя колонками.

    В первой строке таблицы указываем название колонок: , Карточка, Автор. Во второй строке таблицы указываем плейсхолдеры:

    • {n} - порядковый номер записи;

    • {t:OutgoingRefDocs.DocID->DocumentCommonInfo.FullNumber} - номер карточки;

    • {t:OutgoingRefDocs.DocID->DocumentCommonInfo.AuthorName} - автор карточки.

    image141 22

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

    image141 23
  4. Еще один способ - использовать механизм закладок в Word, для возможности выделения нужной области в качестве строки, группы или таблицы. С помощью имени закладки система поймет, к какому типу необходимо определить данную область.
    Область, которую система определяет по закладке, определяется по следующему правилу:

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

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

      image141 34
    • Если закладка находится внутри нескольких параграфов или других элементов (ячейках, строках, таблицах), то система определяет в качестве области все элементы целиком, вне зависимости от того, где конкретно начинается или заканчивается закладка.

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

Выделяют следующие типы закладок, в зависимости от их имени:

Имя закладки Описание

r_AreaName

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

Пример простого использования:

Сделаем перечисление внутри пагарафа, где заданы алиасы плейсхолдеров (см Алиасы плейсхолдеров), указав закладку на внутренние элементы параграфа r_Decided:

image141 35

В результирующем файле в данный пагараф путем копирования и вставки новых элементов добавлены все записи из карточки протокола:

image141 36

Пример использования вложенных t_AreaName:

Сделаем простой шаблон файла, который из представления Мои документы сразу бы выводил по каждомму документу его связанные документы.

image141 43

Для строк, выделенных синим, создаем закладку r_Main, для строк, выделенных зеленым, создаем закладку t_Sub, для строки, выделеной красным, создаем закладку r_Sub.

В примере также используются плейсхолдеры-объявления, с помощью которых мы указываем, что по алиасу Main у нас будут браться данные для внешней таблицы из представления Мои документы (имя представления не указывается, т.к. шаблон файла строится именно по этому представлению), а по алиасу Sub у нас будут браться данные для вложенной таблицы из представления Связанные документы, и при этом для получения данных из этого представления в качестве параметра LinkedDocID будет передаваться значение из колонки DocID из строки основной таблицы.

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

Таким образом можно получить из этих данных:

image141 44

Следующий результат:

image141 45

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

g_AreaName

Группировка строк по параметру. Внутри диапазона ячеек с группировкой может содержаться диапазон с именем r_AreaName, g_AreaName (для создания многоуровневой группировки) или t_AreaName (для создания вложенной таблицы).

Пример использования g_AreaName с вложенным r_AreaName:

Перенесем шаблон Мои задания на .docx. В качестве строки выделем строку, отмеченную синим, и создадим закладку r_Task, а в качестве группы выделем две строки таблицы, выделенные красным, и создадим хакладку g_TaskGroup.

image141 37

В результирующем файле мы получим аналог шаблона файла "Мои задания", но только уже в формате .docx. Система определила плейсхолдеры в области закладки g_TaskGroup, но не входящие в область закладки r_Task как группирующие, сгруппировала значения по ним и построила таблицу.

image141 38

Пример использования g_AreaName с вложенным g_AreaName2:

Модифицируем первый пример, перенем состояние задания в отдельную строку. Выделим все три строки таблицы, обведенные синим цветом, и сделаем для них закладку g_TasksByType, далее выделим две нижние строки, обведенные зеленым цветом, и сделаем для них закладку g_TasksByState, а затем выделим строку, обведенную красным цветом, и сделаем закладку r_Tasks.

image141 41

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

image141 42

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

Использование области t_AreaName в области g_AreaName идентично использованию области t_AreaName в области r_AreaName, и также допускает использование одновременно несколько областей таблиц внутри себя.

t_AreaName

Определяет таблицу. Внутри области данной закладки должна содержаться другая закладка с именем r_AreaName или g_AreaName. Если внутри сгенерированной таблицы не будет ни одной строки, то все объекты внутри данной области будут удалены из документа.

Пример: обрамляем диапозон r_Decided в новый диапозон t_DecidedTable.

image141 39

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

image141 40

AreaName - любое уникальное имя.

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

image141 9

В поле Адрес указывается ссылка в следующем виде: https://tessalink/?link=ссылка_с_плейсхолдерами, т.е. в нашем примере в качестве гиперссылки указываем https://tessalink/?link=tessa://tessaclient.{serverCode}?Action=OpenCard&ID={t:OutgoingRefDocs.DocID}&Name={t:OutgoingRefDocs.DocDescription}:

image141 10

Далее данную ссылку необходимо сделать в виде нумерованного списка.

После указания гиперссылки если снова открыть окно редактирования гиперссылки, то в поле Адрес можно заметить, что некоторые символы автоматически заменены, например: tessa://tessaclient.%7bserverCode%7d/?…​ Это связано с особенностями работы Word, вносить правки в ссылку не требуется, файл по шаблону будет формироваться корректно.

На рисунках ниже представлен docx шаблонный файл (на рисунке слева) и файл, сформированный из карточки входящего документа по данному шаблону (на рисунке справа):

image141 11

Аналогично можно давать ссылки на файлы и версии файлов, например, на лист согласования текущего документа: tessa://tessaclient.{serverCode}?Action=OpenCard&ID={f:DocumentCommonInfo.ID}&Name={f:DocumentCommonInfo.FullNumber}&FID=fd70bd20-ba8c-420f-9fc7-55c6c8898235&VID=bb68360d-7690-4163-b985-a0a88abe5f21.

Описание плейсхолдеров можно посмотреть в разделе Плейсхолдеры.

Примеры настроенных docx шаблонов можно посмотреть в Типовом решении (вкладка Администратор - Прочее - Шаблоны файлов):

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

8.8. Примеры создания шаблонов файлов в формате html

Пример html шаблонного файла, в котором указаны плейсхолдеры представлен на рисунке ниже (слева). Сформированный из карточки входящего документа по данному шаблону файл представлен на рисунке справа:

image141 6

Для вывода данных построчно (например, список заданий в Листе согласования) используется специальный тэг <_row> …​ {t:…​} …​ {t:…​} …​ </_row>. Всё содержимое внутри тэга дублируется для каждой строки, которая получена от плейсхолдеров внутри строки в результате выполнения запроса SQL. На рисунке ниже представлен пример части .html кода (слева) и сформированный по шаблону файл (справа):

image137 1

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

Также можно поместить всю таблицу целиком в тег <_table> …​ </_table>. Тогда в ситуации, когда табличные плейсхолдеры во внутреннем теге <_row> или <_group> не возвращают ни одной строки, то весь текст, заключенный в тег <_table> будет удален.

Примеры настроенных html шаблонов можно посмотреть в Типовом решении (вкладка Администратор - Прочее - Шаблоны файлов):

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

  • Мои задания - шаблонный файл используется для выгрузки данных из представления Мои задания.

8.8.1. Группировка в шаблонных файлах формата html

Также в html доступен тег для группировки данных в таблице - <_group>, внутри которого может быть один тэг <_row> или <_group> (для множественных группировок) и любое количество тэгов <_table> (для вложнных таблиц). Любые плейсхолдеры, входящие в <_group> и не входящие во внутренние тэги, считаются группирующими. Т.е. группировка происходит по всем плейсхолдерам ({t:…​} или {tv:…​}), которые используются в области группы. Они объединяются в строку и по ней производится группировка. В области группы также могут быть еще любые плейсхолдеры, которые возвращают скаляры (т.е. одну строку).

Параметр для плейсхолдера is group, может использоваться только в области строки (<_row>), но вне области группировки. Этот параметр переносит значение на верхний вроень группировки.

На рисунке ниже представлена часть кода html страницы, которая должна выводить список заданий (из представления Мои задания). Группировка по полю Тип задания (плейсхолдер {tv:TypeCaption}). В колонках таблицы должна отображаться информация: состояние задания, информация по заданию, выполнить к (плановая дата/время завершения задания), до завершения (срок до завершения задания), карточка (ссылка на карточку документа, отображается номер карточки):

image141 17

При формировании из представления Мои задания файла по данному шаблону результирующий документ будет выглядеть следующим образом:

image141 18

8.8.2. Многоуровневая группировка в шаблонных файлах формата html

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

image141 48

При формировании из представления Мои задания файла по данному шаблону результирующий документ будет выглядеть следующим образом:

image141 49

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

8.8.3. Вложенные таблицы в шаблонных файлах формата html

Внутрь тэгов <_row> и <_group> можно поместить один или несколько тегов <_table> для генерации вложенных таблиц внутри каждой строки или группы таблицы. У каждой строки вложенной таблицы также могут быть вложенные таблицы.

Рассмотрим пример создания Html шаблона с вложенной таблицей. Сделаем простой шаблон файла, который из представления Мои документы сразу бы выводил по каждомму документу его связанные документы.

image141 46

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

В примере также используются плейсхолдеры-объявления, с помощью которых мы указываем, что по алиасу Main у нас будут браться данные для внешней таблицы из представления Мои документы (имя представления не указывается, т.к. шаблон файла строится именно по этому представлению), а по алиасу Sub у нас будут браться данные для вложенной таблицы из представления Связанные документы, и при этом для получения данных из этого представления в качестве параметра LinkedDocID будет передаваться значение из колонки DocID из строки основной таблицы.

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

Таким образом можно получить из этих данных:

image141 44

Следующий результат:

image141 47

Описание плейсхолдеров можно посмотреть в разделе Плейсхолдеры.

8.9. Примеры создания шаблонов файлов в формате txt

Пример txt шаблонного файла, в котором указаны плейсхолдеры представлен на рисунке ниже (слева). Сформированный из карточки договора по данному шаблону файл представлен на рисунке справа:

image336

В txt шаблонных файлах для построчного вывода и группировки данных используются те же теги, что и для html: <_row>, <_group> и <_table>. На рисунке выше пример, где построчно выведена информация из секции "Ссылки". Используемый в примере форматтер #wrap описан далее.

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

8.10. Примеры создания шаблонов файлов в формате xlsx

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

Имя диапазона ячеек Описание

r_AreaName

При добавлении новых строк они добавляются путем копирования и вставки новых строк.

Пример: в таблице строка 31, где заданы алиасы плейсхолдеров (см Алиасы плейсхолдеров), указан диапазон ячеек с именем r_Decided:

image141 28

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

image141 29

В данном диапозоне может находиться неограниченное количество диапозонов t_AreaName. Каждый из них будет определять отдельную вложенную таблицу, которая формируется отдельно для каждой строки диапозона r_AreaName.

j_AreaName

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

Пример: для двух таблиц в строках 12-13, где заданы алиасы плейсхолдеров (см Алиасы плейсхолдеров), указаны диапазоны ячеек с именами соответственно j_Participants и j_Reports:

image141 26

В результирующем файле в каждую таблицу путем заполнения существующих строк добавлены все записи из карточки протокола:

image141 27

g_AreaName

Группировка строк по параметру. Внутри диапазона ячеек с группировкой может содержаться один диапазон вида r_AreaName, g_AreaName (для многоуровневых группировок) или j_AreaName. Также внутри данного диапозона может находиться неограниченное количество диапозонов t_AreaName. Каждый из них будет определять отдельную вложенную таблицу, которая формируется отдельно для каждой строки диапозона g_AreaName.

t_AreaName

Определяет таблицу. Внутри диапозона ячеек должен содержаться диапозон с именем r_AreaName, j_AreaName или g_AreaName. Если внутри сгенерированной таблицы не будет ни одной строки, то все строки, в котором располагается диапозон t_AreaName будут удалены из документа.

Пример: обрамляем диапозон r_Decided в новый диапозон t_DecidedTable.

image141 32

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

image141 33

AreaName - любое уникальное имя диапазона ячеек.

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

image141 24

Диспетчер имен (окно для просмотра, редактирования, удаления имен диапазонов) можно открыть нажав в Excel сочетание клавиш Ctrl + F3:

image141 25

Более подробно о настройке xslx шаблонного файла описано далее.

Примеры настроенных xslx шаблонов можно посмотреть в Типовом решении (вкладка Администратор - Прочее - Шаблоны файлов):

  • Мои задания (Excel) - шаблонный файл используется для выгрузки данных из представления Мои задания;

  • Протокол совещания (Excel) - шаблонный файл используется для формирования протокола совещания из карточки Протокола.

8.10.1. Группировка в шаблонных файлах формата xslx

Группировка происходит по всем плейсхолдерам ({t:…​} или {tv:…​}), которые используются в области группы. Они объединяются в строку и по ней производится группировка. В области группы также могут быть еще любые плейсхолдеры, которые возвращают скаляры (т.е. одну строку).

Параметр для плейсхолдера is group, может использоваться только в области строки (r_AreaName или j_AreaName), но вне области группировки. Данный параметр определяет, что плейсхолдер будет использоваться на самом верхнем уровне группировки (если их несколько).

В данном разделе рассмотрим пример создания шаблонного файла в формате xlsx для представления "Мои задания": вывод списка моих заданий с группировкой по одному плейсхолдеру - Тип задания.

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

t_type          tv:TypeCaption
t_state         tv:StateName
t_role          tv:RoleName
t_result        tv:TaskInfo
t_date          tv:PlannedDate
t_completed     tv:TimeToCompletion

Формируем Excel файл, где прописываем заданные алиасы плейсхолдеров. Для колонки Карточка (ссылка на карточку) указываем ссылку в следующем формате (более подробно о плейсхолдерах в разделе Плейсхолдеры):

tessa://tessaclient.{serverCode}?Action=OpenCard&ID={tv:CardID}&Name={tv:CardName}

image141 13

В данном примере будет настроена группировка по {*t_type}, т.е. типу задания.

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

Выделяем ячейки в строке с плейсхолдерами (кроме ячейки с группировкой - {t_type}) и задаем для них имя (имя указываем с обязательным служебным префиксом r_):

image141 14

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

image141 15

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

image141 16

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

image141 30

В поле Адрес указывается ссылка в следующем виде: https://tessalink/?link=ссылка_с_плейсхолдерами, т.е. в нашем примере в качестве гиперссылки указываем https://tessalink/?link=tessa://tessaclient.{serverCode}?Action=OpenCard&ID={tv:CardID}&Name={tv:CardName}.

После указания гиперссылки если снова открыть окно редактирования гиперссылки, то в поле Адрес можно заметить, что некоторые символы автоматически заменены, например: tessa://tessaclient.%7bserverCode%7d/?…​​ Это связано с особенностями работы Excel, вносить правки в ссылку не требуется, файл по шаблону будет формироваться корректно.

8.10.2. Многоуровневая группировка в шаблонных файлах формата xslx

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

image141 50

В выбранном шаблоне делаем область g_TasksByType на ячейках, выделенных синим цветом, область g_TasksbyState на ячейках, выделенных зеленым цветом и область r_Tasks на ячейках, выделенных красным цветом.

Для группировки значений для вернхнеуровневой группировки будут использоваться все плейсхолдеры, которые входят в область g_TasksByType, но не входят во вложенную область. Для внутренней группировки работает точно такая же логика, но уже на области g_TasksByState

При формировании из представления Мои задания файла по данному шаблону результирующий документ будет выглядеть следующим образом:

image141 51

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

8.10.3. Вложенные таблицы в шаблонных файлах формата xslx

Как было написано выше, внутрь групп r_AreaName и g_AreaName можно поместить одну или несколько групп t_AreaName для генерации вложенных таблиц внутри каждой строки или группы таблицы. У каждой строки вложенной таблицы также могут быть вложенные таблицы.

Рассмотрим пример создания xslx шаблона с вложенной таблицей. Сделаем простой шаблон файла, который из представления Мои документы сразу бы выводил по каждомму документу его связанные документы.

image141 52

В выбранном шаблоне делаем область r_Main на ячейках, выделенных синим цветом, область t_Sub на ячейках, выделенных зеленым цветом и область r_Sub на ячейках, выделенных красным цветом.

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

В примере также используются плейсхолдеры-объявления, с помощью которых мы указываем, что по алиасу Main у нас будут браться данные для внешней таблицы из представления Мои документы (имя представления не указывается, т.к. шаблон файла строится именно по этому представлению), а по алиасу Sub у нас будут браться данные для вложенной таблицы из представления Связанные документы, и при этом для получения данных из этого представления в качестве параметра LinkedDocID будет передаваться значение из колонки DocID из строки основной таблицы.

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

Таким образом можно получить из этих данных:

image141 44

Следующий результат:

image141 53

Описание плейсхолдеров можно посмотреть в разделе Плейсхолдеры.

8.10.4. Использование формул в шаблонных файлах формата xlsx

Система генерации файлов по шаблону поддерживает работу формул в файлах Excel при генерации файла. В эту обработку входит:

  • Сохранение позиции формулы в ячейке при перемещении строки с формулой в документе (при добавлении новых строк). Например, если формула была в ячейке A2, и перед этой строкой добавилось 5 новых строк (при генерации таблицы), то формула будет на строке A7.

    Шаблон:

    image141 54

    Результат:

    image141 55
  • Сохранение корректных ссылок в формуле на другие ячейки. Например, если формула находится в ячейке A3, а ссылается на ячейки B1 и C6, а в документ были добавлено 5 новых строк, начиная со строки 4, то в итоговом документе формула останется на позиции A3 (т.к. перед ней не было добавлено строк), а сама формула будет ссылаться на ячейки B1 (не изменилась, т.к. перед ней не было добавлено строк) и C11 (ячейка, на которую ссылалась формула, сместилась на 5 строк).

    Шаблон:

    image141 56

    Результат:

    image141 57
  • Клонирование формул внутри именованных групп, определяющих строки таблицы. Например, если формула находилась в группе r_AreaName, то при добавлении новых строк по этой группе, формула будет скопирована в каждую строку. При этом в формуле будут также актуализированы все ссылки, которые ссылаются на ячейки в r_AreaName. Например, если формула находится в ячейке A1, и ссылается на ячейки B1 и C1, и при этом указанная группа с табличными плесхолдерами r_AreaName на диапазон A1:C1, то при копировании этой строки, в новой строке 2 в ячейке A2 будет формула из A1, но ссылаться она будет уже на ячейки B2 и C2.

    Шаблон:

    image141 58

    Результат:

    image141 59
  • Расширение диапазонов ссылок из формул, которые ссылаются на именованные группы r_AreaName или g_AreaName. Если формула ссылается на ячейки именованной группы, то эта ссылка будет расширяться с увеличением числа строк, генерируемых по данной именованной группе. Для того, чтобы это расширение происходило, должно быть выполнено 2 условия:

    1. Ссылка из формулы должна покрывать всю высоту группы. Т.е., если группа r_AreaName занимает диапазон A1:B2, и на нее ссылаются 2 формулы, одна на диапазон A1:A2, другая на диапазон A1:B1. То при добавлении, например, 5 новых строк по этой именованной группе, первая формула будет ссылаться на диапазон A1:A12 (т.к. добавлено 10 строк), а вторая формула на диапазон A1:B1 (не был расширен).

      Шаблон, зеленым выделена правильная настройка, красным неправильная:

      image141 60

      Результат:

      image141 61
    2. Формула должна находиться или вне именованных групп, или в именованной группе, отличной от той, на которую ведет ссылка из формулы.

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

    Шаблон:

    image141 62

    Результат:

    image141 63

Рассмотрим пример использования формул. Для этого модифицируем шаблон файла Мои задания (Excel).

Добавим в ячейку A5, где у нас выводится тип задания, следующую формулу:

="{*t_type} ("&СЧЁТЗ(A6)&")"

Данная формула будет все также выводить тип задания, но дополнительно считать количество строк с заданиями для каждого типа. Можно убедиться, что диапазон ячеек A6 в формуле будет расширяться вместе с самой таблицей, на которую он ссылается, т.к:

  • Ссылка A6 покрывает всю высоту группы r_Tasks (выделена зеленым).

  • Формула находится в группе g_TasksByType (выделена красным), которая является родительской по отношению к группе r_Tasks (выделена зеленым), на ячейки которой она ссылается.

image141 64

Построив файл по данному шаблону можно убедиться в результате:

image141 65

8.11. Форматтеры и вставка изображений в плейсхолдеры

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

Форматтеры выводятся вместо стандартного форматирования после двоеточия (см. примеры ниже).

Также форматтеры можно объединять в цепочки, разделяя их через точку с запятой. Подробное описание цепочек форматтеров и примеры см. в разделе Цепочки форматтеров.

Список доступных форматтеров с их кратким описанием представлен в таблице (а также ссылки на соответствующие разделы с подробным описанием форматтера):

Форматтер Описание

#image

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

#barcode

Получает строку текста и вставляет её как штрих-код указанного формата.

#qrcode

Получает строку текста и вставляет её как QR-код указанного формата.

#format

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

#align

Применяется для выравнивания полученного текста.

#wrap

Применяется для выравнивания полученного текста c переносом на следующую строку, если размер превышает допустимый предел.

#file

Форматтер загружает заданный файл или версию файла по идентификатору и представляет как массив байт, который можно направить в другие форматтеры, например, в #image или #text.

#text

Форматтер представляет заданный массив байт как текст.

#cardLink и #webCardLink

Форматтеры, преобразующие входящий Guid в ссылку на карточку (в толстом и легком клиенте соответственно). Пример использования см. в разделе Цепочки форматтеров.

#noencode

Форматтер, который предотвращает вызов Encode-методов для плейсхолдера при замене его в документе. Актуально, в частности, для HTML документов, для которых в форматтере можно вставлять HTML-разметку, которая будет вставлена именно как тэги HTML, а не как обычный текст.

При использовании форматтеров, которые вставляют изображение (т.е. #image, #barcode, #qrcode) для шаблонов html на месте плейсхолдера при формировании документа по шаблону автоматически будет сгенерирован тэг объект <image />, содержащий бинарные данные изображения и разные параметры. Пример html шаблона см. в разделе Форматтер #barcode.

Для корректной вставки изображений в шаблоны форматов Word и Excel необходимо в шаблоне добавить объект типа "Надпись" и в тексте надписи указать плейсхолдер (или алиас).

Если данные, по которым строится изображение (#image), штрих-код (#barcode) или QR-код (qrcode) вернули "null" (в т.ч. только пробелы) или массив байт нулевого размера (из представления, базы данных, другого форматтера и т.д.), то в документе HTML тег <image/> не генерируется на месте плейсхолдера, а в документах Word и Excel объект "Надпись" будет удалён.

8.11.1. Форматтер #image

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

#image(w=300;h=200;img=jpeg;alt=Image text;reformat)

Описание параметров форматтера изображения:

  • w - ширина изображения, если размер не указан в параметрах, то используется либо исходный, либо тот, который есть у надписи в Word/Excel.

  • h - высота изображения, если размер не указан в параметрах, то используется либо исходный, либо тот, который есть у надписи в Word/Excel.

  • img - указывается тип изображения при вставке в документ. При этом не выполняет конвертацию, а просто указывает на исходный тип картинки. По умолчанию это PNG.

    В HTML для всех современных браузеров и в Word/Excel изображение успешно отобразится с параметром по умолчанию, даже если его тип отличен от PNG, но если вдруг возникнут проблемы и изображение не будет отображено, то можно задать тип явно. Доступны типы (соответствующие одноимённым форматам): bmp, emf, exif, gif, icon, jpeg, png, tiff, wmf. Укажите unknown, если тип неизвестен и об этом надо явно оповестить браузер или Word/Excel.
  • alt - используется, чтобы задать альтернативный текст в тех случаях, когда картинка недоступна или когда её должен прочитать голосовой помощник Windows.

    Может использоваться во всех типах шаблонов - html, Word, Excel. Для Word-а замещающий текст можно просмотреть, вызвав контекстное меню правой кнопкой мыши по изображению и выбрав пункт "Замещающий текст" (или выбрав "Формат рисунка" - для более старых версий Word). При включении голосового помощника вместо изображения будет зачитан указанный текст.

    Замещающий текст также может содержать локализацию, например:

    #qrcode(t=url;alt=$KrTypes_DocTypes_Incoming)

    Если в данном параметре требуется помимо строки локализации указать какой-то текст, то необходимо записывать в следующем формате:

    #qrcode(t=url;alt={$KrTypes_DocTypes_Incoming} - Ссылка на карточку)

    При необходимости указании плейсхолдера с таким форматтером (который содержит в себе фигурные скобки) необходимо использовать Алиасы плейсхолдеров, иначе документ не будет формироваться корректно.
  • reformat - используется только в Word/Excel. Если данное свойство не указано, то при вставке изображения в объект "надпись" все параметры надписи (включая рамку, обтекание текстом и соотношение сторон) будут сохранены. Если reformat указан, то параметры надписи будут сброшены, и они будут определяться исключительно указанной шириной/высотой (или же шириной/высотой исходного изображения). Для документа HTML свойство reformat игнорируется.

Перечисленные свойства применимы для всех форматтеров изображений. При вставке в HTML на месте плейсхолдера будет сгенерирован тэг объект <image />, содержащий бинарные данные изображения и разные параметры.

Для Word и Excel надо вставить объект типа "надпись" и в тексте надписи указать плейсхолдер (или алиас плейсхолдера). Надпись будет заменена на объект "Рисунок" с изображением.

Пример

Для примера возьмем иконку из стандартного представления "Приложения" (Администратор - Прочее - Приложения), и отобразим её в файле шаблона в виде изображения размером 300х300 пикселей.

В шаблонном документе Word создадим таблицу, в левой колонке отобразим имя приложения с помощью плейсхолдера {tv:Applications.AppName}, во второй колонке добавим две области "Надпись", в каждой из которых плейсхолдер получает иконку и с помощью форматтера отображает изображение размером 300х300: {tv:Applications.Icon:#image(w=300;h=300)}.

image277

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

image278

Форматтер #image также может сконвертировать входящее изображение в формат png:

#image(png;…​прочие параметры).

Если на входе было изображение в .bmp (или любое другое), то оно будет сконвертировано в .png. Если на входе уже был .png, то конвертация не выполняется и изображение показывается в исходном виде. В отличие от остальных перечисленых параметров, этот работает только для форматтера #image и нужен он в случае, если изображение в исходном виде не отображается в документе, или оно занимает слишком много места (как в случае с .bmp).

8.11.2. Форматтер #barcode

Форматтер штрих-кода получает строку текста и вставляет её как штрих-код. Штрих-код всегда выводится как изображение png.

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

Форматтер может содержать как все вышеперечисленные параметры (описанные в разделе Форматтер #image), так и параметр t, где указывается тип штрих-кода.

Возможные типы штрих-кодов (описание типа можно найти по названию в интернете): UPCA, UPCE, UPC_SUPPLEMENTAL_2DIGIT, UPC_SUPPLEMENTAL_5DIGIT, EAN13, EAN8, Interleaved2of5, Standard2of5, Industrial2of5, CODE39, CODE39Extended, CODE39_Mod43, Codabar, PostNet, BOOKLAND, ISBN, JAN13, MSI_Mod10, MSI_2Mod10, MSI_Mod11, MSI_Mod11_Mod10, Modified_Plessey, CODE11, USD8, UCC12, UCC13, LOGMARS, CODE128, CODE128A, CODE128B, CODE128C, ITF14, CODE93, TELEPEN, FIM, PHARMACODE.

Если формат не указан, то используется формат по умолчанию - CODE128.

Пример

Создадим шаблон файла для входящего документа, где будет выводиться номер документа в виде штрих-кода. В шаблоне добавляем область "Надпись", где указываем плейсхолдер для получения номера карточки и форматтер для вывода штрих-кода:

{f:DocumentCommonInfo.FullNumber:#barcode(t=ean13;w=150;h=30)}

В результирующем файле мы видим сформированный штрих-код (правый рисунок):

image279

Чтобы в Word/Excel изображение выводилось без "рамки", можно либо использовать параметр reformat, описанный выше, либо в формате фигуры средствами Word/Excel убрать границу у надписи.

Аналогичный пример в формате html:

image281

Может быть указан опциональный параметр l, позволяющий вывести метку с текстом штрих-кода рядом с изображением. По умолчанию метка не выводится. Текст выводится как часть изображения и вставляется соответствующим образом в документ. Если вам нужно вставить текстовое представление штрих-кода как текст, то вместо этого параметра добавьте в шаблон файла второй текстовый плейсхолдер, связанный с тем же полем.

Возможные значения параметра l (без учёта регистра): None (метка не выводится), TopLeft (метка с текстом выводится сверху слева от изображения), TopCenter (метка с текстом выводится сверху по центру от изображения), TopRight (метка с текстом выводится сверху справа от изображения), BottomLeft (метка с текстом выводится снизу слева от изображения), BottomCenter (метка с текстом выводится снизу по центру от изображения), BottomRight (метка с текстом выводится снизу справа от изображения).

Пример

Используем параметр l для вывода метки снизу по центру от графического представления:

{f:DocumentCommonInfo.FullNumber:#barcode(t=ean13;l=bottomcenter;w=150;h=30)}

image369

8.11.3. Форматтер #qrcode

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

Например, может быть QR-код со ссылкой на веб-страницу (URL), телефонным номером для возможности позвонить по этому номеру или добавить его в контакт, адресом email, на который надо написать письмо, и др.

Помимо параметров, описанных в разделе Форматтер #image у данного форматтера есть еще дополнительные параметры:

  • t - задается тип QR-кода. Доступны следующие типы:

    • Text - QR-код, вставляемый в виде текста.

    • Url - QR-код, вставляемый как URL-ссылка. Если протокол не указан, то используется http://.

    • Email - QR-код, вставляемый как mailto-ссылка для заданного email получателя.

    • SMS - SMS-сообщение, отправляемое на заданный телефонный номер.

    • MMS - MMS-сообщение, отправляемое на заданный телефонный номер.

    • Phone - QR-код, вставляемый как телефонный номер.

    • Skype - QR-код, вставляемый как звонок заданному пользователю Skype.

    • WhatsApp - QR-код, вставляемый как WhatsApp-сообщение заданному пользователю.

      Если тип не указан, то используется тип по умолчанию t=Text.

  • ecc - определяет уровень коррекции ошибок для генерируемого QR-кода, т.е. определяет объём нечитаемой информации, при наличии которой QR-код всё равно корректно распознаётся смартфоном. Более высокий уровень означает больший размер генерируемого изображения. Доступны следующие варианты:

    • L - 7% информации может быть потеряно.

    • M - 15% информации может быть потеряно.

    • Q - 25% информации может быть потеряно.

    • H - 30% информации может быть потеряно.

      Если параметр не указан, по умолчанию используется ecc=Q.

  • utf8 - определяет факт того, что текст кодируется в UTF8 внутри QR-кода. Если флаг не указан, то используется другая кодировка, определяемая стандартном QR-кода, обычно это ISO-8859-1.

    Этот параметр может влиять на считывание QR-кода некоторыми устройствами. По умолчанию не рекомендуется указывать.

  • bom - определяет необходимость вставки специальных символов BOM (byte order mark) в начале строки для кодирования UTF-8; используется совместно с флагом utf8.

    Этот параметр может влиять на считывание QR-кода некоторыми устройствами. По умолчанию не рекомендуется указывать.

  • px - количество пикселей в т.н. блоке QR-кода, который влияет на размер генерируемого изображения (или на чёткость изображения при вставке в документ с явно указанными размерами).

    По умолчанию значение px=2, допустимо значение "1" или больше.

Пример

В шаблон файла для входящего документа добавим QR-код для звонка контактному лицу контрагента, указанного в карточке.

Для отображения QR-кода создадим область "Надпись", где укажем плейсхолдер для получения номер телефона контактного лица контрагента и форматтер для вывода QR-кода типа Phone:

{f:DocumentCommonInfo.PartnerID->Partners.Phone:#qrcode(t=phone)}

В результирующем файле мы видим сформированный QR-код (правый рисунок):

image280

8.11.4. Форматтер #format

Форматтер аналогичен форматированию в плейсхолдерах, т.е. {f:DocumentCommonInfo.DocDate:dd.MM.yyyy} и {f:DocumentCommonInfo.DocDate:#format(f=dd.MM.yyyy)} равнозначны и вернут одинковый результат.

Данный форматтер нужен, чтобы иметь возможность передать его дальше по цепочке форматтеров. Например, генерируем QR-код по строке с датой: {f:DocumentCommonInfo.DocDate:#format(f=dd.MM.yyyy);qrcode}

Также он может использоваться для локализации полученных данных. Например, если в поле "Тема" карточки документа помимо обычного текста вставлена строка локализации, то для корректного вывода в шаблоне необходимо указать:

{f:DocumentCommonInfo.Subject:#format(localize)}

при этом строка локализации на входе должна быть в формате $String или text {$String} text.

8.11.5. Форматтер #align

Форматтер #align используется для выравнивания текста в заданном направлении:

#align(right=30;trim;char=.)

Описание параметров форматтера выравнивания:

  • right=N/center=N/left=N - направление выравнивания текста, где N - количество символов, до которых необходимо выравнивать текст.

  • trim - если параметр указан, то при превышении допустимого размера произойдет обрезание строки.

  • char - символ, используемый для выравнивания. Можно указывать символ или код Unicode. Например: char=. или char=0x002E. Если параметр не указан, то используется пробел.

Пример

Шаблон в формате txt, который выводит тему документа, дополнив строку точками, длина строки - 25 символов. В случае превышения (тема документа более 25 символов), строка будет обрезана:

{f:DocumentCommonInfo.Subject:#align(center=25;trim;char=.)}

image324

Документ, сформированный по данному шаблону с темой, имеющей длину менее 25 символов:

image325

Документ, сформированный по данному шаблону с темой, имеющей длину более 25 символов:

image326

8.11.6. Форматтер #wrap

Форматтер #wrap аналогичен форматтеру #align (параметр trim не поддерживается). При превышении допустимого значения происходит перенос остатка на следующую строку.

Данный форматтер корректно функционирует только для текстовых файлов формата .txt.
Пример

Возьмем тот же пример, что и для форматтера #align, где строка была обрезана. Только в данном случае выполним перенос строки с помощью форматтера #wrap:

{f:DocumentCommonInfo.Subject:#wrap(center=25;char=.)}

image327

Документ, сформированный по данному шаблону:

image328
Обратите внимание, что в шаблонном файле для корректной работы переноса строк неоходимо после плейсхолдера с форматтером #wrap добавить перенос строк.

На рисунке ниже пример, где видны переносы строк.

image331

По такому шаблону файл будет сформирован корректно, как на рисунке выше. Если же в конце не добавить перенос строк, например:

image332

То по данному шаблону файл сформируется вот в таком виде:

image333

8.11.7. Цепочки форматтеров

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

Пример

Выведем список ссылок на карточки (из поля "Ссылки в документе") и QR-коды для открытия карточек по ссылкам в веб клиенте на смартфоне.

В первой колонке таблицы запишем: {t:OutgoingRefDocs.DocDescription order by Order} - упорядоченный список ссылок, во второй колонке создадим область "Надпись", где укажем плейсхолдер {t:OutgoingRefDocs.DocID order by Order:#webCardLink;qrcode(t=url)} - в каждой строке таблицы для идентификатора документа, на который ведёт ссылка, генерируем адрес веб-клиента (для открытия ссылки в браузере), а затем по адресу (как по строке текста) генерируем QR-код типа "URL" (ссылка).

image282

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

8.11.8. Форматтер #file

Форматтер #file загружает заданный файл или версию файла по идентификатору и представляет как массив байт, который можно направить в другие форматтеры, например, в #image или #text, т.е. по сути позволяет приложенные к карточке файлы изображений отобразить в шаблоне файла.

Пример

В документе добавим таблицу из одной колонки, внутри колонки создадим объект "Надпись", в которой укажем следующую конструкцию:

{t:Files.RowID:#file;image}

Результат создания файла по шаблону из карточки, к которой приложено три файла изображений:

image283

В данном примере мы ищём файл по идентификатору #file, далее массив байт передаем в форматтер #image, который формирует изображение.

Для поиска файла по идентификатору версии файла форматтер используется с параметром version, например: {t:Files.VersionRowID:#file(version);image(w=120;h=60)}.

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

Также идентификатор можно указать прямо в плейсхолдере, например: {text:4e4eb070-2333-40bd-8516-7e7c4592fbf4:#file;image}.

8.11.9. Форматтер #text

Форматтер #text представляет заданный массив байт как текст. Массив байт можно получить непосредственно из поля карточки, представления, или как в примере выше, из форматтера #file (т.е. из файла или версии файла с заданным идентификатором).

Для данного форматтера есть параметр t, в котором можно указать кодировку, например: {t:Files.RowID:#file;text(t=utf16)}.

Если для форматтера кодировка не задана, то текст берется в соответствующей кодировке Unicode на основании BOM (byte order mark - специальные нечитаемые символы в начале текстового файла), если он есть. Если BOM нет, то используется ANSI (это кодовая страница, заданная в региональных параметрах учётной записи Windows, например, страница 1251 для русскоязычного Windows).

Указать кодировку можно или из следующих значений (без учёта регистра):

  • utf7 - UTF-7

  • utf8 - UTF-8

  • utf16 или utf16le - UTF-16 Little Endian

  • utf16be - UTF-16 Big Endian

  • utf32 - UTF-32

  • ascii - ASCII

Или указав кодовую страницу, которая известна в .NET, подробнее в MSDN.

9. Система прав доступа к карточкам, включенным в типовое решение

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

9.1. Основные принципы работы системы прав доступа

В данном разделе тезисно указаны принципы работы системы прав доступа в Tessa.

  • В системе нет запрещающих правил доступа (за исключением запретов для отдельных секций/вкладок в расширенных правилах доступа). По умолчанию в системе всё запрещено, а правилами доступа выдается доступ кому-либо к чему-либо.

  • Правила доступа никак не влияют на видимость строк в представлении. Видимость строк регулируется SQL запросом представления.

  • Доступ к кнопкам запуска/отзыва различных процессов настраивается в карточках вторичных процессов или в карточках шаблонов процессов.

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

  • Права доступа наследуются по замещению.

  • С помощью расширенных прав доступа можно:

    • настроить доступ к отдельных полям и секциям карточки или задания;

    • маскировать данные;

    • указать видимость контролов и обязательность заполнения полей;

    • гибко настроить доступ к файлам.

9.2. Общий механизм расчёта прав доступа к карточке

Доступ к карточкам документов осуществляется согласно карточкам правил доступа и заданиям процесса, которые находятся в карточке.

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

9.3. Карточка правил доступа

Создавать и редактировать карточки правил доступа могут только сотрудники, имеющие уровень доступа "Администратор". Создать новую карточку можно из правого меню "Создать карточку → Настройки → Правило доступа" или кнопкой создания в представлении "Администратор → Типовое решение → Правила доступа":

image142

Внешний вид основной вкладки карточки:

image143

В карточке правил доступа указывается:

  • Тема карточки – обязательное поле, указывается краткое название карточки.

  • Описание – необязательное поле, указывается информация, раскрывающая тему карточки.

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

    Пример

    Если в правиле доступа не выставлен флаг и при этом пользователь открывает карточку, находящуюся в состоянии, отличном от "Проект", доступную ему по этому правилу доступа на чтение и редактирование, то карточка открывается только на чтение.

    Для перехода в режим редактирования пользователю необходимо в левом меню нажать на кнопку "Редактировать", система выполнит расчёт прав и если есть какие-либо права, помимо чтения карточки, эти права буду предоставлены. В данном примере, после нажатия на кнопку "Редактировать", поля карточки откроются на редактирование.

    Если в этом же правиле доступа выставить флаг, то та же карточка документа (доступная по правилу доступа на чтение и редактирование и находящаяяся в состоянии, отличном от "Проект") откроется сразу на редактирование, т.е. нет необходимости пользователю нажимать кнопку "Редактировать" в левом меню системы.

    Все расширенные настройки правил доступа к карточке также применяются без нажатия кнопки "Редактировать", если установлен данный флаг.
    Не рекомендуется выставлять данный флаг в правилах доступа без острой необходимости, потому что каждое правило доступа с таким флагом даёт ощутимую нагрузку на БД (особенно в системе с большим количеством пользователей), т.к. при каждом открытии карточки любым пользователем будет выполняться дополнительный расчёт по таким правилам, хотя в большинстве случаев пользователи открывают карточки только для просмотра информации или выполнения заданий, т.е. без необходимости редактирования карточки. Для карточек в состоянии "Проект", не зависимо от данного флага, права всегда рассчитываются сразу при открытии.
  • Отключить правило доступа - флаг указывает, что данное правило отключено и его настройки не учитываются при расчёте прав доступа.

  • Типы – обязательное поле, типы карточек, включенных в типовое решение, к которым применяется правило.

  • Состояния карточек – состояния карточек, в которых будут работать определенные ниже разрешения.

  • Список ролей – обязательное поле; роли, для которых выдаются указанные права для указанных типов карточек в указанных состояниях. В списке ролей можно указать, в том числе, и контекстные роли, например, "Инициатор" или "Создатель карточки".

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

  • Список разрешений – разрешения, выдаваемые для указанных типов карточек в указанных состояниях для пользователей, состоящих в указанных ролях. Право на создание карточки не зависит от указанных состояний.

Внешний вид вкладки с расширенными настройками правил доступа:

image144

Более подробно расширенные настройки прав доступа описаны в раздел Расширенные настройки прав доступа.

9.4. Права доступа к карточке

Существуют следующие права доступа к карточке:

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

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

  • Чтение карточки – пользователь может открывать карточку и просматривать ее содержимое.

  • Редактирование карточки – пользователь может редактировать поля карточки (кроме маршрута, номера документа и файлов, доступ, к редактированию которых, определяется отдельными правами). Может быть ограничен с помощью расширенных настроек правил доступа к карточке.

  • Редактирование маршрута – пользователь может редактировать маршрут (кроме активных и завершенных этапов).

  • Полный пересчёт маршрута - пользователь может выполнять пересчёт маршрута в карточке документа (доступна кнопка "Пересчитать" на вкладке "Маршрут").

  • Пропуск этапов - пользователь может пропускать этапы в маршруте согласования. Имеет более высокий приоритет, чем флаг "Разрешён пропуск" в настройках этапа.

  • Ручное редактирование номера – пользователь может изменять номер документа.

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

  • Добавление файлов – пользователь может добавлять файлы в карточку.

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

  • Редактирование всех файлов – пользователь может редактировать любые файлы карточки.

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

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

  • Удаление карточки – пользователь может удалить карточку.

  • Инициация типового процесса отправки задач – пользователь может создавать задачи для этого документа, а также отправлять документ на ознакомление.

  • Добавление обсуждений - пользователь может создавать новые обсуждения.

  • Права супермодератора - пользователь имеет права супермеодератора. Это дает доступ ко всем обсуждениям карточки, а также позволяет добавлять в качестве участников обсуждения роли.

  • Подписка на уведомления - пользователь может включать/отключать подписку на уведомления по карточке.

  • Редактировать мои сообщения - пользователь может редактировать свои сообщения в обсуждениях, которые ему доступны.

  • Редактировать все сообщения - пользователь может редактировать все сообщения в обсуждениях, которые ему доступны.

    На работу флагов Редактировать мои сообщения и Редактировать все сообщения влияет поле Редактировать сообщения не старше, чем в карточке Настройки сервера, в котором можно указать период в минутах, в течении которого можно редактировать сообщения, начиная с момент отправки. При этом значение 0 означает, что редактировать разрешено без ограничения времени, а пустое значение - редактировать запрещено.

9.5. Расширенные настройки прав доступа

Подсистема прав доступа поддерживает расширенные настройки прав доступа.

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

Если флаг снять, то все элементы управления расширенными настройками исчезнут, при этом сами настройки не будут удалены, но они не будут учитываться при расчёте прав доступа.
image144

Вкладка содержит следующие поля и таблицы:

  • Приоритет - определяет приоритетность расширенных настроек правила доступа. Чем больше число, тем больше приоритет. Актуально для настроек прав доступа карточки, заданий и видимости.

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

  • Расширенные настройки прав доступа заданий - таблица с настройками доступа к секциям и полям заданий карточки, для которой производится расчёт прав доступа. Аналогично настройкам для карточки, только применяется к заданиям карточки.

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

  • Расширенные настройки видимости - таблица с настройками видимости контролов карточки. Управление контролами идет по их Alias. Данные настройки позволяют скрыть вкладки, блоки или контролы по имени, а также показать скрытые контролы.

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

9.5.1. Расширенные настройки прав доступа карточки

Каждая строка таблицы определяет отдельное правило доступа к секции или полям секции в карточке. В этом правиле можно настроить доступ к полю, ко всей секции, а также указать, что контролы, настроенные на данные поля/секции должны быть скрыты в карточке.

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

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

Каждое правило содержит следующие настройки:

  • Секция - секция карточки, к которой применяется данное правило. Обязательное для заполнения поле. Если карточка не использует данную секцию (секция не добавлена в типе карточки), то данное правило применяться не будет.

  • Поля - набор полей из секции, для которых применяется данное правило. Если не заполнено, то правило применяется ко всей секции.

  • Настройка доступа - определяет настройку доступа для секции/полей данного правила. Если не заполнено, то настройка доступа не применяется (но все еще может быть применена настройка скрытия контрола, настроенного на данную секцию/поле карточки).

    Может иметь одно из следующих значений:

    • Разрешить редактирование - доступ на редактирование секции/полей карточки разрешен, даже если в правиле не установлен флаг доступа "Редактирование карточки".

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

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

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

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

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

  • Заменить данные на - значение, на которое заменяются замаскированные данные. Поле доступно только при установке в качестве Настройки доступа значения Замаскировать данные.

  • Скрыть контрол - флаг определяет, что контролы для данной секции/полей должны быть скрыты при просмотре карточки. Физически данные передаются в пакете карточки (если не установлена настройка доступа Замаскировать данные).

9.5.2. Расширенные настройки прав доступа заданий

Каждая строка таблицы определяет отдельное правило доступа к секции или полям секции в заданиях. В этом правиле можно настроить доступ к полю, ко всей секции, а также указать, что контролы, настроенные на данные поля/секции должны быть скрыты в заданиях карточки. В правиле определяется список типов задания, для которых применяется данное правило.

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

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

Каждое правило содержит следующие настройки:

  • Типы заданий - список типов заданий, для которых применяется данное правило.

  • Секция - секция задания, к которой применяется данное правило. Обязательное для заполнения поле. Если задание не использует данную секцию (секция не добавлена в типе задания), то данное правило применяться не будет.

  • Поля - набор полей из секции, для которых применяется данное правило. Если не заполнено, то правило применяется ко всей секции.

  • Настройка доступа - определяет настройку доступа для секции/полей данного правила. Если не заполнено, то настройка доступа не применяется (но все еще может быть применена настройка скрытия контрола, настроенного на данную секцию/поле карточки).

    Может иметь одно из следующих значений:

    • Разрешить редактирование - доступ на редактирование секции/полей карточки разрешен, даже если в правиле не установлен флаг доступа "Редактирование карточки".

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

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

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

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

  • Скрыть контрол - флаг определяет, что контролы для данной секции/полей должны быть скрыты при просмотре задания. Физически данные передаются в пакете задания.

9.5.3. Расширенные настройки обязательности полей

Каждая строка таблицы определяет отдельное правило проверки обязательности заполнения полей карточки или задания при сохранении карточки или при завершении задания.

Каждое правило содержит следующие настройки:

  • Секция - секция карточки или задания, к которой применяется данное правило. Обязательное для заполнения поле. Для коллекционной секции, если не заданы Поля, то проверяется наличие строк в данной секции.

  • Поля - набор полей из секции, для которых применяется данное правило. Обязательно для заполнения для строковой секции. Для коллекционной секции, если не задано, то проверяется наличие строк в секции.

  • Тип проверки обязательности - определяет настройку проверки обязательности секции/полей данного правила. Обязательно для заполнения.

    Может иметь одно из следующих значений:

    • Всегда - проверка обязательности выполняется всегда, когда сохраняется карточки.

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

    • При завершении задания - проверка обязательности выполняется, когда завершается задания с заданным вариантом завершения.

  • Типы заданий - список типов заданий для которых должна выполняться проверка обязательности при завершении задания. Доступно и обязательно для заполнения при указании типа проверки обязательности При завершении задания.

  • Варианты завершения - список вариантов завершения для которых при завершении задания с одним из заданных вариантов должна выполняться проверка обязательности при завершении задания. Если не заполнено, то проверка выполняется при завершении задания с любым вариантом завершения.

  • Текст сообщения об ошибке - текст ошибки, который выводится пользователю, когда проверка обязательности не выполнена.

9.5.4. Расширенные настройки видимости

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

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

Для правил с одинаковым приоритетом при воздействии на один и тот же элемент управления поведение не определено.

Каждое правило содержит следующие настройки:

  • Тип контрола - определяет тип элемента управления, для которого применяется правило (контрол, блок, вкладка).

  • Имя контрола - определят имя элемента управления (алиас), для которого применяется правило. Данное поле поддерживает символ подстановки "*" в начале и в конце. Например, строка "*Button*" скрывает/показывает все элементы управления, имя которых содержит слово "Button".

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

9.5.5. Расширенные настройки доступа к файлам

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

Каждое правило содержит следующие настройки:

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

  • Расширение файла - список расширений файлов, записанные через пробел, для которых будет применено данное правило. Если не заполнено, то правило применяется для файлов с любым расширением.

    Пример заполнения поля - "txt pdf docx" (без кавычек). Правило будет применено к файлам с расширением txt, pdf и docx.
  • Проверять доступ к собственным файлам - если флаг установлен, то доступ будет проверяться ко всем не виртуальным файлам карточки, а если не установлен - то ко всем файлам, создателем которых не является сотрудник, для которого проверяется правило доступа.

  • Настройка доступа к файлу - определяет доступ к файлу, для которого применимо данное правило.

    Может иметь одно из следующих значений:

    • Доступна только последняя версий файла - пользователь видит только последнюю версию файла.

    • Доступны только свои версии и последняя версия файла - пользователь видит только те версии, которые добавил он, и последнюю версию файла.

    • Содержимое файла недоступно - пользователь не может просмотреть файл, однако видит атрибуты файла (размер, название, кем создан, категорию). Просмотр истории версий недоступен.

    • Файл недоступен и скрыт - пользователь не видит данный файл в карточке. Информация о файле даже физически не передается пользователю в пакете карточки.

9.6. Представление правил доступа

Просмотреть и открыть карточки правил доступа можно в соответствующем представлении "Правила доступа", которое находится в рабочем месте администратора, в папке "Типовое решение". В представлении отображается вся информация, указанная в карточке правил:

image146

Для представления доступны сабсеты по указанным разрешениям, состояниям карточки, указанным ролям и типам карточек:

image147

Также для представления доступны поисковые параметры – название, описание, тип, состояние, роль, разрешение, сотрудник, приоритет, отключено, всегда проверять и включены расширенные настройки:

image148

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

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

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

image146.2

В данном представлении правила доступа, у которых включены расширенные настройки, в имени правила доступа есть приписка Расширенные настройки. Если в правиле доступа включен флаг Всегда проверять правило доступа, то данная строка подсвечивается желтым цветом. Если правило доступа отключено, то данная строка подсвечивается серым цветом.

Расширенные настройки правил доступа можно посмотреть через отдельное представление "Расширенные правила доступа", которое представляет из себя master-detail представление "Правила доступа" и набора представлений для отображения расширенных настроек доступа:

image146.1

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

9.7. Права доступа, определяемые этапом согласования/подписания

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

image149

Для параллельного этапа включение этих опций может стать причиной конфликта сохранения, о чем написано в информационном блоке около этих флагов.

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

9.8. Определение прав доступа при создании карточки

Пользователь, не имеющий прав на создание карточки определенного типа (на момент запуска TessaClient) не увидит элемента панели создания карточки этого типа. Тем не менее, при попытке создания карточки происходит проверка возможности действия – если есть правила доступа, в которых указан пользователь (или роль, в которую он входит) и отмечено право создания карточки типа создаваемой карточки, то пользователь успешно создаст карточку. Если пользователь после запуска клиента успел утратить права на создание карточки такого типа, будет отображено соответствующее сообщение об ошибке:

image151

При расчёте правил доступа к карточке при ее создании фильтрация правил доступа не производится по состояниям и по таблице "Условия", указанным в настройках правила. Вместо этого выполняются только те правила, в которых установлен флаг "Создание карточки".

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

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

Как было указано выше, при создании карточки не учитываются состояния и условия из правил доступа, однако, не запрещается создавать правила доступа, где стоит флаг "Создание карточки" и при этом указаны состояния и условия. Такое правило можно сделать и оно будет работать - до сохранения карточки без учета состояний и условий, после сохранения - с их учетом. Такие правила доступа настраиваются, как правило, когда нет необходимости разделять уровень прав для создаваемой и сохраненной карточки. Но такое правило доступа категорически не подойдет, например, при таком кейсе: документ могут создавать все пользователи, а редактировать могут только свои карточки - тут понадобится создавать два правила доступа.

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

9.9. Определение прав доступа при чтении карточки

Определение прав, которыми обладает пользователь при открытии карточки, происходит в зависимости от типа карточки, состояния карточки, заданий карточки, данных карточки и настроек этапов процесса.

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

  2. Если в карточке есть задание на доработку и текущий пользователь - исполнитель:

    • Если задание не в работе – пользователь может читать карточку.

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

  3. Если в карточке есть задание согласования или подписания и текущий пользователь – исполнитель:

    • Если задание не в работе – пользователь может читать карточку.

    • Если задание в работе – пользователь может читать карточку и добавлять файлы (и редактировать ранее добавленные им файлы). Также, этапом согласования/подписания могут быть даны права на редактирование карточки и редактирование файлов.

  4. Если в карточке есть задание комментирования и текущий пользователь исполнитель – пользователь может читать карточку и добавлять файлы (и редактировать ранее добавленные им файлы).

  5. Если карточка находится в состоянии "Проект" - пользователь открывает карточку сразу со всеми правами, которыми он обладает согласно определенным правилам.

  6. Если пользователю карточка направлена на ознакомление - пользователь может читать карточку.

  7. Если в правиле доступа установлен флаг "Всегда проверять правило доступа", то все настройки данного правила доступа будут применены при расчёте прав.

  8. Во всех иных случаях при чтении карточки проверяется только наличие прав на чтение, и карточка открывается только для чтения.

В случае если карточка открыта не со всеми правами, которые требуются пользователю, пользователь может нажать на кнопку "Редактировать" в левом меню системы:

image152

При нажатии на кнопку "Редактировать" карточка будет открыта со всеми правами, определенными для пользователя. Выход из режима редактирования осуществляется путем обновления карточки с помощью соответствующей кнопки в левом меню системы или нажатием клавиши [F5]. Если при расчёте прав не было получено право на редактирование непосредственно карточки, пользователь увидит информационное сообщение со списком полученных прав:

image153

Если на момент нажатия на кнопку "Редактировать" карточка содержала несохраненные изменения, система предложит на выбор предварительно сохранить изменения, отказаться от изменений или не переходить в режим редактирования (опции "Да", "Нет", "Отмена" соответственно):

image154

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

9.10. Определение прав доступа при удалении карточки, возврате карточки на доработку, отзыве и отмене процесса

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

Права на удаление карточек определяются правилами доступа. Права на возврат карточки на доработку, отзыв и отмену процесса настраиваются в соответствующих вторичных процессах (вкладка Администратор → Маршруты → Вторичные процессы).

9.11. Некоторые примеры расчёта прав доступа на карточку

9.11.1. Пример 1 – чтение карточки

Карточка типа "Документ" создана и находится в состоянии "Проект".

В карточке правил доступа "Правило 1" в типах указан "Документ", в состояниях указан "Проект" и др., в ролях указан "Пользователь 1", отмечено право на чтение карточки.

В карточке правил доступа "Правило 2" в типах указан "Документ", в ролях указана роль "Отдел 1", в которую входит пользователь, отмечено право на редактирование карточки.

В карточке правил доступа "Правило 3" в типах указан "Документ", в ролях указана роль "Сотрудник отдела создателя карточки", отмечено право на редактирование маршрута.

При открытии карточки будут выбраны правила, в которых указан тип "Документ", состояние "Проект" и не контекстные роли, в которые включен пользователь. Согласно выбранным правилам пользователь получит возможность читать и редактировать карточку.

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

Далее будут выбраны контекстные роли для типа "Документ" и состояния "Проект" и соответствующие им наборы разрешений. Если "Пользователь 1" входит в роль "Сотрудник отдела создателя карточки", то он получит право на редактирование маршрута.

9.11.2. Пример 2 – создание карточки

Пользователь "Пользователь 1" пытается создать карточку типа "Договор"

Определено правило доступа "Правило 1" для типа "Договор", роли "Отдел 1" и "Отдел 2", отмечено право на создание и редактирование карточки.

При попытке создания карточки "Договор" будет проверено наличие правил, в которых указан тип "Договор", отмечено право на создание карточки и указаны роли, в которые входит пользователь. Т.к. карточка еще не создана – у нее нет состояния, поэтому правила будут выбираться без фильтрации по состоянию. Также будут игнорироваться контекстные роли, т.к. для несуществующей карточки невозможно определить содержание контекстной роли. Если такие правила существуют – пользователь сможет создать карточку. Таким образом, если пользователь входит в роль "Отдел 1" или в "Отдел 2", он успешно создаст карточку и получит доступ к ней в соответствии с настройками правил доступа, а после первого сохранения доступ к карточке будет определяться стандартным для открытия карточки образом.

9.11.3. Пример 3 – чтение карточки, отмена согласования, удаление карточки

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

Определено правило доступа "Правило 1" для типа "Входящий", состояния "Отмена", для контекстной роли "Создатель карточки" и отмечено право удаления карточки.

В карточке вторичного процесса "Отменить процесс" не указаны типы (т.е. кнопка будет доступна для всех типов карточек), указана роль "Отдел 1", в которую входит пользователь, состояние - "На согласовании".

Карточка содержит не взятое в работу задание комментирования для роли "Все сотрудники", в которую входит "Пользователь 1".

Система дает пользователю "Пользователь 1" доступ на чтение карточки, т.к. есть задание комментирование для "Все сотрудники" и "Пользователь 1" является исполнителем задания, хотя оно еще не взято в работу.

"Пользователь 1" может отменить процесс согласования, и отмена пройдет успешно согласно настройкам карточки вторичного процесса, который отвечает за отмену процесса.

После отмены процесса пользователь может удалить карточку, т.к. он является создателем карточки и входит в контекстную роль "Создатель карточки", для которой доступно удаление карточки в состоянии "Отмена".

10. Права на просмотр отчетов

В типовом решении предустановлено два вида отчетов (вкладка Пользователь, папка Отчеты): Текущие задания, Завершенные задания.

В зависимости от роли, пользователям доступна следующая информация в отчетах:

  • Администратор - отчет по заданиям всех сотрудников и департаментов в системе;

  • Руководитель департамента - доступен отчет по заданиям всех сотрудников департамента данного руководителя;

  • Сотрудник - доступен отчет только по своим заданиям в системе.

Также, при необходимости, сотрудникам может быть настроен доступ на отчеты по другим департаментам или сотрудникам.

Добавить права на просмотр отчётов можно перейдя на рабочее место Администратор, в представление Типовое решение → Права на текущие отчёты:

image154 1

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

  • Тема - описание карточки доступа на отчеты;

  • Кто может смотреть - список сотрудников, департаментов или ролей, кто сможет просматривать указанные отчеты;

  • Кого можно смотреть - список департаментов или сотрудников, чьи отчеты по заданиям будут доступны указанным сотрудникам/ролям:

image154 2

Таким образом можно создать нужное количество карточек с правами на просмотр отчетов.

11. Уведомления

11.1. Карточка уведомления

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

Карточка уведомления представляет из себя настройки, по которым система сформирует письмо и отправит его пользователю". Создать карточку уведомления можно из правой панели "Создать карточку → Справочники → Уведомление".

image342

Уведомление во многом похоже на шаблон файла html и настраивается похожим образом при помощи плейсхолдеров.

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

Описание - подробное опиание карточки, для чего она используется.

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

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

Тема письма - при помощи плейсхолдеров тут можно сформировать тему письма.

Текст письма - тело письма в формате html.

Подробно о плейсхолдерах и шаблонах файлов вы можете прочитать в разделе Шаблоны файлов и плейсхолдеры.

Список карточек уведомлений можно найти на рабочем месте Администратор в представлении Типовое решение → Уведомления.

11.2. Типы уведомлений

Карточки типов уведомлений найти и создать новые можно в представлении Типовое решение → Типы уведомлений:

image412

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

image413
  • Название - понятное название типа уведомления, можно указать строку локализации.

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

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

  • Типы карточек - типы карточек, по которым пользователи смогут подписаться на уведомления, относящиеся к данному типу уведомления (при наличии соответствующих прав доступа). Подписка на уведомления осуществляется непосредственно из карточки документа. Поле доступно для редактирования только при выставленном флаге "Можно подписаться".

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

12. Типы условий

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

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

  • Правила доступа.

  • Настройки правил уведомлений пользователя.

  • Виртуальные файлы (см. Виртуальные файлы).

  • Действие Условие в конструкторе бизнес-процессов.

image371

Карточка типа условия содержит следующие поля:

  • Имя - имя условия, которое будет отображаться пользователю при выборе типа условия.

  • Тип карточки настроек - тип карточки, настройки которой будут использованы для создания редактора условия с данным типом. Если не задано, то у условий данного типа не будет редактора (аналогично выбору типа "Без редактора").

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

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

    Например: "Тип документа: <_row>{t:CollectionSectionName.TypeName separate by (, )}; </_row>" - в качестве описания условия будет текст, содержащий список значений из поля "TypeName" строк секции "CollectionSectionName", разделенных через запятую.

  • Условие - скрипт условия, которое будет выполнятся при проверке условия с данным типом. Должен вернуть значение типа bool.

12.1. Заполнение таблицы с условиями

Таблица с условиями выглядит следующим образом:

image372

Условия, указанные в одной таблице, проверяются с логическим оператором "И". Т.е. для выполнения проверяемого действия, к которому относится настраиваемая таблица, все условия должны быть выполнены. Проверка условий производится сверху вниз.

image373

В каждом условии данной таблицы есть следующие настройки:

  • Тип условия - определяет тип условия. На основе данного поля в настройках условия формируются другие поля.

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

После завершения редактирования условия, на основе типа условия и его настроек формируется описание условия, которое отображается в талице с условиями.

13. Виртуальные файлы

В системе есть возможность создать карточки виртуальных файлов, по настройкам которых система добавляет виртуальные файлы при открытии карточек документов. Сами файлы генерируются на основе шаблонов файлов, указанных в настройках виртуальных файлов (см. раздел Шаблоны файлов) и, соответственно, поддерживаются все те же форматы файлов, что и для шаблонов файлов: html, txt, docx, xlsx.

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

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

image374

Карточка виртуального файла содержит следующие настройки:

  • Название - уникальное название виртуального файла.

  • Шаблон файла - шаблон файла, на основе которого генерируется текущая версия виртуального файла.

  • Имя файла (пусто - определяется из шаблона) - имя файла, который будет добавлен в карточку как виртуальный файл. Имя файла пишется без расширения, расширение файла определяется на основе файла из шаблона файла.

  • Категория файла - категория файла, с которой будет добавлен виртуальный файл. Если не задано, то файл добавляется без категории.

  • ID виртуального файла - идентификатор виртуального файла, добавляемого в карточку. Генерируется системой.

  • ID версии виртуального файла - идентификатор текущей версии виртуального файла. Генерируется системой.

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

    • Шаблон файла - шаблон файла, на основе которого генерируется дополнительная версия виртуального файла.

    • Имя файла (пусто - определяется из шаблона) - имя дополнительной версии файла. Имя файла пишется без расширения, расширение файла определяется на основе файла из шаблона файла.

    • ID версии виртуального файла - идентификатор дополнительной версии виртуального файла. Генерируется системой.

  • Типы - список типов карточек, для которых используется данный виртуальный файл.

  • Состояния карточек - список состояний, на которых данный виртуальный файл доступен.

  • Роли - список ролей, для которых доступен данный виртуальный файл. Не поддерживает контекстные роли.

  • Список условий - таблица с условиями, которые определяют доступность к виртуальному файлу. Более подробно о таблице с условиями смотрите в разделе Заполнение таблицы с условиями.

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

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

14. Маршруты документов

14.1. Введение в маршруты

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

Основные компоненты подсистемы маршрутов

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

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

    routes2

Компоненты, настраиваемые администратором

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

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

  • Кнопка процесса - это карточка, позволяющая описывать новые кнопки (тайлы) в контекстной (левой) или глобальной (правой) панели приложения системы. С кнопкой можно связать группу шаблонов, которая должна выполниться по ее нажатию или указать дополнительные параметры управления процессом.

    routes3
  • Сценарии (скрипты) - при помощи простых скриптов можно чрезвычайно сильно расширить возможности подсистемы маршрутов. Для скриптов используется синтаксис C#, и в различных объектах системы вы с их помощью можете модифицировать маршруты и их поведение, манипулировать данными карточек, организовывать циклы и сложные связи между различными этапам, управлять условиями подставки и пропуска этапов. Далее будет приведено большое количество примеров таких условий и скриптов, вы увидите, что это несложно. Обычный администратор, владеющий базовыми навыками скриптинга, легко сможет использовать их в работе.

  • Методы расширений - это карточка, позволяющая определить библиотеку различных вспомогательных методов (скриптов), которые в дальнейшем использовать в скриптах и условиях. Методы расширений позволяют сильно упростить скрипты и не дублировать одинаковые действия.

14.1.1. Виды процессов маршрутов, расчет маршрута и его выполнение

Существуют два вида процессов маршрутов: основной процесс и второстепенный процесс.

  • Основной процесс - это главный процесс маршрута по карточке. Его вы можете видеть на вкладке Маршрут.

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

Также различают два вида процессов по синхронности этапов, входящих в маршрут.

  • Асинхронный процесс - процесс, некоторые этапы которого асинхронные, т.е. не могут выполниться сразу, а ждут чего-то от пользователя или внешней системы. Например, отправка задания - это асинхронный этап. Система отравляет задание и ждет, когда пользователь завершит его. Только тогда процесс идет дальше.

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

Расчет маршрута или его части выполняется в следующих ситуациях:

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

  • "Вход" в группу. Когда при выполнении процесса маршрут дошел до какой-то группы, то перед началом выполнения система перестраивает группу.

  • При достижении этапа "Пересчет маршрута". Если в состав какой-нибудь группы входит этап "Пересчет маршрута", то при выполнении этого этапа система полностью пересчитает состав текущей группы после этапа "Пересчет маршрута".

  • При нажатии кнопки "Пересчитать маршрут" на вкладке "Маршрут".

При расчете маршрута основного процесса при запуске система включает в маршрут:

  • Группы, которые не связаны с кнопками\тайлами И

    • которые по типу документа и роли соответствуют текущему типу документа и сотруднику - владельцу процесса, если задан, иначе инициатору процесса

  • Затем выполняются сценарии инициализации всех групп (построение маршрута)

  • Затем выполняются условия включения группы в маршрут (построение маршрута), у подтвержденных групп, которые останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.

  • Затем для каждой подтвержденной группы (условие включения в маршрут истинно) по очереди:

    • Вычисляются шаблоны этапов, которые включены в эту группу И

      • которые по типу документа и роли соответствуют текущему типу документа и сотруднику - владельцу процесса, если задан, иначе инициатору процесса

    • выполняются сценарии инициализации этих шаблонов этапов

    • выполняются условия включения в маршрут этих шаблонов этапов. У подтвержденных шаблонов, этапы которых останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.

    • строится маршрут по этой группе по подтвержденным этапам

    • выполняются сценарии постобработки для всех шаблонов, в т.ч. неподтвержденных

  • Затем для всех групп выполняются сценарии постобработки (построение маршрута), в том числе для неподтвержденных.

  • Далее система приступает к выполнению первой группы маршрута с выполнением ее пересчета. Пересчет группы выполняется по тем же правилам, что и для всего маршрута.

Например
В маршруте участвуют три группы: Группа 0 (условие ложно), Группа 1 (условие истинно), Группа 2 (условие истинно).
Терминология:
* Before - сценарий инициализации группы или шаблона этапа
* Condition - условия включения в маршрут (построение маршрута) группы или шаблона этапа
* After - сценарий постобработки группы (построение маршрута) или шаблона этапа

1. Выполняем Before для всех трех групп
2. Выполняем Condition для всех групп
2.0 Не берем шаблоны для группы 0, т.к. Condition = false
2.1 Берем шаблоны для группы 1
2.1.1 Выполняем Before для всех шаблонов группы 1
2.1.2 Выполняем Condition для всех шаблонов группы 1
2.1.3 Строим маршрут для группы 1 на основе подтвержденных в п 2.1.2
2.1.4 Выполняем After для всех шаблонов группы 1. Маршрут, построенный в 2.1.3 доступен в контексте.
2.2 Берем шаблоны для группы 2
2.2.1 Выполняем Before для всех шаблонов группы 2
2.2.2 Выполняем Condition для всех шаблонов группы 2
2.2.3 Строим маршрут для группы 2 на основе подтвержденных в п 2.2.2
2.2.4 Выполняем After для всех шаблонов группы 2. Маршрут, построенный в 2.2.3 доступен в контексте.
3. Выполняем After для всех трех групп. На этом моменте доступен полный маршрут по всем группам

При расчете маршрута вторичного процесса, связанного с кнопкой\тайлом система включает в маршрут:

  • Группы, которые непосредственно связаны с этим тайлом И

    • проверяется вхождение текущего сотрудника в роли, указанные в поле "Роли" группы

    • если тайл глобальный (правая панель), то поле "Тип документа" группы игнорируется

    • если тайл контекстный (левая панель), то в маршрут попадают только группы, у которых в поле "Тип документа" присутствует тип текущего документа.

  • Далее маршрут считается по общим правилам.

*Пересчет группы" при начале ее выполнения выполняется системой по аналогии с полным перестроением маршрута:

  • Сначала выполняется сценарий инициализации (построение маршрута) группы.

  • Затем выполняется условие включения в маршрут (построение маршрута) группы.

    • Если условие истинно, то вычисляются шаблоны этапов, которые включены в эту группу И

      • которые по типу документа и роли соответствуют текущему типу документа и сотруднику - владельцу процесса, если задан, иначе инициатору процесса

    • выполняются сценарии инициализации этих шаблонов этапов

    • выполняются условия включения в маршрут этих шаблонов этапов. У подтвержденных шаблонов, этапы которых останутся в маршруте (условие истинно), устанавливается флаг Confirmed = true в контексте.

    • строится маршрут по этой группе по подтвержденным этапам

    • выполняются сценарии постобработки для всех шаблонов, в т.ч. неподтвержденных

  • Затем для группы выполняется сценарий постобработки (построение маршрута).

  • Далее система приступает к выполнению этой группы маршрута.

Владелец процесса - это персональная роль, от имени которой выполняется пересчёт маршрута. Для её получения или задания следует использовать свойство IKrScript.ProcessOwner.

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

Пересчет части маршрута этапом "Пересчет маршрута" выполняется следующим образом:

  • Система полностью пересчитывает текущую группу, так же, как и при входе в группу.

  • Если в пересчитанной группе этапа "Пересчет маршрута" нет - выдается ошибка.

  • Если в пересчитанной группе ранее этапа "Пересчет маршрута" есть новые этапы - выдается ошибка.

  • Если всё в порядке, управление передается на следующий этап в группе.

Правила выполнения маршрута:

  • Система выполняет маршрут в глобальном порядке групп, входящих в него.

  • При "входе" в группу, т.е. перед выполнением первого этапа, входящего в эту группу, система выполняет и проверяет рантайм-условие (выполнение маршрута). Если условие ложно, система переходит к следующей группе в маршруте.

  • Если рантайм-условие истинно, то выполняется сценарий рантайм-инициализации (выполнение маршрута) группы.

  • Далее система по очереди выполняет этапы, входящие в группу, при этом для каждого этапа по очереди:

    • вычисляется условие

    • если условие истинно, то выполняется сценарий инициализации и выполняется собственно этап

    • при завершении этапа выполняется сценарий постобработки

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

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

    • Формирует список групп, подходящих по типу документа и роли сотрудника, которые по порядку (поле "Порядок") должны выполняться между текущей завершенной группой и следующей.

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

14.2. Примеры маршрутов

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

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

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

Примеры, которые мы рассмотрим:

14.2.1. Инициация нового договора (пример)

Ниже представлена общая схема процесса.

routes sample1

После инициации договор будет отправлен на согласование, если он дороже 100 000.

После успешного согласование он будет переведен в состояние "На подписании руководителем" и отправлен на подписание руководителю.

Затем договор будет переведен в состояние "На подписании контрагенту" и отправлен инициатору на организацию подписания контрагентом.

И в самом конце договор получит состояние "Подписано сторонами".

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

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

В правой панели нажмите тайл "Инициировать договор".

routes sample1 01

Создастся и откроется карточка договора. Обратите внимание, что к ней уже приложен файл условного шаблона договора.

routes sample1 02

Давайте попробуем отправить договор на согласование не внося изменений в сумму. Она меньше 100 000 и это значит, что договор должен сразу попасть на подписание.

Нажмем в левой панели кнопку "Запустить процесс". Мы запустили маршрут прохождения документа.

routes sample1 03

Запустился процесс и нам сразу же пришло задание на подписание, минуя согласование.

routes sample1 04

Обратите внимание на сформированный маршрут на вкладке "Маршрут".

routes sample1 05

Обратите внимание, что состояние карточки изменилось на "На подписании руководителем". Состояние карточки можно посмотреть и на основной вкладке карточки, и на вкладке "Маршрут".

routes sample1 06

Вернемся к процессу. В задании на подписание нажмите кнопку "В работу", чтобы взять задание в работу.

routes sample1 07

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

Нажмите кнопку "Подписать", вы увидите поле для ввода комментария. Нажмите "Подписать" еще раз для подтверждения завершения задания.

Нам сразу же приходит следующее задание. Это задание инициатору на организацию подписания контрагентом.

routes sample1 08

Обратите внимание, что состояние карточки изменилось и теперь оно "На подписании контрагентом".

Давайте откажем в подписании. Нажмите кнопку "В работу". Затем нажмите кнопку "Отказать", введите комментарий (при отказе в подписании он обязательный) и нажмите еще раз "Отказать".

routes sample1 09

И нам сразу же приходит задание редактирования/доработки. Состояние карточки изменилось на "На редактировании".

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

routes sample1 10

Давайте посмотрим на содержимое листа согласования. Лист согласования - это специальный виртуальный файл, который для вашего удобства система формирует у каждой карточки, участвующей в согласовании. В нем в удобном для просмотра, печати или, например, отправки почтой, в табличном виде представлен процесс согласования и подписания документа. Файл "Лист согласования" всегда актуальный, так как формируется системой автоматически в момент запроса содержимого и физически в карточке не хранится.

routes sample1 11

Также посмотреть текущее состояние всех документов, отправленных вами на согласование, вы можете в представлении "Мои документы" в рабочем месте "Пользователь".

routes sample1 12

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

routes sample1 13

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

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

Процесс завершится и состояние карточки изменится на "Подписано сторонами".

routes sample1 14

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

Теперь давайте инициируем договор с большей суммой. Еще раз нажмите в правой панели кнопку "Инициировать договор".

В открывшейся карточке договора введите сумму 200 000.

routes sample1 15

И опять в левой панели нажмите тайл "Запустить процесс".

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

routes sample1 16

Посмотрим на вкладку "Маршрут". Появился новый этап "Согласование внутри компании". Он состоит из последовательного согласования ролями "Руководитель инициатора" и подразделением "Финансовый департамент".

routes sample1 17

Если вы согласуете документ (возьмите в работу задание, и нажмите "Согласовать"), а затем сделаете это еще раз в следующем задании, то попадете опять на этап подписания внутри компании - сначала руководителем, а затем и контрагентом. Поэкспериментируйте с выполнением процесса. Попробуйте различные варианты.

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

14.2.2. Подготовка, согласование и исполнение служебной записки/заявки (пример)

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

Давайте посмотрим на схему процесса.

routes sample2

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

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

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

Если заявка является финансовой:

  • После отправки на согласование будет предложено предоставить финансовое обоснование или ввести комментарий.

  • Когда заявка инициирована и приложено обоснование, она отправляется на согласование. В нем участвуют роли: "Руководитель инициатора", "Финансовый департамент" и "Главный бухгалтер". Интересно, что времени на согласование система будет давать всё меньше с каждым новым циклом согласования.

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

Если инициатор не подтверждает выполнение заявки, то система вновь отправляет задание исполнителю заявки с комментарием недовольного инициатора.

Давайте создадим новую служебную записку. Нажмите тайл "Обычная СЗ" в группе тайлов "СЗ" на правой панели.

routes sample2 01

Будет открыто диалоговое окно содержащее сформированный по шаблону документ. Если вы хотите отредактировать документ, нажмите правой кнопкой на файле, выберите "Редактировать", в открывшемся приложении отредактируйте документ, сохраните и закройте приложение.

routes sample2 02

После отправки на согласование система стартует процесс и присылает задание на исполнение заявки, отправленное на роль "ДИТ". При этом карточка автоматически открывается в клиентском рабочем месте. Нам не нужно вспоминать, какая карточка отвечает за какой процесс или какой шаблон документа надо использовать.

routes sample2 03

Посмотрим, как выглядит сформированный маршрут документа на вкладке "Маршрут". В настоящий момент активен этап "Исполнение обычной СЗ".

routes sample2 07

Как видите, в задании уже написано, что нам нужно сделать.

Теперь нажмите кнопку "В работу" в задании.

Теперь вам доступны все возможности работы с этим заданием. Задание можно просто завершить. Еще вы можете отправить задание другому сотруднику или сотрудникам, вы можете создать подчиненное задание, чтобы получить какие-то дополнительные материалы и данные. Возможностей очень много и они подробно описаны в руководстве пользователя в разделе "Работа с задачами".

Давайте завершим задание, чтобы сообщить системе что заполнение заявки вами завершено и можно продолжить маршрут. Нажмите кнопку "Завершить" в задании. Далее на форме завершения задания нажмите кнопку "Завершить" еще раз для подтверждения. Комментарий можно оставить пустым.

routes sample2 08

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

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

routes sample2 05

Давайте вернемся в карточку и заполним поле "Категория документа". Выберите "Прочие СЗ" из выпадающего списка и опять отправьте на согласование.

routes sample2 06

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

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

Состояние карточки изменилось на "На исполнении". Часто со сменой состояния также настраивают изменения прав доступа на карточку, например, чтобы инициатор имел права на изменение данных и файлов карточки, только пока она в состоянии "Проект".

routes sample2 09

Давайте возьмем задание в работу. Нажмите кнопку "В работу". Опять, как и в задании на заполнение, нам становится доступно множество возможностей. На этапе исполнения они могут быть полезны. Например, исполнитель может отправить задание другому сотруднику с возвратом после завершения, чтобы проконтролировать исполнение заявки до того, как система отправит ее инициатору.

Например, так:

routes sample2 10

И назад при завершении оно придёт так:

routes sample2 11

Мы же просто завершим задачу - заявка исполнена. Нажмите кнопку "Завершить" в задании и подтвердите завершение.

И система мгновенно присылает инициатору (опять нам) задание на подтверждение выполнения заявки.

routes sample2 12

Возьмем задание в работу. Нажмите кнопку "В работу". Обратите внимание, что это другое задание. В нем нам доступны только два варианта завершения "Выполнено" и "Не принято". Эти варианты специально настроены под данный шаг маршрута.

routes sample2 13

Давайте не примем выполнение. Мы чем-то недовольны. Нажмите кнопку "Не принято", заполните комментарий и еще раз нажмите "Не принято" для подтверждения завершения.

routes sample2 14

И мы опять переходим на этап выполнения заявки. Система вновь отправила задание исполнителю с комментарием инициатора.

routes sample2 15

Давайте опять возьмём задание в работу и затем завершим его. Нажмите "В работу", затем нажмите "Завершить" и на форме завершения задания еще раз нажмите "Завершить".

Система вновь присылает нам задание на подтверждение. Возьмите его в работу, и нажмите "Выполнено".

Исполнение заявки принято, процесс завершен, карточка перешла в состояние "Исполнен".

routes sample2 16

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

А в рабочем месте "Пользователь" в представлении "Мои документы" вы всегда можете увидеть список всех инициированных вами документов и их текущее состояние.

routes sample2 17

А теперь давайте инициируем финансовую заявку, чтобы посмотреть на работу согласования. Нажмите в правой панели тайл "Финансовая СЗ".

routes sample2 18

Вновь система создала карточку заявки и открыла её в диалоговом окне. Система запустит процесс и отправит задание на роль "Инициатор".

routes sample2 20

Задание уже взято в работу. Нажав на кнопку "Приложить обоснование" откроется диалоговое окно, где можно добавить файл или указать комментрий. Нажмите на панели инструментов кнопку "Отправить" для завершения задания.

routes sample2 21

Документ отправится дальше по маршруту.

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

routes sample2 19

Согласно схеме процесса, нам, а точнее нашей роли "Руководитель инициатора", приходит задание на согласование заявки. Срок задания составляет 5 рабочих дней.

routes sample2 23

Возьмите задание в работу. Это задание этапа согласования и оно предоставляет множество возможностей. Вы можете его делегировать, можете запрашивать комментарии у различных сотрудников (например, уточнить что-то у инициатора), можете делать дочерние согласования. Это подробно описано в руководстве пользователя в разделе "Согласование документов".

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

routes sample2 24

Система немедленно отправляет задание инициатору на доработку.

routes sample2 25

Задача инициатора скорректировать заявку в связи с замечаниями. Давайте сделаем вид, что мы это сделали и начнем сразу новый цикл согласования. Нажмите "В работу" и затем "Начать новый цикл".

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

После завершения задания на предоставление обоснования система вновь отправляет задание первому из согласующих - роли "Руководитель инициатора". Обратите внимание, что срок задания уменьшился и составляет уже 4 дня! Все работает так, как мы и предполагали. Если дальше не согласовывать документ, то с каждым новым циклом срок будет уменьшаться, пока не составит 1 день.

routes sample2 26

Теперь давайте согласуем документ. Нажмите "В работу", затем "Согласовать" и еще раз "Согласовать" в форме завершения. Система сразу же отправляет следующее задание согласования на роль "Финансовый департамент" (и это опять мы - для удобства).

routes sample2 27

Если завершить и это задание, согласовав документ, мы попадем на этап согласования финансового обоснования главным бухгалтером. Укажем результат проверки и согласуем финансовое обоснование.

routes sample2 28

Мы попадаем на уже знакомый нам этап исполнения заявки, только исполнителем будет другая роль, потому что категория заявки "Финансовая СЗ".

routes sample2 29

Дальнейший процесс мы подробно проходили в первой части этого примера. Обратите внимание, сколько мелких нюансов реализовано в этом процессе и при этом он остался чрезвычайно простым в настройке. Посмотреть, как устроен маршрут, вы можете в рабочем месте "Администратор" в папке "Маршруты". Там вы найдете все объекты, связанные с маршрутом.

14.2.3. Последовательное согласование протокола по списку участников, заданных непосредственно в карточке (пример)

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

В нашем случае мы возьмем список приглашенных из карточки протокола и последовательно будем согласовывать протокол с каждым из согласующих. Согласующие будут отсортированы по алфавиту, вне зависимости от того, как они заданы в карточке. Какого-то глубокого смысла этот процесс не имеет, это просто пример, относитесь к нему соответствующе.

routes sample3 01

Давайте создадим карточку протокола. В правой панели нажмите тайл "Протокол" в группе "Создать".

routes sample3 02

Откроется новая карточка протокола. Заполните ее, указав нескольких сотрудников в поле "Участники". Создать нового сотрудника вы можете в правой панели в группе тайлов "Создать → Роли → Персональная роль (сотрудник)", если у вас есть административные права.

routes sample3 03

Теперь давайте запустим процесс. В левой панели нажмите кнопку "Запустить процесс". Кстати, тайл запуска процесса может называться как угодно для разных процессов, типов документов и даже сотрудников. Это все настройки маршрутов.

routes sample3 04

В моем случае после запуска карточка выглядит вот так.

routes sample3 05

Первое задание отправилось сотруднику "Арамазамзам Г.Р.", а не нам. Увидеть это задание мы можем, если нажмем кнопку "Показать задания автора". Обычно инициатор является автором большинства заданий процесса, хотя можно настроить и по-другому.

routes sample3 06

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

На вкладке "Администратор" в представлении "Пользователи" найдите этого сотрудника и двойным щелчком мыши откройте его карточку. Далее на вкладке "Мои замещения" под таблицей "Кто меня замещает" нажмите кнопку "Добавить" и укажите себя (текущего сотрудника) как постоянного заместителя во всех ролях и подразделениях.

routes sample3 07

Далее сохраните карточку сотрудника нажатием тайла "Сохранить" в левой панели или сочетанием [ctrl+s]. Обратите внимание, что заместитель должен появиться в поле "Сотрудники" группы "Состав роли" карточки сотрудника. Это может произойти с небольшой задержкой, т.к. за пересчет замещений отвечает служба Chronos, входящая в состав платформы, которой может быть нужно небольшое время.

routes sample3 08

Теперь вернемся к карточке протокола и в левой панели нажмем тайл "Обновить" или просто [F5]. Теперь мы можем исполнить задание. В форме задания написано, что мы его видим как заместитель исполнителя (справа от фамилии исполнителя).

routes sample3 09

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

routes sample3 10

Действительно, цикл работает. Вкладка "Маршрут" содержит всего несколько этапов, которые организуют инициализацию и выполнение цикла. Полностью посмотреть их настройки вы можете в рабочем месте "Администратор" в папке "Маршруты".

routes sample3 11

14.2.4. Создание уже зарегистрированного документа (пример)

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

В данном случае система по нажатию глобального тайла:

  • Создаст карточку входящего по шаблону.

  • Выполнит для нее регистрацию.

  • Откроет карточку в рабочем месте пользователя.

Регистрация - это стандартная возможность системы. Обычно это тайл в карточке, по нажатию на который система выделяет для карточки постоянный номер и меняет состояние карточки на "Зарегистрировано".

В подсистеме маршрутов есть этап "Регистрация", который выполняет те же действия в автоматическом режиме или отправляет задание исполнителю.

В правой панели нажмите тайл "Зарегистрировать входящий".

routes sample4 01

Откроется карточка входящего. Обратите внимание, что на вкладке "История заданий" указано, что регистрация уже выполнена.

routes sample4 02

Полностью посмотреть настройки этого маршрута вы можете в рабочем месте "Администратор" в папке "Маршруты".

14.2.5. Установка примеров

Библиотека с примерами рассчитана на установку в дефолтную конфигурацию, с которой поставляется система. Если в стандартные маршруты или конфигурацию были внесены изменения, то примеры могут работать не так, как ожидается.

Загрузите библиотеку примеров по ссылке RoutingSamples.zip.

Для ее установки нужно:

  • Установить библиотеку схемы "RoutingSamples" из папки "Scheme". Она включает в себя несколько новых состояний карточек.

  • Импортировать типы карточек из папки "Types" и представления из папки "Views".

  • Добавить в рабочее место "Пользователь" (или в любое другое) узел с представлением RsEvents.

  • Установить библиотеку карточек "RoutingSamples.cardlib" из папки "Cards". Она включает в себя все необходимые маршруты, кнопки, шаблоны и подразделения.

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

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

  • Убедитесь, что в справочнике сотрудников есть сотрудник "Admin" (с идентификатором "3db19fa0-228a-497f-873a-0250bf0a4ccb"), который автоматически создается при установке системы на новую БД. При импорте некоторых объектов, таких как шаблоны карточек - он указан как владелец шаблона.

  • Проверьте, что для типа карточки "Протокол" (правая панель → Настройки → Типовое решение) в настройках типового решения и для типа документа "Служебная записка" (рабочее место Администратор → Типовое решение → Типы докуметов → Служебная записка) установлен флажок "Использовать маршруты".

  • При импорте библиотеки карточек для примеров, у вас создадутся несколько подразделений, которые используются в настройках маршрутов. Если вы не хотите их использовать, то:

    • В карточке шаблона этапов "st: СЗ согласование" в этапе "Согласование с руководителем и фин. департаментом" укажите вместо подразделения "Финансовый департамент" (т.к. у вас не существует подразделения с таким идентификатором) - любое подразделение или роль, существующие в вашей системе.

    • В карточке шаблона этапов "st: СЗ исполнение" укажите в этапах "Исполнение финансовой СЗ" и "Исполнение обычной СЗ" любых исполнителей вместо указанных в них ролей "Департамент обеспечения" и "ДИТ" (т.к. у вас не существует подразделения с таким идентификатором).

  • Добавьте в настройки типового решения тип карточки Мероприятие:

    routes46

    В настройках типа карточки выставьте настройки, как на рисунке ниже:

    routes45

14.3. Настройка маршрутов пользователем

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

  • Добавление новых этапов в маршрут.

  • Изменение существующих этапов.

  • Изменение порядка этапов.

  • Пропуск этапов.

Изменение маршрута выполняется на вкладке "Маршрут" карточки документа. Чтобы определить, какие возможности есть у пользователя, система проверяет следующие правила:

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

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

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

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

14.3.1. Справочник настроек этапов маршрута

Этот справочник позволяет настроить - каким пользователям в какие группы этапов и что (какие этапы) можно добавлять. Например, логично разрешить в группу этапов "Согласование" добавлять только этапы согласования. Редактировать справочник может только администратор.

Справочник расположен в справочнике настроек типового решения (правая панель → Настройки → Типовое решение) на вкладке "Дополнительно".

routes43

Каждая строка в справочнике задает одно правило. В правиле можно указать:

Типы документов - для каких типов документов работает правило.

Группы этапов - в какие группы этапов будет разрешено добавлять этапы. Пользователь увидит эти группы этапов в диалоге добавления этапа.

Типы этапов - какие типы этапов разрешено добавлять в указанные выше группы. Пользователь увидит список этих типов этапов в диалоге добавления этапа.

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

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

routes44
Диалог добавления этапов использует два представления KrFilteredStageGroups, KrFilteredStageTypes для получения списка доступных пользователю групп и типов этапов. Вы можете поменять их для получения какой-то своей собственной логики выбора.

14.4. Настройка маршрутов администратором

Различные объекты подсистемы маршрутов доступны администратору системы в рабочем месте "Администратор" в папке "Маршруты".

14.4.1. Карточка "Группа этапов"

Группа этапов объединяет несколько связанных по смыслу шаблонов этапов в группу маршрута. Обычно группы представляет крупные части маршрута, например "Подготовка", "Согласование" или "Исполнение".

Создать карточку группы этапов мы можете через правую панель "Создать карточку → Маршруты → Группа этапов" или нажав на кнопку routes18 на панели пейджинга в представлении "Шаблоны этапов".

routes4

Основная информация.

  • Название - название карточки для отображения в списках.

  • Описание - подробный комментарий к группе.

  • Порядок - целое число, которое определяет положение данной группы в общем маршруте. Должно быть уникальным. Система при построении маршрута упорядочивает группы именно по этому числу.

  • Все этапы нередактируемые - если флажок установлен, то пользователь при работе с маршрутом на вкладке "Маршрут" не сможет менять этапы в этой группе.

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

Ограничения при пересчете.

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

  • Роли - группа будет подставлена в маршрут, если текущий пользователь (который нажимает тайл или запускает процесс) входит в любую из указанных ролей. Если роли не указаны, они не проверяются.

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

Построение маршрута. В данной группе находятся условия и сценарии, выполняемые в момент построения маршрута.

routes5

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

SQL условие - позволяет задать условие подстановки группы в маршрут при помощи sql. Вычисляется при построении маршрута.

Запрос должен возвращать ноль или одну строку и строго одну колонку. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL. Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

В запросе доступны следующие плейсхолдеры:

  • #user_id - идентификатор текущего пользователя

  • #user_name - имя текущего пользователя

  • #card_id - идентификатор карточки, для которой производится расчет

  • #card_type_id - идентификатор типа карточки, для которой производится расчет

  • #doc_type_id - идентификатор типа документа текущей карточки

  • #type_id - айди типа документа текущей карточки, если он не пуст, в противном случае айди типа карточки.

  • #doc_state - целое число, идентификатор состояния текущей карточки

  • #stage_group_id - идентификатор текущей группы

Условное выражение - позволят задать условие подстановки группы в маршрут по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в разделе Особенности работы сценариев и рекомендации по их использованию. Чаще всего используется объект Card, через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

Инициализация - это сценарий, выполняемый перед построением маршрута. Постобработка - это сценарий, выполняемый после того, как маршрут построен.

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

На вкладке Условие можно задать условие, которое определяет, выполнится ли эта группа, когда маршрут до нее дойдет.

  • SQL условие - условие можно задать в форме запроса SQL.

  • Условное выражение - в этом поле можно задать условие в синтаксисе C#.

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

Порядок построения маршрута и выполнения сценариев и проверки условий описан в данном разделе. Подробно про написание условий и сценариев для объектов маршрута рассказано в данном разделе.

14.4.2. Карточка "Шаблон этапов"

Новая карточка шаблона этапов создается из правого меню Создать карточку → Маршруты → Шаблон этапов. В новой вкладке будет открыта карточка:

routes6

Описание полей карточки:

Вкладка Карточка:

На данной вкладке указываются основные настройки и условия для подстановки этапов из текущего шаблона в карточку документа.

  • Название - уникальное название карточки шаблона этапов.

  • Описание - описание карточки, указывается при необходимости.

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

    • "В начале группы" - этапы этого шаблона в маршруте документа будут всегда в начале своей группы. Добавленные пользователем вручную этапы будут всегда идти после них.

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

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

Пример. Есть два шаблона, оба настроены так, что должны добавляться в карточку договора. И один этап добавил пользователь вручную.

  • Шаблон 1: положение - в конце группы, порядок = 0, можно перемещать = нет;

  • Шаблон 2: положение - в конце группы, порядок = 1, можно перемещать = нет.

Пересчитываем маршрут в карточке договора и в результирующем маршруте порядок этапов такой:

  • Этап, добавленный вручную.

  • Шаблон 1.

  • Шаблон 2.

Мы видим, что добавился сначала этап из шаблона с порядком 0, после него этап из шаблона с порядком 1. Оба они в конце маршрута относительно этапов, добавленных пользователем вручную.

Однако, если в Шаблоне 1 мы выставим флаг "Можно перемещать" и пересчитаем маршрут в карточке договора, увидим, что результирующий маршрут изменился:

  • Этап, добавленный вручную.

  • Шаблон 2.

  • Шаблон 1.

Это связано с тем, что указанный в шаблонах порядок используется системой для сортировки этапов только в случае, когда настройки в полях "Положение" и "Можно перемещать" - одинаковы. В примере выше в одном из шаблонов мы изменили настройку "Можно перемещать" и система отсортировала этапы в соответствии с заложенным алгоритмом:

  1. В начале группы и нельзя менять порядок

  2. В начале группы и можно менять порядок

  3. Этапы, добавленные пользователем вручную

  4. В конце группы и можно менять порядок

  5. В конце группы нельзя менять порядок

В пределах каждой подгруппы этапы сортируются по значению поля "Порядок".

Этапы нередактируемые - при выставленном флаге сотрудник не сможет редактировать параметры этапов, которые были добавлены в карточку документа автоматически на основании данного шаблона (даже если у сотрудника, в соответствии с настроенными правилами доступа, есть разрешение на редактирование маршрута согласования). Администратору также будет недоступно редактирование таких этапов в карточке документа.

Можно перемещать - при выставлении флага сотрудник сможет перемещать этапы, которые были добавлены в карточку документа автоматически из данного шаблона (при наличии прав доступа на редактирование маршрута).

Если этап, добавленный из шаблона доступен для редактирования/перемещения и его отредактировали/переместили, то при изменении администратором настроек или положения этого этапа в шаблоне, он не будет обновляться в карточке документа при пересчете маршрута или его части.

Группа - группа, в которую входит этап. Каждый этап должен входить в группу.

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

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

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

SQL-условие - условие, задаваемое через SQL-запрос. Вычисляется при построении маршрута.

Запрос должен возвращать ноль или одну строку и строго одну колонку. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL. Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

В запросе доступны следующие плейсхолдеры:

  • #user_id - идентификатор текущего пользователя

  • #user_name - имя текущего пользователя

  • #card_id - идентификатор карточки, для которой производится расчет

  • #card_type_id - идентификатор типа карточки, для которой производится расчет

  • #doc_type_id - идентификатор типа документа текущей карточки

  • #type_id - айди типа документа текущей карточки, если он не пуст, в противном случае айди типа карточки.

  • #doc_state - целое число, идентификатор состояния текущей карточки

  • #stage_template_id - идентификатор текущего шаблона

  • #stage_group_id - идентификатор группы, в которую включен текущий этап

  • #stage_type_id - идентификатор типа этапа

Условное выражение. Пишется по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в разделе Особенности работы сценариев и рекомендации по их использованию. Чаще всего используется объект Card, через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

  • Инициализация - при построении маршрута система сначала выполняет эти сценарии для всех подходящих по типу документа и роли шаблонов, а уже затем начинает вычислять условия для включения этапов в маршрут. На данном этапе можно выполнять сложные проверки и, при необходимости, отменить пересчет и выдать сообщение об ошибке.

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

Порядок построения маршрута и выполнения сценариев и проверки условий описан в данном разделе. Подробно про написание условий и сценариев для объектов маршрута рассказано в данном разделе.

Вкладка Маршрут:

На вкладке настраиваются этапы, которые будут подставлены в маршрут документа при выполнении всех условий данного шаблона.

routes7

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

Доступные типы этапов описаны в разделе Типы этапов.

Вкладка Результат компиляции.

На данной вкладке отображается информация (т.е. лог) по выполнению компиляции текущего шаблона и всех шаблонов и методов. Компиляцию можно выполнить, нажав на нужной вкладке кнопку "Выполнить компиляцию" или на кнопку "Проверить скрипты", расположенную в левом меню системы (по данной кнопке выполняется компиляция всех шаблонов и методов).

"Частичная" компиляция (т.е. компиляция на вкладке "Этот сценарий") используется для проверки сценариев из этого шаблона, а также из всех методов расширений. "Полная" сборка (вкладка "Все сценарии") компилирует все шаблоны и все методы.

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

При компиляции не выполняется проверка SQL запросов.

14.4.3. Карточка "Вторичный процесс"

При помощи карточки "Вторичный процесс" можно описать новый процесс, который можно запускать в карточке независимо от основного, отображенного на вкладке "Маршрут", или глобально, т.е. вне контекста карточки. Такой маршрут может выполнять любые действия - управлять основным процессом (отозвать, выполнить переход и т.п.), манипулировать данными текущей карточки, запускать новые процессы, отправлять задания и так далее.

Вторичный процесс поддерживает несколько режимов:

  • Простой процесс - процесс, который можно запускать в расширениях или скриптах.

  • Кнопка - процесс, запускаемый по плитке в левой(локальный) или в правой(глобальный) панели.

  • Действие - процесс, запускаемый по какому-либо событию

Основные настройки и выбор режима:

routes19 1

Название - название карточки, которое будет отображаться в представлении и ссылках на вторичный процесс.

Описание - подробное описание нюансов этого вторичного процесса. Полезно для комментирования.

Режим - выбор режима вторичного процесса. В зависимости от режима отображаются специфичные настройки.

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

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

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

routes19 2

Сообщение при недоступности для выполнения - сообщение, которое выводится пользователю, если проверка при запуске процесса выполнилась неуспешно. При запуске процесса проверяются различные роли (поля Роли, Контекстные роли) и сценарии из группы Дополнительные настройки выполнения (SQL условие и условное выражение C#). Например, Выполнить это действие может только инициатор процесса. Обратитесь к Васильеву В.В..

В группе Ограничения при пересчете расположены различные ограничения на запуск вторичного процесса или видимость кнопки.

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

Роли - текущий пользователь должен входить в одну из этих ролей, чтобы запустить процесс. Доступны только роли, имеющие постоянный состав: сотрудник, подразделение, группа, динамическая роль. Позволяет ограничить видимость тайла. Проверки контекстных ролей, например "Инициатор", выполняются при запуске процесса (см. поле Доступно ролям). Это сделано для того, чтобы гарантировать быстрое открытие карточки или клиента. Вычисление контекстных ролей может занимать какое-то время и замедлять открытие карточки. Выполнять их каждый раз при открытии неэффективно.

Состояния карточек - в каких состояниях карточек процесс доступен для запуска (видима кнопка). Применимо только к контекстным процессам и игнорируется для глобальных.

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

routes19 3
Режим "Простой процесс"

Разрешить запуск на клиенте - простой процесс может быть запущен в клиентском коде. Проверка ограничений будет выполнена

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

routes19 4
Режим "Кнопка"

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

routes21

Это очень удобно, если маршрут написан так, что отправляет текущему пользователю какое-то задание. Сразу после выполнения пользователь увидит, что ему пришло новое задание.

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

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

Значок - алиас иконки для этого тайла. Доступные иконки вы можете увидеть в файле Thin Icons.png в папке с документацией в архиве с релизом платформы.

Размер плитки - размер плитки.

Текст подтверждения - вопрос, который нужно задать пользователю. Подтверждение будет показано, только если установлен флажок Спрашивать подтверждение.

routes22

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

Группировать в "Действия" - тайл (вместе с группой, если она задана), будет отображаться в группе "Действия" контекстной панели. Применимо только для контекстных тайлов.

routes19 5
Режим "Действие"

Тип события - событие, по которому будет запущен маршрут. Доступны следующие события:

  • Создание карточки - запуск маршрута при создании карточки. Аналочно методу расширения CardNewExtension.AfterRequest, в контексте доступна только что созданая карточка Card.

  • Перед сохранением карточки - запуск маршрута перед сохранением карточки. Аналочно методу расширения CardStoreExtension.BeforeRequest, в контексте доступна сохраняемая карточка Card (в пакете карточки присутствуют только изменения). Данный тип события может быть полезен для проверок и дополнительной валидации данных.

  • Сохранение карточки - запуск маршрута при сохранении карточки. Аналочно методу расширения CardStoreExtension.BeforeCommitTransaction, при обращении к карточке Card полный пакет карточки будет загружен повторно. В данном событии можно запускать более сложные маршруты, в т.ч. отправляющие задания.

  • Перед завершением задания - запуск маршрута при завершении задания (выборе одного из варианта завершения, в т.ч. с выставленным флажком "Не удалять задание"). Аналогично методу расширения CardTaskStoreExtension.BeforeRequest. Задание доступно в поле CardTask.

  • Завершением задания - запуск маршрута при завершении задания (выборе одного из варианта завершения, в т.ч. с выставленным флажком "Не удалять задание"). Аналогично методу расширения CardTaskStoreExtension.BeforeCommitTransaction. Задание доступно в поле CardTask.

  • Перед созданием задания - запуск маршрута при создании задания. Аналогично методу расширения CardTaskStoreExtension.BeforeRequest. Задание доступно в поле CardTask.

  • Завершением задания - запуск маршрута при создании задания. Аналогично методу расширения CardTaskStoreExtension.BeforeCommitTransaction. Задание доступно в поле CardTask.

routes19 6

Далее следуют скрипты для определения "выполняемости" процесса, а также видимости кнопки (если вторичный процесс в режиме "Кнопка").

routes20

SQL условие - запрос, вычисляющийся при расчете видимости плитки или выполнения вторичного процесса. Запрос должен возвращать ноль или одну строку и строго один столбец. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL. Запрос, возвращающий более одной строки и более одного столбца, является некорректным.

Список доступных для всех видов процессов плейсхолдеров:

  • #user_id - идентификатор текущего пользователя

  • #user_name - имя текущего пользователя

  • #button_id - идентификатор карточки, описывающей нажатый тайл

Следующие плейсхолдеры доступны только в контекстных процессах:

  • #card_id - идентификатор карточки, для которой производится расчет

  • #card_type_id - идентификатор типа карточки, для которой производится расчет

  • #doc_type_id - идентификатор типа документа текущей карточки

  • #type_id - айди типа документа текущей карточки, если он не пуст, в противном случае айди типа карточки.

  • #doc_state - целое число, идентификатор состояния текущей карточки

Условное выражение - условное выражение в синтаксисе C#. Если истинно, то тайл будет виден или процесс запущен. Например, тайл, который виден, если сумма договор больше 100000.

(await GetCardAsync()).DocumentCommonInfo.Amount > 100000
Запрос и сценарий идимости вычисляются каждый раз, когда системе нужно проверить видимость тайла, например, при открытии карточки. Убедитесь что эти условия выполняются очень быстро и не перегружайте систему.

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

14.4.4. Карточка "Метод расширения"

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

Новая карточка метода расширения создается из правого меню Создать карточку → Маршруты → Метод расширения. В новой вкладке будет открыта карточка:

image271

Описание полей карточки:

Вкладка Карточка:

  • Название - уникальное название карточки метода расширения.

  • Описание - описание карточки, указывается при необходимости.

  • Тело метода - поле для написания кода данного метода.

Система объединяет все карточки методов расширений в один класс, методы и свойства которых затем доступны из любых сценариев подсистемы маршрутов.

Ниже пример метода расширения, который определяет константу с телом письма и вспомогательный метод отправки уведомления указанного формата.

#using System.Threading;
#using Tessa.Notices;

public const string MessageFormat = @"
<html>
<body>
  Это письмо предназначено для {0}.
</body>
</html>
";

public async Task SendNotificationExampleAsync(CancellationToken cancellationToken = default)
{
  IMailService service = this.Resolve<IMailService>(MailServiceNames.WithoutTransaction);

  var query =
    this.DbScope
      .BuilderFactory
      .SelectDistinct()
      .C("pr", "Email")
      .From("PersonalRoles", "pr").NoLock()
      .InnerJoin("RoleUsers", "ru").NoLock()
      .On().C("ru", "ID").Equals().C("pr", "ID")
      .InnerJoin("DocumentCommonInfo", "dci").NoLock()
      .On().C("dci", "AuthorID").Equals().C("ru", "ID")
      .Where()
      .C("dci", "ID").Equals().P("cardID")
      .And()
      .C("pr", "Email").IsNotNull()
      .Build();

  this.Db.SetCommand(query, Db.Parameter("cardID", CardID));
  var emails = await this.Db.ExecuteListAsync<string>(cancellationToken);
  Show(emails.Count.ToString());
  foreach (var email in emails)
  {
    await service.PostMessageAsync(email, "Важное письмо", string.Format(MessageFormat, email), this.ValidationResult, cancellationToken: cancellationToken);
  }
}

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

...
await this.SendNotificationExampleAsync(this.CancellationToken);
...

Обратите внимание, что отправлять уведомления лучше с использованием стандартного этапа "Отправка уведомления" и карточки "Уведомление" (см соответствующий раздел документации).

Вкладка Результат компиляции

На данной вкладке отображается информация (т.е. лог) по выполнению компиляции текущего метода и всех шаблонов и методов. Компиляцию можно выполнить нажав на нужной вкладке кнопку "Выполнить компиляцию" или на кнопку "Проверить скрипты", расположенную в левом меню системы (по данной кнопке выполняется компиляция всех шаблонов и методов).

После компиляции система выводит информационное сообщение аналогично, как при компиляции из карточки шаблона этапов.

Кнопки выполнения компиляции нужны только для проверки корректности написания скриптов. Подсистема маршрутов автоматически компилирует сценарии, когда это требуется.

14.4.5. Карточки маршрутов, входящие в типовую конфигурацию

В типовую конфигурацию Tessa входят следующие карточки маршрутов:

  • Вторичные процессы

    • Вернуть документ на доработку - кнопка для прерывания основного процесса и возврата в начало группы (в типовой конфигурации это формирование нового цикла согласования и отправка задания на доработку).

    • Ветка протокола - вторичный процесс, вызываемый из вторичного процесса "Разослать задачи по решениям". Отправляет задачи по таблице "Решения" карточки протокола.

    • Запустить процесс - кнопка запуска основного процесса.

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

    • Отменить процесс - кнопка для прерывания основного процесса и перехода в состояние "Отмена".

    • Отменить регистрацию - кнопка отмены регистрации.

    • Отозвать процесс - кнопка для прерывания основного процесса и перехода в состояние "Проект".

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

  • Группы этапов

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

  • Шаблоны этапов

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

    • Доработка - шаблон этапов, обычно расположен в начале группы (но после шаблона "Новая итерация согласования"), содержащий этап Доработки. Необходим для отправки задания доработки по документу в случае несогласования или неподписания документа.

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

14.4.6. Состояние процесса, состояние этапа и настройки этапа

Состояние процесса - это набор параметров, предназначенных для использования в качестве универсального хранилища любых данных, нужных при работе процесса - сценариям, этапам, группам и т.д. Технически это hash, т.е. набор элементов вида "Ключ: Значение", где значением может быть скаляр, массив или вложенный хэш, что позволяет хранить там данные любой сложности и вложенности. Обращаться к этим данным могут любые этапы и сценарии. У каждого процесса маршрута, первичного или вторичного, своё отдельное состояние. Оно создается в момент первого обращения к нему и далее системой никогда не очищается. Хранится состояние процесса в сериализованном в json виде в поле ApprovalCommonInfo.Info.

Например:

{
  "Cycle::int":3,
  "CurrentPerformer::int":1,
  "TotalPerformers::int":1
}

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

{
  // Добавим параметр "HasFinancialGroud" и установим ему значение
  ProcessInfo.HasFinancialGround = false

  // Проверка значения
  if (ProcessInfo.HasFinancialGround == false) {
    ...
  }
}

Состояние этапа - аналогично состоянию процесса, это hash, но относится он к конкретному этапу процесса. Создается он в момент добавления этапа в маршрут и далее никогда не очищается. При этом, разумеется, если этап в какой-то момент был удален из маршрута, а потом добавлен заново - у него будет новое состояние. Как и состояние процесса, состояние этапа доступно из сценариев данного этапа (а при необходимости и из любых других сценариев маршрута) и предназначено для хранения информации, специфичной для конкретного этапа и его сценариев. Также, через состояние этапа он может обмениваться полезной информацией со сценариями в этом этапе. Состояние этапа хранится в сериализованном виде в json формате в поле KrStages.Info.

Например, этап создания карточки записывает идентификатор только что созданной карточки в состояние этапа в поле с именем "cardID" и сценарий постобработки может обратиться к этой информации:

  // Выведем идентификатор созданной карточки в отладочное сообщение.
  Show((Guid)StageInfo.cardID);

Настройки этапа - это тоже hash, в котором хранятся все настройки этапа, которые доступны в пользовательском интерфейсе. Абсолютно все поля и параметры, которые там можно задать - хранятся в настройках этапа. Как и состояние, настройки этапа доступны для чтения и изменения любым сценариям. Типичное их использование - это в сценарии инициализации динамически рассчитать и задать какие-то параметры этапа, которые было невозможно сразу задать в пользовательском интерфейсе. Изменять можно абсолютно все параметры, которые вы видите в пользовательском интерфейсе этапа.

Вот пример сценария, который меняет текст задания перед его отправкой в этапе "Задача".

  Stage.Settings.KrResolutionSettingsVirtual__Comment = "Не забудьте приложить файл.";

В базе данных настройки этапа тоже хранятся в сериализованном в json виде в поле KrStages.Settings.

Чтобы узнать, как называется тот или иной параметр, поменяйте его в интерфейсе этапа, закройте форму этапа и нажмите <Ctrl+g> для просмотра структуры изменённой карточки. На изображении ниже приведен пример того, что вы увидите, если измените состояние флажка "Отдельная задача каждому исполнителю" в этапе Задача. В настройках этот флажок доступен по имени "KrResolutionSettingsVirtual__MassCreation". routes11

Обратите внимание на тот факт, что некоторые из настроек доступны не в объекте Stage.Settings, а напрямую в текущем контексте. Например, чтобы изменить срок задания, можно написать просто TimeLimit = 3;. Подробности описаны в следующем разделе.

14.4.7. Особенности работы сценариев и рекомендации по их использованию

Сценарии в системе маршрутов могут быть следующие:

  • В тайле можно задать сценарий (условие) видимости и сценарий, который выполняется при нажатии на тайл.

Сценарии, выполняемые при построении маршрута:

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

  • В шаблоне этапов можно задать условное выражение, сценарии инициализации и постобработки.

Сценарии, выполняемые при прохождении маршрута:

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

  • В каждом отдельном этапе можно задать условное выражение, сценарии инициализации и постобработки.

Все сценарии выполняются на серверной стороне.

Порядок построения маршрута и выполнения сценариев и проверки условий описан в данном разделе.

Можно выделить следующие основные рекомендации и нюансы работы сценариев.

Сценарии, выполняемые при расчете маршрута:

  • Инициализация выполняется при построении маршрута для всех шаблонов перед проверками всех условий, Постобработка - после построения всего маршрута документа.

    Инициализация может использоваться, например, чтобы запретить запуск процесса, выведя при этом сообщение об ошибке, если какое-то поле в карточке не заполнено. При этом маршрут даже не будет построен. Или чтобы что-то заполнить так, чтобы другие этапы могли использовать эту информацию.

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

  • При расчете условий сначала выполняется "Условное выражение", если оно успешно (или не задано), то после выполняется SQL-условие, и в случае, если и оно успешно (или не задано) - этапы из шаблона будут добавлены.

    Т.е. шаблон\группа "сработает" и добавит этапы в карточку документа только в случае успешного выполнения и C# условия, и SQL-условия или если данные поля (или поле) пустые.

  • Постобработка выполняется всегда, включая случаи, когда шаблон не подтвержден (т.е. если не выполнено C# или SQL условия). Это может использоваться для принятия каких то решений в зависимости от подтверждения самого шаблона: если подтвержден выполнить какое-то действие, если не подтвержден - другое.

Сценарии, выполняемые при проходе маршрута.

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

  • Сценарии постобработки в этапах удобно использовать для проверки результатов этапа. Некоторые этапы в состояние этапа записывают результаты своей работы, их можно как-то обработать. Можно проверить, что пользователь при завершении задания задал все нужные параметры в задании или карточке и выдать ошибку.

  • Порядок расчета условий тот же, что и в дизайн-тайм условиях.

Сценарии в тайлах:

  • Сценарий видимости должен работать как можно быстрее. В нем запрещено выполнять какие-либо сложные или длительные действия, т.к. это влияет на скорость и даже возможность открытия карточки.

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

В любой ситуации, если хотите отменить текущую операцию (построение маршрута, запуск процесса, завершение этапа), выполните сценарий примерно такого вида:

  AddError("Пожалуйста, заполните категорию!");
Также все приведённые ниже свойства и методы описаны в интерфейсе IKrScript в расширениях типового решения в файле Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrCompilers/UserAPI/IKrScript.cs и в документации по API: IKrScript.

Постобработка выполнения этапа выполняется как при нормальном завершении, так и при прерывании этапа. Чтобы отличать различные причины завершения этапа, можно использовать следующий код:

  if (Stage.State == KrStageState.Inactive) {
    Show("Отозвано");
  } else if (Stage.State == KrStageState.Skipped) {
    Show("Пропущено");
  } else if (Stage.State == KrStageState.Completed) {
    Show("Завершено");
  }
  • Отозвано может быть при отзыве/отмене

  • Пропущено при регистрации с активным этапом

  • Завершено при согласовании/несогласовании

14.4.8. Написание сценариев для объектов маршрута

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

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

Для проверки скриптов на ошибки необходимо нажать тайл "Проверить скрипты" в левой панели, сочетание клавиш ctrl + alt + B или нажать кнопку "Выполнить компиляцию" на вкладке "Результат компиляции"

  • В случае успешной компиляции:

    routes8
  • В случае наличия ошибок компиляции:

    routes9

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

    routes10

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

Ниже информация о свойствах контекста, которые доступны во всех скриптах:

Информация о выполняемом этапе

Информация о процессе

  • ProcessID - идентификатор процесса. Используется только для асинхронных процессов.

  • ProcessTypeName - тип процесса. Может принимать значения KrProcess и KrSecondaryProcess.

  • WorkflowProcess - объектная модель процесса. Более подробная информация об объекте процесса.

  • Stages - список этапов в процессе. Алиас для WorkflowProcess.Stages.

  • CurrentStages - подсписок этапов в маршруте. В зависимости от контекста выполнения содержит разные выборки. Данный массив является неизменяемым, однако его элементы могут быть отредактированы.

    • Скрипт этапа - массив из одного элемента (текущий этап).

    • Скрипт шаблона этапов - массив из этапов текущего шаблона.

    • Скрипт группы этапов - массив из этапов текущей группы.

  • ProcessInfo - состояние процесса. Алиас для WorkflowProcess.Info.

  • GetCycleAsync() и SetCycleAsync(int newValue) - методы позволяющие получить или задать номер текущего цикла. Представляют собой типизированный интерфейс для получения/записи значения в ProcessInfo для основного процесса или для доступа к контекстуальному сателлиту в котором хранится значение для остальных типов процессов. Важно отметить, что номер цикла хранится в состоянии основного процесса, однако доступ к номеру цикла может быть осуществлён и во вторичных процессах, что приводит к десериализация и сериализация состояния основного процесса. Поэтому обращение к номеру цикла вне основного процесса является дорогостоящей операцией и должно быть максимально сокращено.

  • Initiator - сотрудник, инициатор (автор) процесса.

  • InitiatorComment - комментарий к циклу согласования, указанный в карточке.

Информация о выполняемом шаблоне

  • TemplateID - ID карточки шаблона этапа.

  • TemplateName - название карточки шаблона этапа.

  • Order - позиция карточки шаблона этапа.

  • Position - положение относительно этапов, добавленных вручную. Может принимать значения:

    • GroupPosition.AtFirst - для шаблонов в начале маршрута,

    • GroupPosition.AtLast - для шаблонов в конце маршрута.

  • CanChangeOrder - флаг "Можно перемещать".

  • IsStagesReadonly - флаг "Этапы нередактируемые".

Информация о карточке

Карточка:

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

  • CardID (тип Guid, readonly) - идентификатор карточки.

  • CardTypeID (тип Guid, readonly) - идентификатор типа карточки.

  • CardTypeName (строковый тип string, readonly) - название типа карточки.

  • CardTypeCaption (строковый тип string, readonly) - название типа карточки (отображаемое).

  • GetVersionAsync() (числовой тип int) - асинхронно возвращает версию карточки.

Поля в карточке, файлы:

  • GetCardAsync() (dynamic entries) - асинхронно возвращает представление строковых секций карточки посредством dynamic-полей. Через данный метод удобно получать значения конкретных полей в строковых секциях карточки, например: (await GetCardAsync()).DocumentCommonInfo.Amount.

  • GetCardTablesAsync() (dynamic tables) - асинхронно возвращает представление табличных секций карточки в виде dynamic-полей. Данный метод позволяет удобно получать строки из коллекционных секций, а также значения полей в строках, например: (await GetCardTablesAsync()).Recipients[0].UserID.

  • GetFilesAsync() (ListStorage<CardFile>) - асинхронно возвращает список файлов в карточке.

Задание:

  • CardTask - текущее завершаемое задание. Доступно, только если продвижение маршрута связано с завершением задания.

Сохранение, загрузка, валидация:

  • CardContext (производные от ICardExtensionContext) - контекст сохранения или загрузки карточки, в зависимости от того, при каких условиях происходит пересчет.

  • ValidationResult (IValidationResultBuilder) - результат валидации. В него можно записывать данные, которые будут отображены пользователю после пересчета. Если указать результат валидации с уровнем Error, то пересчет будет считаться неудачным.

  • Info (словарь Dictionary<string, object>) - дополнительная структура данных, которую можно использовать для хранения полезной информации.

Зависимости

  • Session - Сессия текущего пользователя. Используйте Session.User.ID, чтобы получить идентификатор текущего пользователя.

  • Db - Объект, используемый для выполнения SQL-запросов к текущей БД.

    • По умолчанию уже открыто соединение к основной БД системы, но посредством вызова using (DbScope.CreateNew("connectionAlias")) { …​ } можно изменить базу данных, доступную по свойству Db, может быть изменена.

    • Пример выполнения запроса: int result = await Db.SetCommand("select @Result", Db.Parameter("Result", 42)).LogCommand().ExecuteAsync<int>(CancellationToken);.

    • Следует учесть, что Db.Parameter("Result", 0) ведет себя нелогично и определит параметр типа nvarchar со значением DbNull, т.к. будет использована некорректная перегрузка метода Db.Parameter(). В связи с этим добавьте преобразование типа значения к object: Db.Parameter("Result", (object)0).

  • DbScope - Объект, обеспечивающий доступ к базам данных.

    • Позволяет открывать соединение к другим БД: await using (DbScope.CreateNew("connectionAlias")) { …​ }.

    • Также определяет тип СУБД, которая используется системой: DbScope.Dbms.

    • Вместо вызова DbScope.Db для простоты рекомендуется использоваться свойство Db, описанное выше.

  • UnityContainer - IoC-контейнер для получения любых необходимых зависимостей в рамках системы. Для более удобного использования есть метод Resolve<T>() о котором написано ниже.

  • CardMetadata - Содержит метаинформацию, необходимую для использования типов карточек совместно с пакетом карточек.

  • CardCache - Потокобезопасный кэш с карточками и дополнительными настройками.

  • KrTypesCache - Кэш по типам карточек и документов, содержащих информацию по типовому решению.

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

    • Exists - признак того, что в данный момент существует KrScope.

    • CurrentLevelID - идентификатор текущего уровня вложенности.

    • GetLevels() - список идентификаторов всех уровней вложенности запроса. Размер массива равен количеству вложенных сохранений.

    • GetMainCardAsync(Guid mainCardID, IValidationResultBuilder validationResult = default, bool withoutTransaction = default, CancellationToken cancellationToken = default) - асинхронно возвращает основную карточку из Scope. Разрешено использовать только в BeforeCommitTransaction или позже. При первом обращении карточка будет загружена полностью, далее ее объект будет закэширован и после завершения обработки автоматически сохранен.

    • GetKrSatelliteAsync(Guid mainCardID, IValidationResultBuilder validationResult = default, CancellationToken cancellationToken = default) - асинхронно возвращает основной сателлит Kr процесса. Рекомендуется использовать во всех расширениях на карточки, включенные в типовое решение вместо явной загрузки через ICardRepository.

    • GetSecondaryKrSatelliteAsync(Guid processID, CancellationToken cancellationToken = default) - асинхронно возвращает сателлит вторичного процесса по идентификатору вторичного процесса.

Контроль выполнения шаблона

  • Confirmed - свойство, принимающее true, если этап был подтвержден (оба условия выполнились. Имеет смысл только в постобработке скриптов построения маршрута.

  • KrScriptType - свойство, описывающее текущее выполняемое действие. Может принимать следущие значения:

    • KrScriptType.Before

    • KrScriptType.Condition

    • KrScriptType.After

    • KrScriptType.ButtonVisibility

    • KrScriptType.ButtonExecution

Методы, доступные в контексте
  • ValueTask<ListStorage<CardRow>> CardRowsAsync(string sectionName) - асинхронно возвращает строго типизированную коллекцию строк из секции основной карточки.

Пример
  foreach(var row in await CardRowsAsync("Recipients")) {
    ...
  }
  • IsMainProcess() - получить признак того, что текущий процесс является основным KrProcess.

Пример
  if (IsMainProcess()) {
    // В основном процессе, маршрут отражен на вкладке
  } else {
    // Вторичный процесс.
  }
  • IsMainProcessStartedAsync() - асинхронно возвращает признак, показывающий, что для текущей карточки запущен основной процесс (KrProcess).

  • RunNextStageInContextAsync(Guid cardID, bool wholeCurrentGroup = false, IDictionary<string, object> processInfo = null) - асинхронно выполнить следующий этап в контексте другой карточки. Данный метод имеет смысл только при выполнении маршрута. Если метод вызвать в скрипте инициализации, тогда текущий этап будет выполнен в другом контексте, иначе, если в постобработке, то следующий этап. Для карточки с идентификатором cardID будет запущен вторичный синхронный процесс, состоящий из текущего этапа или всех оставшихся этапов до конца текущей группы (wholeCurrentGroup == true). Для создаваемого синхронного процесса можно опционально передать ProcessInfo.

  • ContextChangePending() - возвращает признак того, что была запланирована смена контекста с помощью метода RunNextStageInContextAsync.

  • DoNotChangeContext() - отмена смены контекста.

  • Resolve<T>(string name = null) - возвращает зависимость из IoC-контейнера с опциональным указанием имени (если зависимость является именованной, например, ICardRepository).

    Пример
      var cardRepository = Resolve<ICardRepository>(CardRepositoryNames.Default);
  • AddStage(string name, StageTypeDescriptor descriptor, int position) - добавляет новый этап в маршрут с именем name и положением position. По умолчанию position - в конец.

    Особенности метода:

    • Если этап не был добавлен скриптом при предыдущих пересчетах, он будет создан с новым RowID.

    • Если этап был добавлен ранее, то RowID будет перенесен, но все значения изменены на стандартные.

    • Если этап был добавлен ранее и изменен пользователем, то возвращается null.

    • Можно использовать только в скрипте построения шаблона этапов.

      Пример
        var stage = AddStage("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor, 1);
      
        if(stage != null){
          stage.Name = "Пример этапа";
        } else {
          // При этом положение измененного пользователем этапа не специфицируется.
          // Для удержания этапа на том же месте необходимо использовать GetOrAddStage
          AddWarning("Этап изменен вручную");
        }
  • GetOrAddStage(string name, StageTypeDescriptor descriptor, int position) - возвращает или добавляет этап в маршруту с указанным именем name, типом, описываемым через descriptor, и положением position. По умолчанию position - в конец.

    Особенности метода:

    • Если этап не был добавлен скриптом при предыдущих пересчетах, он будет создан с новым RowID.

    • Если этап был добавлен ранее, то RowID будет перенесен, но все значения изменены на стандартные.

    • Если этап был добавлен ранее и изменен пользователем, то возвращается этот этап.

    • Можно использовать только в скрипте построения шаблона этапов.

      Пример
        var stage = GetOrAddStage("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor, 1);
      
        // Даже если этап установлен пользователем,
        // его положение относительно других этапов из шаблона будет 1
      
        if(!stage.RowChanged){
          stage.Name = "Пример этапа";
        } else {
          AddWarning("Этап изменен вручную");
        }
  • RemoveStage(string name) - удаляет этап из маршрута, добавленный через скрипт (доступен только в скрипте построения шаблона этапов).

  • SetSinglePerformer(Guid id, string name, Stage intoStage, bool ignoreManualChanges = false) - устанавливает исполнителя в этапе. Применимо только для типов этапов с одиночными исполнителями (доступно только в скрипте постороения шаблона этапов).

  • SetSinglePerformer(string id, string name, Stage intoStage, bool ignoreManualChanges = false) - перегрузка для SetSinglePerformer(Guid, string, Stage, bool).

  • AddPerformer(Guid id, string name, Stage intoStage, int pos = int.MaxValue, bool ignoreManualChanges = false) - добавляет исполнителя в этап intoStage на место position. По умолчанию в конец. Возвращает null, если этап изменен. Применимо только для типов этапов с множественными исполнителями (доступен в скрипте выполнения этапа и построения шаблона этапов).

    Пример
      var stage = AddStage("ПримерЭтапа", StageTypeDescriptors.ApprovalDescriptor);
    
      if(stage != null) {
        var approver = AddPerformer(perfID, perfName, stage);
      }
  • AddPerformer(string id, string name, Stage intoStage, int pos = int.MaxValue, bool ignoreManualChanges = false) - перегрузка для AddPerformer(Guid, string, Stage, int, bool).

  • RemovePerformer(Guid performerID, Stage stage, bool ignoreManualChanges = false) - удаляет исполнителя по идентификатору указанной роли для этапа с режимом множественных исполнителей.

  • RemovePerformer(string performerID, Stage stage, bool ignoreManualChanges = false) - перегрузка для AddPerformer(Guid, Stage, bool).

  • RemovePerformer(int index, Stage stage, bool ignoreManualChanges = false) - удаляет исполнителя расположенному по указанному порядковому индексу для этапа с режимом множественных исполнителей.

  • void ForEachStage(Action<CardRow> rowAction) - выполняет указанное действие над строкой (из коллекционной секции KrStages) этапа текущего процесса в обход объектной модели.

    Пример
      ForEachStage(row => {
        ...
      });
  • Task ForEachStageInMainProcessAsync(Func<CardRow, Task> rowActionAsync, bool withNesteds = false) - асинхронно выполняет указанное действие над строкой (из коллекционной секции KrStages) этапа основного процесса карточки в обход объектной модели.

    Пример
      await ForEachStageInMainProcessAsync(row => {
        ...
      });
  • SetStageStateAsync(CardRow stage, KrStageState stageStates) - асинхронно изменяет состояние этапа, заданного строкой секции карточки, а не объектной моделью. Полезно, когда нужно изменить состояние этапа из другого процесса.

    Пример
      await ForEachStageInMainProcessAsync(row => SetStageStateAsync(row, KrStageState.Inactive));
  • AddTaskHistoryRecordAsync( Guid typeID, string typeName, string typeCaption, Guid optionID, string result = null, Guid? performerID = null, string performerName = null, int? cycle = null, Func<CardTaskHistoryItem, Task> modifyActionAsync = null) - асинхронно добавляет запись в текущую группу истории заданий.

  • AddTaskHistoryRecordAsync( Guid? taskHistoryGroup, Guid typeID, string typeName, string typeCaption, Guid optionID, string result = null, Guid? performerID = null, string performerName = null, int? cycle = null, int? timeZoneID = null, TimeSpan? timeZoneUTCOffset = null, Func<CardTaskHistoryItem, Task> modifyActionAsync = null) - асинхронно добавляет запись в указанную группу истории заданий.

  • Методы для вывода пользовательской информации в ValidationResult.

    • AddError(string text)

    • AddWarning(string text)

    • AddInfo(string text)

  • Методы для вывода отладочной информации в ValidationResult. При передаче одиночных объектов подробная информация выводится сразу, при передаче перечисления IEnumerable<T> подробная информация выводится в деталях ValidationResult.

    • Show(object obj)

    • Show(string message, string details)

    • Show(Stage stage)

    • Show(IEnumerable<Stage> stages)

    • Show(Performer approver)

    • Show(IEnumerable<Performer> approvers)

Подробнее об объектах для маршрута

Тип GroupPosition

Тип данных GroupPosition хранит информацию о значении поля "положение относительно этапов, добавленных вручную". В типе определено два свойства - ID и Name. Создавать новые объекты типа нельзя. Существует три предопределенных объекта:

  • Unspecified = ID = null, Name = null

  • AtFirst = ID = 0, Name = "AtFirst"

  • AtLast = ID = 1, Name = "AtLast"

Тип WorkflowProcess

Класс содержит в себе полную информацию о текущем маршруте. Определение класса и полная информация о нем содержится в файле типового решения Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrObjectModel/WorkflowProcess.cs

  • Author - инициатора процесса.

  • AuthorComment - комментарий к циклу согласования.

  • State - состояние документа. Представлено структурой Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrState, все стандартные состояния указаны в структуре статическими полями. При добавлении новых состояний в перечисление KrDocState с помощью редактора схемы для удобной работы в исходном коде с состоянием рекомендуется вынести новые состояния в отдельный статический класс в Shared-расширениях.

    Пример:
      public static class CustomDocStates
      {
        // Строка со значением ID = 1000 Name = "CustomState" добавлена в перечисление KrDocState
        // Использовать идентификаторы ниже 1000 крайне не рекомендуется во избежание конфликта с состояниями типового решения
        public static readonly KrState CustomState = new KrState(1000);
      }
    Теперь для изменения состояния карточки в скрипте достаточно:
      #using Tessa.Extensions.Shared.CustomHelpers
      WorkflowProcess.State = CustomDocStates.CustomState;
  • Stages - список этапов в маршруте. Более подробная информация об объекте этапа.

  • Info - состояние процесса. Персистентное хранилище ключ-значение, позволяющее хранить произвольные данные, полезные при выполнении процесса и любых скриптов в рамках процесса. Алиасом поля в объекте этапа является свойство ProcessInfo в контексте скрипта. .Часто состояние процесса удобно использовать как общий буфер между этапами или даже группами. В Info можно записывать результат завершения какого-либо этапа, чтобы потом использовать этот результат в условии следующей группы

    Например:
      // Постскрипт этапа
      ProcessInfo.StageResult = "Успешно";
    
      // ...
      // Условие группы
      ProcessInfo.StageResult == "Успешно" && ...

Тип Stage

Здесь перечислены основные свойства модели этапа. Определение класса и полная информация о нем содержится в файле типового решения Source/Extensions/Tessa.Extensions.Default.Server/Workflow/KrObjectModel/Stage.cs

  • ID - идентификатор этапа. Для шаблонных этапов это RowID этапа в шаблоне, а для этапов, добавленных вручную в карточке документа, это RowID строки в документе. Таким образом, при пересчетах и подстановках идентификатор строки будет сохраняться, что позволит использовать один и тот же идентификатор в скриптах.

  • StageTypeID - идентификатор типа этапа. Каждый тип этапа описывается дескриптором, все дескрипторы стандартных типов этапов располагаются в Tessa.Extensions.Default.Shared.Workflow.KrProcess.StageTypeDescriptors.

    Пример
      Stage.StageTypeID == StageTypeDescriptors.ApprovalDescriptor.ID
  • TemplateID - ID карточки шаблона этапа KrStageTemplate.

  • StageGroupID - ID карточки группы этапов KrStageGroup, к которой принадлежит текущий этап.

  • Name - название этапа.

  • TimeLimit - срок выполнения этапа, указываемый в UI. Настройка доступна только для тех типов этапов, в дескрипторе которых UseTimeLimit выставлено в true

  • Performer - одиночный исполнитель этапа. Используется для тех типов этапов, в дескрипторе которых PerformerUsageMode выставлен в PerformerUsageMode.Single. Более подробная информация об объекте исполнителя.

  • Performers - список исполнителей этапа. Используется для тех типов этапов, в дескрипторе которых PerformerUsageMode выставлен в PerformerUsageMode.Multiple. Более подробная информация об объекте исполнителя.

  • Settings - настройки этапа, задаваемые через UI настройки. Набор настроек определяется структурой секций карточки настроек, связанной с типом этапа.

    Пример работы с настройками в Settings:
      // Название строковых полей формируется по шаблону "ИмяСекции__ИмяПоля"
      var comment = Stage.KrApprovalSettingsVirtual__Comment;
      comment = comment.Replace("пожалуйста", "немедленно");
      Stage.KrApprovalSettingsVirtual__Comment = comment;
    
      // Название строковых секций образуется с использованием суффикса __Synthetic
      var firstRow = Stage.KrUniversalTaskOptionsSettingsVirtual__Synthetic[0];
  • Info - состояние этапа. Персистентное хранилище ключ-значение, позволяющее хранить произвольные данные, полезные при выполнении этапа и его скриптов. Алиасом поля в объекте этапа является свойство StageInfo в контексте скрипта.

    Для примера, будем хранить в Info количество выполнений этапа. В скрипте инициализации запишем:
      if (StageInfo.ExecutionCount == null) {
        StageInfo.ExecutionCount = 0;
      }
      StageInfo.ExecutionCount = StageInfo.ExecutionCount + 1;

    Затем, в постскрипте выведем это количество:

      if (StageInfo.ExecutionCount != null) {
        Show(StageInfo.ExecutionCount.ToString());
      }
  • OrderChanged - признак того, что порядок менялся пользователем. Не зависит от изменения порядка в коде.

  • RowChanged - признак того, что этап менялся пользователем. Не зависит от изменений в коде.

Тип Performer

  • RowID (тип Guid, readonly) - RowID согласующего в таблице согласующих KrApprovers. Если согласующий попал в маршрут из шаблона, то RowID это ID для шаблонного согласующего. Если согласующий создан вручную, то RowID - это RowID для маршрута карточки.

  • ID - ID роли согласующего.

  • Name - имя роли согласующего.

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

14.5. Типы этапов

В этом разделе описаны все доступные "из коробки" типы этапов маршрута. Так как подсистема маршрутов расширяемая, то в вашей конфигурации могут быть добавлены новые типы этапов.

14.5.1. Общие настройки этапов

У всех этапов, независимо от типа, есть некоторые общие настройки (помимо названия).

routes47

Не показывать в маршруте - признак того, что в маршруте документа этап не будет отображаться, даже если попадает в маршрут. Посмотреть скрытые этапы можно с помощью плитки Другие → Показать скрытые этапы или с помощью сочетания клавиш [Ctrl+Alt+H]. Скрытые этапы будут выделены серым цветом.

Разрешён пропуск - признак того, что Пользователь может пропускать данный этап в маршруте документа. Это делается путём нажатий кнопки "Удалить", расположенной под таблицей этапов маршрута. При этом этап становится скрытым. Пропускать можно только неактивные этапы и если это разрешено правилом доступа "Пропуск этапов".

routes47 1

Для активации пропущенного этапа необходимо в режиме отображения скрытых этапов, если пользователь является администратором или в режиме отображения пропущенных этапов (тайл Другие → Показать пропущенные этапы или с помощью сочетания клавиш [Ctrl+Alt+H]), если у пользователя обычный уровень доступа, нажать кнопку "Активировать" или выбрать одноимённый пункт контекстного меню. Активировать этап можно только, если это разрешено правилом доступа "Редактирование маршрута".

routes12

Условие - тут можно либо в виде SQL запроса, либо в виде C# выражения (как на примере) задать условие выполнения данного этапа. Если это условие не выполняется в момент, когда до этапа доходит выполнение маршрута, то этап будет пропущен.

SQL условие. Истинным значением считается запрос, возвращающий 1. Ложным значением считается запрос, вернувший 0 строк или строку со значением 0 или NULL.

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

В запросе доступны следующие плейсхолдеры:

  • #user_id - идентификатор текущего пользователя

  • #user_name - имя текущего пользователя

  • #card_id - идентификатор карточки, для которой производится расчет

  • #card_type_id - идентификатор типа карточки, для которой производится расчет

  • #doc_type_id - идентификатор типа документа текущей карточки

  • #type_id - айди типа документа текущей карточки, если он не пуст, в противном случае айди типа карточки.

  • #doc_state - целое число, идентификатор состояния текущей карточки

  • #stage_template_id - идентификатор текущего шаблона

  • #stage_rowid - идентификатор строки этапа в маршруте

  • #stage_group_id - идентификатор группы, в которую включен текущий этап

  • #stage_type_id - идентификатор типа этапа

Условное выражение. Пишется по правилам написания логических выражений языка C#. Доступные в контексте поля и объекты описаны в следующем разделе. Чаще всего используется объект Card, через который можно проверить (а в обычных сценариях и поменять) данные текущей карточки.

Пример условия, проверяющего сумму договора.

  (await GetCardAsync()).DocumentCommonInfo.Amount > 100000

Инициализация. В этом поле задается сценарий, выполняемый перед выполнением этапа.

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

Подробнее сценарии описаны в следующем разделе.

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

Для вычисления SQL исполнителей используется скрипт, указанный в шаблоне этапа на момент выполнения скрипта.

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

  • #card_id - идентификатор карточки, для которой производится расчет

  • #card_type_id - идентификатор типа карточки, для которой производится расчет

  • #user_id - идентификатор текущего пользователя

  • #user_name - имя текущего пользователя

  • #stage_template_id - идентификатор текущего шаблона

  • #stage_template_name - название текущего шаблона

  • #stage_rowid - RowID этапа в таблице шаблона этапов, для которого вычисляются роли

Например, добавим этап, в котором укажем одного согласующего, а также SQL запрос для вычисления исполнителей - запрос, вычисляющий всех пользователей и активных заместителей в подразделении "Финансовый департамент":

routes13

Вот какой результат возвращает запрос.

routes15

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

routes14

Однако, при необходимости, можно указать положение вычисляемых согласующих в этапе. Для этого в список согласующих необходимо добавить служебную роль "Вычисляемые согласующие" в список исполнителей. Нажмите ссылку "Добавить роль Вычисляемые исполнители" под списком исполнителей. В список исполнителей добавится роль "Вычисляемые исполнители". Добавьте любых других исполнителей до и\или после этой роли. Например:

routes16

На место роли "Вычисляемые согласующие" будут подставлены исполнители, вычисленные в результате выполнения SQL запроса. Исполнители подставляются в том же порядке, в котором они возвращаются запросом.

14.5.2. Согласование

Этап согласования предназначен для отправки одного или нескольких заданий согласования.

routes23

Название этапа – название текущего этапа согласования.

Срок (рабочие дни) - срок для заданий согласования в рабочих днях. Срок можно задать и дробный, например "0,5" - половина рабочего дня (4 часа).

Дата выполнения - астрономическая дата выполнения задания. Можно указать либо это поле, либо "Срок (рабочие дни)".

Согласующие – согласующие текущего этапа. Можно указать как конкретных сотрудников, так и роли.

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

routes24
  • Исполнители для выбранного согласующего - список сотрудников или ролей, кому будет отправлено задание дополнительного согласования. Данные задания отправляются одновременно с родительским заданием согласования. Решения дополнительных согласующих заносятся в историю заданий и лист согласования, однако не влияют на итоговый результат процесса согласования.

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

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

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

От имени (сотрудник или контекстная роль) - позволяет отправить задание от имени любого сотрудника. В отличие от отправки задачи по тайлу "Создать задачу", здесь можно выбрать абсолютно любого сотрудника, т.к. маршруты настраиваются администратором.

Вид - вид задания.

Комментарий - комментарий к текущему этапу согласования.

Вкладка "Основные настройки"

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

Не возвращать на доработку - данный флаг отключает возврат на начало текущей группы этапов, выполняемый этапом "Согласование". Для того, чтобы был выполнен возврат на доработку, при наличии несогласованных заданий согласования, в стандартную группу этапов "Согласование" включен шаблон этапов "Возврат на доработку". В конце данного раздела есть примеры маршрутов согласования с использованием этого флага, где объясняется как и в каких случаях ведёт себя процесс.

Данной настройкой также можно управлять на уровне маршрута, в процессе выполнения, используя значение типа Nullable<bool> доступное по ключу Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.NotReturnEdit в ProcessInfo. При расчёте итогового значения, значение из ProcessInfo объединяется по "И" со значением указанным в настройках этапа. Если значение в ProcessInfo отсутствует или имеет значение null, то оно не учитывается.

Вернуть при несогласовании – вернуть документ на доработку Инициатору при не согласовании хотя бы одним из согласующих. Флаг проверяет только результат текущего этапа.

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

Вкладка "Дополнительно"

routes25

Вернуть после согласования – вернуть договор на доработку Инициатору при согласовании всеми текущими согласующими. Флаг проверяет только результат текущего этапа.

Отключить автоматическое согласование - отключить для данного этапа автоматическое завершение задания согласования (см. Автоматическое согласование).

Следующие две настройки управляют логикой работы этапа в подсистеме маршрутов.

Изменять состояние при старте - если флажок установлен (по умолчанию), то при запуске этапа состояние карточки устанавливается в "На согласовании". Снимите флажок, если вам не нужно такое поведение.

Изменять состояние при завершении - если флажок установлен, то при успешном выходе из этапа (все согласующие согласовали) состояние карточки устанавливается в "Согласовано". При несогласовании в последовательном режиме - этап устанавливает состояние карточки "Не согласовано" сразу же а в параллельном режиме выполнение - когда все согласующие завершили свои задания. Снимите флажок, если вам не нужно такое состояние.

Настройки прав доступа для согласующих этапа

  • Редактировать карточку – дать права доступа на редактирование карточки договора согласующим этапа;

  • Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для согласующих этапа.

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе "Управление историей", кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа - группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле "Группа истории заданий". Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Как создать новую группу истории заданий описано в разделе Управление историей.

Новая итерация - если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле "Группа истории заданий".

Этап согласования в маршруте ведет себя следующим образом. Проверки выполняются при завершении задания согласования, если этап не рекомендательный:

  1. Если это последнее задание этапа И (были несогласовавшие в текущем этапе ИЛИ результат задания = "Не согласовано"), то:

    1. Если флаг "Вернуть при несогласовании" не стоит И есть еще этапы согласования после текущего в пределах группы, то завершаем этап и идем дальше по маршруту.

    2. Если флаг "Не возращать на доработку" стоит, то завершаем этап и идем дальше по маршруту.

    3. Если вышеописанные условия не выполнились, то возвращаемся в начало текущей группы.

  2. Если это не последнее задание этапа И этап последовательный И результат задания = "Не согласовано", то:

    1. Выполняются те же проверки что и в пунктах 1.a..1.c

  3. Если результат задания = "Согласовано", то:

    1. Если флаг "Не возвращать на доработку" стоит, то завершаем этап и идем дальше по маршруту.

    2. Если флаг "Не возвращать на доработку" не стоит И были несогласовавшие на этом же этапе или ранее в пределах группы И нет следующих этапов согласования в пределах группы, то возвращаемся в начало текущей группы.

    3. Если это последнее задание этапа И флаг "Возвращать при согласовании" стоит, то ищем первый этап доработки в текущей группе:

      1. Если нашли - переходим на него. После завершения задания доработки выполнение маршрута возобновляется с этапа следующего за этапом инициировавшим доработку. Номер цикла не изменяется.

      2. Если не нашли - завершаем этап и идем дальше по маршруту.

При обработке завершения задания, если результат = "Не согласовано" и этап не рекомендательный - в StageInfo пишется признак "Disapproved": true.

Проверка, были ли несогласовашие в прошедших этапах, проверяет наличие флага "Disapproved": true в текущем и предыдущих этапах.

Имя флага Disapproved содержится в константе Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.Disapproved.

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

Этап согласования завершается, когда завершится последнее задание этапа.

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

  • Примеры маршрутов в типовой группе Согласование с наличием всех типовых шаблонов этапов.

    Пример 1. Комбинация флагов "Вернуть при несогласовании" и "Вернуть после согласования"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Да

    Нет

    Нет

    Да

    2

    Волков

    Нет

    Да

    Нет

    Нет

    Нет

    Варианты прохождения маршрута:

    • Иванов - согласовал, Петров - согласовал, документ отправился на доработку, далее Волкову. Волков согласовал. Документ согласован.

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

    • Иванов - не согласовал, документ отправился на доработку с увеличением цикла.

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

    • Иванов - согласовал, Петров - согласовал, документ отправился на доработку, далее Волкову. Волков не согласовал, документ отправился на доработку с увеличением цикла.

      В данном случае был возврат в начало группы, т.к. документ не согласовали. Причем этот возврат не зависел от наличия флага "Вернуть при несогласовании" на втором этапе, т.к. внутри этапа согласования встроена проверка, срабатывающая на последнем этапе группы: если в маршруте на каком-либо этапе были отрицательные визы - вернуть маршрут в начало группы.

    Пример 2. Комбинация флагов "Вернуть при несогласовании" и "Вернуть после согласования"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Нет

    Нет

    Нет

    Нет

    2

    Волков

    Нет

    Нет

    Нет

    Нет

    Да

    Варианты прохождения маршрута:

    • Иванов - не согласовал, Петров - не согласовал, Волков - не согласовал, документ отправился на доработку с увеличением цикла.

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

    • Иванов - согласовал, Петров - согласовал, Волков - согласовал, документ отправился на доработку, далее переход в состояние "Согласован".

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

    Пример 3. Флаг "Не возвращать на доработку"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Нет

    Да

    Нет

    Нет

    2

    Волков

    Нет

    Нет

    Да

    Нет

    Нет

    Варианты прохождения маршрута:

    • Иванов - не согласовал, Петров - согласовал, Волков - не согласовал, документ отправился на доработку с увеличением цикла.

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

      В этом примере Флаг "Не возвращать на доработку" на первом этапе отключил встроенную в этап проверку, которая в случае несогласования возвращает маршрут в начало группы, а во втором этапе благодаря флагу не сработала проверка, которая в случае, если в группе ранее (на любых этапах) были отрицательные визы - вернуть маршрут в начало группы. Документ же вернулся на доработку в начало группы благодаря шаблону этапов "Возврат на доработку", входящему в типовую поставку и находящемуся в конце группы Согласование.

    В предыдущих примерах маршрутов возврат в начало группы выполнялся как раз благодаря проверке, встроенной внутри этапа Согласования. Шаблон этапов "Возврат на доработку" даже не выполнялся, он выполнится только в случае выставления флага "Не возвращать на доработку" на последнем этапе группы.

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

    По сути, флаг "Не возвращать на доработку" отрабатывает так же, как снятый флаг "Вернуть при несогласовании", небольшое отличие есть только на последнем этапе группы (при условии, что в группе есть типовой шаблон этапов "Возврат на доработку"). Возврат будет выполнен с помощью разных инструментов: с флагом "Не возвращать на доработку" - путём обозначенного шаблона этапов, без флага - путем встроенной проверки в этапе согласования. Инструменты разные, но итог один - возврат выполняется.

    Однако флаг "Не возвращать на доработку" может быть полезен и в других целях, например, если в шаблоне этапов снят флаг "Этапы нередактируемые" - тогда пользователи при редактировании этапов, где выставлен флаг "Не возвращать на доработку", не смогут управлять флагами "Вернуть при несогласовании" и "Вернуть после согласования", т.к. они будут скрыты.

    Пример 4. Флаг "Рекомендательное согласование"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Нет

    Нет

    Да

    Да

    2

    Волков

    Нет

    Нет

    Нет

    Нет

    Нет

    Варианты прохождения маршрута:

    • Иванов - согласовал, Петров - согласовал, документ отправлен на доработку, далее Волкову. Волков - согласовал. Документ согласован.

    • Иванов - не согласовал, Петров - не согласовал, документ отправлен на доработку, далее Волкову. Волков - согласовал. Документ согласован.

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

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

  • Примеры маршрутов при отсутствии в группе типового шаблона этапов "Возврат на доработку".

    Пример 5. Флаг "Вернуть при несогласовании"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Да

    Нет

    Нет

    Нет

    2

    Волков

    Нет

    Нет

    Нет

    Нет

    Нет

    Варианты прохождения маршрута:

    • Иванов - согласовал, Петров - не согласовал, документ отправлен на доработку с увеличением цикла.

    В этом примере вполне ожидаемое поведение маршрута с учетом приведенных выше примеров

    • Иванов - согласовал, Петров - согласовал, Волков - не согласовал, документ отправлен на доработку с увеличением цикла.

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

    Пример 6. Флаг "Не возвращать на доработку"

    Шаблон этапов с маршрутом:

    Исполнители

    Параллельный

    Вернуть при несогласовании

    Не возвращать на доработку

    Рекомендательное согласование

    Вернуть после согласования

    1

    Иванов, Петров

    Нет

    Нет

    Да

    Нет

    Нет

    2

    Волков

    Нет

    Нет

    Да

    Нет

    Нет

    Варианты прохождения маршрута:

    • Иванов - не согласовал, Петров - согласовал, Волков - согласовал, документ переходит в состояние "Не согласован".

    • Иванов - согласован, Петров - согласовал, Волков - не согласовал, документ переходит в состояние "Не согласован".

    Это единственный пример, где в конце выполнения группы при наличии отрицательных виз не выполнен возврат на доработку, даже при отсутствии флага "Рекомендательное согласование". Документ переходит в состояние "Не согласован" и маршрут согласования завершается. При этом наличие флага "Не возвращать на доработку" в первом этапе отрабатывает аналогично снятому флагу "Вернуть при несогласовании", этот сценарий подробно описан в примере 3.

    Комбинация условий: наличие флага "Не возвращать на доработку" на последнем этапе группы и отсутствие в группе шаблона этапов "Возврат на доработку" может быть полезна, например, при настройке сложного маршрута согласования с использованием ветвления (чтобы в случае отрицательных виз ветка могла завершиться, без доработки внутри ветки) или при обработке отрицательных виз по своей логике, отличающейся от типовой.

14.5.3. Подписание

Этап подписания полностью аналогичен согласованию, за исключением:

  • В заданиях кнопки называются "Подписать" и "Отказать" вместо "Согласовать" и "Не согласовать";

  • Состояние карточки при входе в этап устанавливается "На подписании".

14.5.4. Доработка

Этап, обеспечивающий доработку документа после несогласования. Отправляет задание на доработку указанному исполнителю. По завершению задания передает управление следующему этапу в маршруте.

routes26

Срок (рабочие дни) - срок задания в рабочих днях, допускаются дробные значения.

Дата выполнения - астрономическая дата выполнения задания. Можно указать либо это поле, либо "Срок (рабочие дни)".

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

От имени (сотрудник или контекстная роль) - позволяет отправить задание от имени любого сотрудника.

Вид - вид задания.

Комментарий - комментарий к этапу.

Изменять состояние - если флажок установлен (по умолчанию), то при входе в этап состояние карточки меняется на "На доработке". Снимите флажок, если вам не нужно такое поведение.

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

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

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

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе "Управление историей", кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа - группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле "Группа истории заданий". Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Как создать новую группу истории заданий описано в разделе Управление историей.

Новая итерация - если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле "Группа истории заданий".

14.5.5. Задача

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

Подробно возможности задач подробно описаны в соответствующем разделе руководства пользователя.
routes27

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

От имени (сотрудник или контекстная роль) - позволяет отправить задание от имени любого сотрудника. В отличие от отправки задачи по тайлу "Создать задачу", здесь можно выбрать абсолютно любого сотрудника, т.к. маршруты настраиваются администратором.

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

Первый исполнитель - ответственный - если флажок установлен, то первый исполнитель получит обычную задачу, а остальные - дочерние задачи.

Длительность (рабочие дни) - срок задания в рабочих днях. Допускаются дробные значения.

Дата выполнения - астрономическая дата выполнения задания. Можно указать либо это поле, либо "Длительность (рабочие дни)".

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

Комментарий - текст задания.

Вид - вид задания.

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе "Управление историей", кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа - группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле "Группа истории заданий". Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Как создать новую группу истории заданий описано в разделе Управление историей.

Новая итерация - если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле "Группа истории заданий".

14.5.6. Настраиваемое задание

Этап "Настраиваемое задание" позволяет отправить одному или нескольким исполнителям задание с заданными в настройках этапа вариантами завершения и обработать результат. Этап асинхронный и для завершения ждет завершения всех заданий исполнителей. После завершения задания этап завершается и передает управление далее по маршруту.

routes28

Вот так выглядит взятое в работу настраиваемое задание.

routes30

Срок (рабочие дни) - срок задания в рабочих днях. Допускаются дробные значения.

Дата выполнения - астрономическая дата выполнения задания. Можно указать либо это поле, либо "Срок (рабочие дни)".

Исполнители - исполнители задания. Можно указывать любые роли.

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

Вид - вид задания.

Текст задания - текст задания.

Варианты завершения - в этом разделе можно создать варианты завершения, которые будут доступны пользователю как кнопки завершения задания.

routes29

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

Вариант завершения - название варианта завершения (кнопки в задании). Можно использовать локализацию.

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

routes29 1

Показывать поле Комментарий - с вариантом завершения связано текстовое поле "Комментарий", которое может заполнить пользователь. Обязательность данного поля система не проверяет, ее можно гарантировать в сценарии пост-обработки.

  // если комментарий пустой, ругаемся
  if ( String.IsNullOrWhiteSpace ( (string)StageInfo.Tasks[0].Comment ) ) {
    AddError("Пожалуйста, укажите комментарий!");
  }
routes31

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

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе "Управление историей", кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа - группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле "Группа истории заданий". Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Как создать новую группу истории заданий описано в разделе Управление историей.

Новая итерация - если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле "Группа истории заданий".

При завершении задания этап записывает в состояние этапа в коллекцию Tasks набор значений, описывающих все нюансы завершения задания. Элемент коллекции - это сериализованное состояние задания хранящееся в виде словаря Dictionary<string, object>.

// Обратиться к конкретному элементу массива можно по его индексу, например
StageInfo.Tasks[i].OptionName
// Получить количество элементов можно при помощи
StageInfo.Tasks.Count()
// Если задание одно, в массиве будет всегда один элемент. К его данным можно обращаться следующим образом:
StageInfo.Tasks[0]

Вот пример набора параметров, которые записывает система.

{
  "Tasks": [
    {
      "RowID": "976f5b71-4130-46fe-8826-90513014bb24",
      "RoleID": "2778f2a8-e77b-4c15-9f23-2c56d1946099",
      "RoleName": "Инициатор согласования",
      "RoleTypeID": "b672e00c-0241-0485-9b07-4764bc96c9d3",
      "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "AuthorName": "Admin",
      "AuthorPosition": null,
      "Action": 3,
      "TypeID": "9c6d9824-41d7-41e6-99f1-e19ea9e576c5",
      "TypeName": "KrUniversalTask",
      "TypeCaption": "$CardTypes_TypesNames_KrUniversalTask",
      "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "UserName": "Admin",
      "OptionID": "bc390ea9-530b-4467-b352-e6842db2e6c5",
      "OptionName": "Выполнено",
      "Result": null,
      "Planned": "2018-07-14T11:04:47",
      "PlannedQuants": 79,
      "InProgress": "2018-07-11T11:05:40",
      "Digest": "Пожалуйста, подтвердите, что ваша СЗ исполнена.  В этом случае нажмите \"Выполнено\". Если необходимо еще что-то сделать, пожалуйста, нажмите \"Не принято\" и введите ваш комментарий.",
      "ParentRowID": null,
      "HistoryItemParentRowID": null,
      "ProcessID": null,
      "ProcessName": null,
      "ProcessKind": null,
      "Postponed": null,
      "PostponedTo": null,
      "PostponeComment": null,
      "Comment": null,
      "CompletedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "CompletedByName": "Admin",
      "Completed": "2018-07-14T11:04:47.393Z"
    },
    {
      "RowID": "1737a91c-f53f-4630-b3d7-ca8c87c461d2",
      "RoleID": "fe037e05-2c9e-4a51-8b01-15e11f1ae86a",
      "RoleName": "Департамент обеспечения",
      "RoleTypeID": "abe57cb7-e1cb-06f6-b7ca-ad1668bebd72",
      "AuthorID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "AuthorName": "Admin",
      "AuthorPosition": null,
      "Action": 3,
      "TypeID": "9c6d9824-41d7-41e6-99f1-e19ea9e576c5",
      "TypeName": "KrUniversalTask",
      "TypeCaption": "$CardTypes_TypesNames_KrUniversalTask",
      "UserID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "UserName": "Admin",
      "OptionID": "e4d4db89-4320-4fcb-aa1f-9d36e33ca614",
      "OptionName": "Не принято",
      "Result": "Пожалуйста, проверьте еще раз.",
      "Planned": "2018-07-14T11:04:47.393Z",
      "PlannedQuants::int": 79,
      "InProgress::dtm": "2018-07-11T11:07:56.963Z",
      "Digest": "Пожалуйста, подтвердите, что ваша СЗ исполнена. В этом случае нажмите \"Выполнено\". Если необходимо еще что-то сделать, пожалуйста, нажмите \"Не принято\" и введите ваш комментарий.",
      "ParentRowID": null,
      "HistoryItemParentRowID": null,
      "ProcessID": null,
      "ProcessName": null,
      "ProcessKind": null,
      "Postponed": null,
      "PostponedTo": null,
      "PostponeComment": null,
      "Comment": "Пожалуйста, проверьте еще раз.",
      "CompletedByID": "3db19fa0-228a-497f-873a-0250bf0a4ccb",
      "CompletedByName": "Admin",
      "Completed": "2018-07-14T11:04:47.393Z"
    }
  ]
}

Основные параметры:

  • Comment - комментарий при завершении;

  • OptionID - идентификатор варианта завершения, выбранного пользователем;

  • OptionName - название варианта завершения, выбранного пользователем;

  • CompletedByID - идентификатор сотрудника, завершившего задание;

  • CompletedByName - отображаемое имя сотрудника, завершившего задание;

  • RowID - идентификатор задания;

  • RoleID - идентификатор роли, на которую назначено задание;

  • RoleName - название роли, на которую назначено задание.

Как описано выше, обращаться к ним можно из сценария пост-обработки в синтаксисе StageInfo.Tasks[0].OptionName. Далее, в зависимости от выбранного пользователем варианта завершения можно записать какие-то параметры в ProcessInfo и в зависимости от них выстроить дальнейший маршрут, пропустить или повторить этапы.

14.5.7. Регистрация

Этап "Регистрация" позволяет отправить задание на регистрацию карточки. При регистрации карточке выделяется постоянный номер и изменяется состояние на "Зарегистрирована", согласно настройкам типового решения.

routes32

Регистрация выполняется после завершения задания.

Задание отправляется, только если этап регистрации используется в основном маршруте документа. При использовании во вторичном маршруте (например, выполняемом по тайлу) - этап сразу же выполняет регистрацию, не отправляя задание, и затем передает управление следующему этапу маршрута.

routes33

Срок (рабочие дни) - срок задания в рабочих днях. Можно использовать дробные значения.

Дата выполнения - астрономическая дата выполнения задания. Можно указать либо это поле, либо "Срок (рабочие дни)".

Регистратор - исполнитель задания. Любая роль в системе.

От имени (сотрудник или контекстная роль) - позволяет отправить задание от имени любого сотрудника.

Вид - вид задания.

Комментарий - комментарий к этапу.

Без отправки задания - если флажок установлен, то задание регистрации не отправляется. В данном режиме этап выполняется в синхронном режиме.

  • Редактировать карточку – дать права доступа на редактирование карточки регистраторам;

  • Редактировать любые файлы – дать права доступа на редактирование приложенных файлов для регистраторов.

14.5.8. Отмена регистрации

Этап "Отмена регистрации" выполняет отмену регистрации документа, т.е. возвращает проектный номер и состояние "Проект". Окромя названия и сценариев, настроек не имеет.

Этап синхронный, при получении управления выполняет дерегистрацию и сразу передает управление дальше.

14.5.9. Ознакомление

Этап "Ознакомление" позволяет отправить карточку на ознакомление указанным сотрудникам. Они получат почтовое уведомление и доступ на чтение карточки. Также отправленные на ознакомление документы доступны пользователю в рабочем месте "Пользователь" в представлении "Мне на ознакомление". При открытии ими карточки система зафиксирует факт ознакомления в журнале ознакомления. Функциональность ознакомления полностью аналогична ознакомлению типового решения.

routes34

Получатели - список ролей на которые будет отправлено ознакомление. Система объединит состав ролей, сформировав общий список сотрудников и затем каждому из них отравит на ознакомление документ.

Отправитель (сотрудник или контекстная роль) - сотрудник, от имени которого будет отправлено ознакомление. Можно указать сотрудника или контекстную роль. Если указана контекстная роль, система ее вычислит и возьмет первого сотрудника, входящего в эту роль.

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

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

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

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

  • {{sender}} - заменяется на имя отправителя;

  • {{comment}} - заменяется на сформированный комментарий;

  • <comment_block>…​</comment_block> - блок с комментарием. Удаляется в случае, когда {{comment}} пустой. Например, можно написать как показано в примере, и в случае пустого комментария весь текст "Инициатор отправил…​" будет удален из почтового уведомления.

    Пожалуйста, внимательно прочтите документ.
    <comment_block>Инициатор отправил следующий комментарий: {{comment}}</comment_block>

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

Этап выполняется синхронно, после запуска сразу отправляет уведомления и передает управление следующему этапу в маршруте.

14.5.10. Уведомление

Этап "Уведомление" позволяет сформировать и отправить уведомление сотрудникам по электронной почте (email). При формировании уведомления используется карточка уведомления, на которую ссылается этап. Подробнее про уведомления в разделе руководства администратора.

routes35

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

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

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

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

Этап выполняется синхронно, после запуска сразу формирует исходящие письма и передает управление следующему этапу в маршруте.

14.5.11. Создание карточки

Этап "Создание карточки" позволяет создать новую карточку из маршрута. Создать можно либо по выбранному шабону карточки, либо просто выбрав определенный тип карточки. По созданной карточке можно сразу же запустить маршрут и/или открыть ее в рабочем месте пользователя.

routes36

Тип карточки - ссылка на тип карточки, который будет использоваться для создания новой карточки. Обратите внимание, что в большинстве режимов создания (см. поле "Режим") пользователю не требуются права на создание карточек.

Шаблон - ссылка на шаблон, по которому будет создана карточка. Обратите внимание, что в большинстве режимов создания (см. поле "Режим") пользователю не требуется доступ на этот шаблон.

Режим - режим создания карточки:

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

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

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

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

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

После создания и сохранения карточки этап записывает идентификатор созданной карточки по ключу cardID (константа Tessa.Extensions.Default.Shared.Workflow.KrProcess.KrConstants.Keys.NewCardID) в состояние этапа.

{
  "cardID": "e4d4db89-4320-4fcb-aa1f-9d36e33ca614"
}

Сценарий пост-обработки может получить этот идентификатор ( (Guid)StageInfo.cardID ) и что-нибудь сделать с этим знанием, например:

  • Изменить созданную карточку, выполнив запрос к БД. К моменту выполнения сценария данные карточки уже записаны в базу данных, но транзакция еще открыта.

  • Изменить созданную карточку, выполнив следующий этап маршрута в ее контексте. Для этого нужно добавить в маршрут сразу после этапа создания карточки этап сценария. Затем в сценарии постобработки этапа создания карточки выполнить RunNextStageInContextAsync( (Guid)StageInfo.cardID ); (см. пример с созданием уже зарегистрированной карточки). Следующие этапы маршрута выполнятся в контексте вновь созданной карточки и в тексте сценария можно будет просто написать, например, (await GetCardAsync()).DocumentCommonInfo.Amount = 10 для изменения суммы договора.

Создаваемую карточку можно модифицировать в сценарии постобработки этапа, перед выполнением действия с карточкой (открытием, сохранением, запуском процесса), следующим образом:

  var card = await GetNewCardAsync();
  card.Sections["DocumentCommonInfo"].Fields["Subject"] = "Новая тема документа";
  // Или
  (await NewCardAsync()).DocumentCommonInfo.Subject = "Новая тема документа";

Обратите внимание:

  • В режиме Открыть новую карточку card содержит пустой пакет карточки, предназначенный только для записи новых значений;

  • В остальных режимах - card содержит полный пакет карточки.

14.5.12. Смена состояния

Этап "Смена состояния" позволяет изменить состояние текущей карточки. Этап синхронный и передает управление дальше сразу после изменения состояния.

routes37

Состояние - выбор из справочника состояний. Вы можете добавить свое собственное состояние в таблицу KrDocState при помощи библиотек схемы.

14.5.13. Пересчет маршрута

Этап "Пересчет маршрута" - выполняет пересчет состава текущей группы маршрута и обновляет ту его часть, которая будет выполняться после этапа "Пересчет маршрута". При этом, если были изменения состава этапов ДО того места, где находится этап "Пересчет маршрута", то система трактует это как ошибки и никаких изменений в итоговом маршруте карточки производиться не будет. Пересчет группы выполняется по обычным правилам пересчета маршрута с выполнением сценариев дизайн-тайма, за исключением того, что система пересчитывает только текущую группу.

routes38

Этап не имеет настроек.

14.5.14. Сценарий

Этап "Сценарий" позволяет выполнить какие-то действия в сценариях инициализации или постобработки и только лишь.

routes39

Этап не имеет настроек.

14.5.15. Управление процессом

Этап "Управление процессом" позволяет управлять маршрутом, выполняя различные переходы, отзыв, запуск процесса и так далее.

routes40

В поле Режим можно задать различные режимы работы этапа. Если установлен флажок Выполнять в основном процессе, то этап будет управлять основным процессом карточки, а не текущим. Этот флажок позволяет, например, по нажатию тайла, выполнить отзыв основного процесса. Маршрут, связанный с тайлом, будет вторичным отдельным маршрутом. Если флажок Выполнять в основном процессе не установлен, то этап будет пытаться управлять текущим вторичным процессом.

Режимы работы:

Отправить сигнал - это специальный режим, позволяющий отправить некоторые заранее заданные специальные команды процессу. Этот режим может использоваться только с установленным флажком "Выполнять в основном процессе". Такими командами могут быть:

  • KrStartProcessSignal - формирует маршрут и запускает процесс по документу. Если процесс уже запущен, выдает ошибку.

  • KrStartProcessUnlessStartedGlobalSignal - формирует маршрут и запускает процесс по документу. Если процесс уже запущен, просто ничего не делает.

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

Если происходит управление основным процессом из вторичного (например, мы отзываем основной процесс по нажатию тайла), в основном процессе может быть текущий активный этап, который отправил задания пользователю. В этом случае система всегда отзывает этот этап, который в свою очередь - обычно отзывает отправленные пользователям задания. Отозваны могут быть любые этапы, входящие в поставку платформы. При этом отзыв заданий выполняет собственно, сам этап, когда подсистема маршрутов запрашивает отзыв. Кастомные этапы подсистемы маршрутов могут вести себя по другому - так, как написано в соответствующем этапе.

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

Переход на этап - выполняет переход на конкретный этап маршрута.

routes41

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

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

При переходе в другую группу маршрута - выполняется пересчет этой группы по общим правилам с выполнением сценариев группы "При расчете маршрута".

Переход на группу - выполняет переход на конкретную группу маршрута. Группа должна присутствовать в рассчитанном маршруте в момент перехода.

routes42

В поле Группа этапов нужно выбрать группу, на которую выполняется переход.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы "При расчете маршрута". Далее начинается выполнение этапов этой группы.

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

Переход на следующую группу - выполняет переход на следующую группу в маршруте.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы "При расчете маршрута". Далее начинается выполнение этапов этой группы. Если группы нет (маршрут заканчивается), то завершается процесс маршрута.

Если переход выполняется вперед, то все пропущенные этапы переходят в состояние "Пропущен". Если переход выполняется назад, то все пропущенные этапы переходят в состояние "Не запущен".

Переход на предыдущую группу - выполняет переход на предыдущую группу в маршруте.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы "При расчете маршрута". Далее начинается выполнение этапов этой группы. Если предыдущей группы нет (текущая группа первая в маршруте), то этап не выполняет никаких действий.

Если переход выполняется вперед, то все пропущенные этапы переходят в состояние "Пропущен". Если переход выполняется назад, то все пропущенные этапы переходят в состояние "Не запущен".

Переход в начало текущей группы - выполняет переход на начало текущей группы.

При переходе выполняется пересчет этой группы по общим правилам с выполнением сценариев группы "При расчете маршрута". Далее начинается выполнение этапов этой группы.

14.5.16. Ветвление

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

routes48

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

routes49
Обратите внимание, что внутри этапа "Ветвление" также может запускаться вложенное "Ветвление".
routes50

В сценарии "инициализация" этапа "Ветвление" можно модифицировать "ProcessInfo" для каждого из запускаемых процессов. Это может быть полезно, например, для передачи параметров в запускаемый процесс.

Пример
    IDictionary<string, object> nestInfo = Stage.InfoStorage
        .TryGet<Dictionary<string, object>>(KrConstants.Keys.ForkNestedProcessInfo)
        .TryGet<Dictionary<string, object>>(RowID строки в коллекции вторичные процессы);

    nestInfo["key"] = "value";

    // Далее в скриптах запускаемого вложенного процесса в ProcessInfo.key будет располагаться значение "value".
Будте внимательны, "RowID строки в коллекции вторичные процессы" - это идентификатор строки в секции KrForkSecondaryProcessesSettingsVirtual_Synthetic, а не идентификатор карточки вторичного процесса.

После завершения каждой из веток вызывается сценарий "После завершения ветки". В данном сценарии можно обработать ProcessInfo завершаемого процесса, а также прервать оставшиеся ветки ветвления:

    // Завершить выполнение ветвления и перейти к следующему этапу
    NestedProcessInfo.SkipForkAndContinueRoute = true;
    // Оставить ли активными остальные этапы. Используется только с флагом выше
    NestedProcessInfo.KeepBranchesAlive = true;
    // Вывод ProcessInfo завершаемого процесса
    Show(NestedProcessInfo.ProcessInfo);
    // Вывод ProcessInfo текущего процесса.
    Show(ProcessInfoStorage);

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

В постобработке этапа можно получить информацию обо всех ветках следующим образом:

    // в nestInfo обновленные ProcessInfo после завершения процесса.
    // После выполнения постобработки коллекция будет очищена.
    IDictionary<string, object> nestInfo = Stage.InfoStorage
        .TryGet<Dictionary<string, object>>(KrConstants.Keys.ForkNestedProcessInfo)
        .TryGet<Dictionary<string, object>>(RowID строки в коллекции вторичные процессы);

    // ...

    // Техническая информация об ветках доступна в BranchInfo
    var branchInfos = new ListStorage<BranchInfo>((List<object>)context.Stage.InfoStorage[PendingProcesses], BranchInfoFactory);
    var binfo = branchInfos[0];
    // binfo.RowID - идентификатор RowID в коллекции вторичных этапов в настройках.
    // binfo.ProcessID - идентификатор вложенного процесса в рамках WorkflowAPI.
    // binfo.SecondaryProcessID - идентификатор картчоки вторичного процесса.
    // binfo.Completed - признак того, что ветка завершена
Обратите внимание, при прерывании ветки ее ProcessInfo не попадает в этап "Ветвление".

14.5.17. Управление ветвлением

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

routes51

Этап поддерживает два режима:

Добавить ветку - добавить одну или несколько веток к уже активному этапу ветвления. При необходимости, можно указать ProcessInfo также, как и в этапе "Ветвление".

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

Выполнять в основном процессе - флажок, который необходимо использовать в том случае, если целевой этап "Ветвление" находится в первичном процессе. Если флажок снят, этап влияет на родительское ветвление. Если флажок установлен, тогда этап управления процессом должен находится в вторичном процессе, который запускается вне первичного. Это может быть нажатие кнопки процесса, событие или запуск в коде расширений с помощью IKrProcessLauncher (кроме запуска из сценариев). Если же флаг не выставлен, тогда этап управления должен находится в вложенном процессе.

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

// Получение строк этапов для первичного процесса
var rows = (await GetContextualSatelliteAsync()).Sections[KrConstants.KrStages.Name].Rows;
// Нахождение строки этапа вложенного процесса
var nestedProcessRow = rows.First(
  p => p["NestedProcessID"] != null
  && (Guid)p["StageTypeID"] == StageTypeDescriptors.ApprovalDescriptor.ID);
// Идентификатор вложенного процесса
var nestedProcessID = (Guid)nestedProcessRow["NestedProcessID"];

// Настройки текущего этапа управления процессом
var section = Stage
  .SettingsStorage
  .TryGet<List<object>>(KrConstants.KrForkNestedProcessesSettingsVirtual.Synthetic);

// Дополняем настройки идентификатором вложенного процесса
// Данные настройки являются скрытыми, из интерфейса недоступны
var dict = new Dictionary<string, object>();
dict["RowID"] = Guid.NewGuid();
dict["ID"] = CardID;
dict["Order"] = 0;
dict["NestedProcessID"] = nestedProcessID;
section.Add(dict);

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

Stage.Settings.KrForkManagementSettingsVirtual__DirectionAfterInterrupt = (int)DirectionAfterInterrupt.Backward;

14.5.18. Типизированное задание

Этап типизированного задания позволяет отправлять исполнителям задание указанного в настройках этапа типа. Принципиальное отличие этапа типизированного задания от этапа настраивамого задания заключается в том, что для типизированного задания необходимо в Tessa Admin разработать тип карточки задания, который будет подключен к подсистеме маршрутов и будет использоваться в этапе типизированное задание. Данный тип этапа, как правило, используется, если по маршруту требуется отправлять задание с нестандартным видом, т.е. содержащее в себе какие-то поля для отображения/заполнения.

Для того, чтобы разработанный в Tessa Admin тип задания был доступен в подсистеме маршрутов, его необходимо добавить в карточку настроек типового решения на вкладку "Настройки этапов маршрутов".

Ниже описаны настройки этапа типизированного задания

routes52

Исполнители - любые роли в системе, можно указывать несколько. Задания рассылаются параллельно всем исполнителям.

От имени (сотрудник или контекстная роль) - позволяет отправить задание от имени любого сотрудника. В отличие от отправки задачи по тайлу "Создать задачу", здесь можно выбрать абсолютно любого сотрудника, т.к. маршруты настраиваются администратором.

Вид - вид задания.

Для обеспечения функционирования возможности задания вида задания необходимо, чтобы тип задания содержал комплексную колонку TaskCommonInfo.Kind.

Тип задания (обязательный) - определяет тип отправляемых заданий.

Дайджест - текст задания.

Группа настроек Переопределение группы истории заданий.

Позволяют указать параметры, определяющие группу в истории заданий. Функциональность аналогична, как в этапе "Управление историей", кроме того, что данные настройки не распространяются на другие этапы.

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

Родительская группа - группа истории заданий, являющейся родительской по отношению к группе, задаваемой в поле "Группа истории заданий". Если указана, то будет выбрана родительская группа заданного типа с наибольшей итерацией.

Как создать новую группу истории заданий описано в разделе Управление историей.

Новая итерация - если флаг установлен, то будет создана новая итерация для группы истории заданий, заданной в поле "Группа истории заданий".

После завершения каждого задания в этапе вызывается сценарий "После завершения задания". В нем доступен стандартный контекст сценария этапа, а также дополнительные свойства и методы:

  • TypedTaskContext.Task - пакет завершаемого задания. Вариант завершения находится в Task.OptionID;

  • TypedTaskContext.CompleteStage - флаг, используемый для указания обработчику этапа на необходимость завершения этапа. Если выставить в true, то этап будет завершен, активные задания отозваны и управление перейдет к следующему этапу;

  • TypedTaskContext.SendTaskAsync(Performer исполнитель, Guid? тип задания, DateTime? дата завершения, int? срок в рабочих днях, string дайжест задания, CancellationToken cancellationToken = default) - асинхронно отправляет задания в рамках этапа. Обязательным параметром является - "исполнитель", остальные значения берутся из настроек этапа, если не указано иное;

  • TypedTaskContext.RevokeTaskAsync(Guid taskID или IEnumerable<Guid> taskIDs, CancellationToken cancellationToken = default) - асинхронного отзывает задание в текущем процессе по указанным идентификаторам.

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