Подписи¶

Подпись — фиксация согласия пользователя с решением: утверждён документ, принята заявка и т.д. Пользователь, ставящий подпись, называется акцептантом (конкретный сотрудник или группа). Подписи запрашиваются при переходе задачи между статусами; в момент подписания система делает цифровой снимок объекта — после этого изменить подписанные данные нельзя. Виды подписей: статическая (на переходе маршрута), динамическая (ручной запрос из карточки), должностная (акцептант по должности/оргструктуре), личная (конкретный пользователь). Документ описывает настройку шаблонов подписей, типов резолюций, привязку к шагам маршрута, подключение ЭЦП (КриптоПро, PayControl, DSS, Контур.Облако) и диагностику типичных ошибок.

Где настраиваются подписи¶

Настройки подписей разнесены по нескольким местам администрирования:

Что настроить	Где
Шаблоны подписей (имя, акцептанты, срок, резолюции)	Администрирование → раздел «Подписи» (форма `signatures`)
Типы резолюций (Согласовать, Отклонить, Делегировать…)	На странице «Подписи» → кнопка «Типы резолюций»
Запрос подписи на переходе	Настройки категории → Маршрут → переход → вкладка «Подписи на переходе»
Право запрашивать и создавать динамическую подпись	Группа → вкладка «Специальные права»
Подключение ЭЦП (КриптоПро, DSS)	Администрирование → Подключения → Сервисы + форма сервиса
Выбор плагина ЭЦП	Администрирование → КриптоПро: Выбор плагина (`/spa/administration/eds-plugin-settings`)

Механизмы администрирования¶

Настройки подписей доступны через несколько механизмов: формы автоадминки, отдельную форму AdminSPA (выбор плагина ЭЦП) и Admin API.

Автоадминка (dbadmin)¶

Часть настроек задаётся через формы автоадминки по их alias:

Alias формы	Название	Таблица БД	Полей	Секций	Папка
`signatures`	Подписи	dbo.Signatures	3	1	Категории и процессы
`signature-resolution-types`	Типы резолюций	dbo.SignatureResolutionTypes	13	1	Служебное
`equal-users-for-signature`	Подписи группы	dbo.EqualUsersForSignature	6	1	Служебное
`cryptopro-verification-centers`	КриптоПро	dbo.CryptoProCertificationCenters	6	1	Подключения
`dsscryptopro-service-settings`	Сервис DSSCryptoPro	dbo.DSSCryptoProCredentials	14	1	Подключения

Отдельная форма AdminSPA и Admin API¶

Выбор плагина ЭЦП и журнал транзакций DSS вынесены в отдельные страницы AdminSPA:

Страница	Адрес	Назначение
КриптоПро: Выбор плагина	`/spa/administration/eds-plugin-settings`	Выбор плагина ЭЦП: CryptoPro / RuToken / DefineOnClient (v2.268+)
Лог транзакций DSS	`/admin/DSSTransactionLog.aspx` (устаревший интерфейс; пункт меню AdminSPA в группе «Логи и статистика»)	Журнал транзакций электронной подписи через DSS КриптоПро — диагностика проблем с ЭЦП, проверка статуса транзакции, аудит

Программно подписи настраиваются через Admin API:

Маршрут	Методы	Назначение
`/api/admin/signatures`	GET, POST, DELETE	Управление подписями, привязка резолюций
`/api/admin/subcat/step/signatures`	GET, POST, DELETE	Подписи на шагах маршрута, SQL-маршруты
`/api/admin/eds/plugin`	GET, PUT	Настройки плагина ЭЦП (глобально, по категории, по группе)

Ключевые настройки¶

Подписи (Signatures)¶

Где настраивается: Администрирование → раздел «Подписи» → карточка подписи (или Admin API /api/admin/signatures) Таблица БД: dbo.Signatures

Подпись — базовая сущность согласования. В карточке подписи настройки сгруппированы по вкладкам:

Вкладка	Что настраивается
Основное	Название, «Не запрашивать повторно», добавление акцептанта в подписчики, запрос комментария при подписании, «Можно эскалировать»
Подпись начальника	Запрос подписи руководителя акцептанта
Срок	Минимальное и стандартное время на подписание, обязательность и возможность менять срок
Динамическая подпись	Может ли подпись запрашиваться вручную, обязательность причины, поведение при отклонении
Резолюции	Какие варианты решения доступны акцептанту
Акцептанты	Кто подписывает — алгоритм определения акцептанта (см. ниже)
Используется	В каких категориях задействована подпись

Карточка настройки подписи: вкладки «Основное», «Срок», «Динамическая подпись», «Резолюции», «Акцептанты»

Единица «день» в полях срока — рабочий день (с 2.268.341). При сохранении значения в формах настройки подписи и подписи на переходе маршрута поле «дни» конвертируется в минуты по числу рабочих минут в дне из системной настройки workTimeSettings.workMinutesInDay (при стандартной конфигурации 8 рабочих часов → 480 минут). На обоих формах работает один общий хелпер signature-time.helpers.ts, поэтому единица измерения интерпретируется одинаково и при сохранении, и при загрузке существующей подписи. До 2.268.341 форма подписи на переходе сохраняла «1 день» как 1440 минут (календарные сутки), а рантайм складывал их через AddWorkingMinutesToDate (480 минут/день) — итог получался ≈3 рабочих дня вместо одного.

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

Запрос подписи в карточке задачи: вкладки «Должностные подписи» и «Личные подписи»

Маршрут	Назначение
`POST /api/admin/signatures`	Создание подписи
`GET /api/admin/signatures/{id}`	Карточка подписи
`GET /api/admin/signatures/{id}/resolutions`	Список привязанных резолюций
`POST .../resolutions/add`	Привязать резолюцию
`POST .../resolutions/remove`	Отвязать резолюцию
`GET .../subcategories`	Где используется подпись

Алгоритмы определения акцептанта¶

Кто должен подписать, задаётся в блоке «Акцептанты» настроек подписи. Акцептант может определяться разными способами:

Алгоритм	Как определяется акцептант
По группам	По группе пользователя задаётся таблица «группа → акцептант». Для личной подписи сотрудника укажите его акцептантом для системной группы Users
По параметру (ДП)	Акцептант зависит от значения ДП (таблица «значение → акцептант»). Для одного значения параметра можно назначить нескольких акцептантов — каждый из них будет отдельной строкой в таблице, которую можно добавить, изменить или удалить независимо. Можно назначить даже сотрудника без учётной записи
По руководителям	Подпись запрашивается у руководителя — непосредственного или выше по иерархии оргструктуры
По смарт-выражению	Список акцептантов возвращает смарт-выражение
По уровню / типу оргструктуры	Акцептант определяется по уровню или типу орг. единицы

Параметр «Акцептант определяется по» задаёт базового пользователя, от которого считается алгоритм: заказчик, исполнитель, ответственный исполнитель или запросивший подпись.

Типы резолюций (SignatureResolutionTypes)¶

Где настраивается: на странице «Подписи» → кнопка «Типы резолюций» (форма signature-resolution-types) Таблица БД: dbo.SignatureResolutionTypes

Тип резолюции — это вариант решения, который акцептант выбирает при обработке подписи (кнопки «Согласовать», «Отклонить», «На доработку» и т.д.). Каждый тип привязан к одному из действий над подписью.

Чтобы создать тип, на странице «Типы резолюций» нажмите «+ Создать», заполните параметры и сохраните:

Параметр	Описание
Название	Текст на кнопке резолюции (поддерживает мультиязычность)
Описание	Всплывающая подсказка при наведении на кнопку
Заголовок диалога	Заголовок окна ввода причины. Если пусто — стандартный текст «Введите причину…»
Действие	Что происходит при выборе резолюции: Подписать (задача переходит дальше по маршруту), Отклонить (остаётся в текущем статусе), Удалить (подпись удаляется, задача переходит дальше), Эскалировать (акцептантом становится руководитель), Делегировать (акцептантом становится другой пользователь), Отозвать согласование (подпись удаляется, задача остаётся)
Причина обязательна	Акцептант обязан ввести комментарий к резолюции
Необходимо подтверждение резолюции	Защита от случайного нажатия: появляется окно «Вы уверены…» (особенно актуально в мобильном приложении)
Цвет	Цвет кнопки: `red`, `yellow`, `orange`, `green`, `cyan`, `blue`, `purple`, `pink`, `brown`, `grey` или в формате HEX (`#42AAFF`)
По умолчанию	Резолюция автоматически добавляется к новым подписям
Название по смарт-выражению	Текст кнопки рассчитывается смарт-выражением

Окно создания типа резолюции: название, действие, причина, цвет, подтверждение

Подписи на шагах маршрута (StepSignatures)¶

Где настраивается: Admin API Маршрут: /api/admin/subcat/step/signatures

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

Маршрут	Назначение
`GET .../step/{stepId}/id/{stepSignatureId}`	Детальная настройка подписи на переходе
`POST /api/admin/subcat/step/signatures`	Добавление подписи на переход
`GET .../route-from-sql`	SQL-маршрут (динамическое определение акцептантов)
`POST .../route-from-sql`	Обновление SQL-маршрута
`POST .../step/{stepId}/add-owner-signature`	Быстрое добавление подписи заказчика

Связь с категориями: привязка подписей к маршрутам — часть настройки категории, но управляется через отдельный раздел Admin API.

Справочник форматов запросов¶

Создание шаблона подписи (POST /api/admin/signatures):

Тело запроса — 2 поля:

{ "name": "TM_Signature", "canBeDynamic": true }

Ответ: { "data": 2460 } — ID созданной подписи.

Обновление шаблона (POST /api/admin/signatures/{id}):

Тело запроса (как в ответе GET). Ключевые поля:

{
  "id": 2460,
  "description": "TM_Signature",
  "canBeDynamic": true,
  "acceptorsEvalutionBaseUser": "Owner",
  "acceptorsEvalutionMethod": "ByGroup",
  "actionIfNotSigned": 0,
  "signatureAcceptorsByGroups": [
    { "groupId": 2085, "aceptorUsers": [], "aceptorGroups": [] }
  ]
}

Ответ: 204 No Content.

Привязка подписи к шагу маршрута (POST /api/admin/subcat/step/signatures):

Тело запроса — 30+ полей. Минимальный рабочий пример:

{
  "StepId": 216570,
  "SignatureId": 2460,
  "IsNecessary": true,
  "SignatureOrder": 1,
  "Enabled": true,
  "AcceptorsEvalutionBaseUser": 0,
  "Description": "",
  "IsSignRestriction": false,
  "IsSignInfo": false,
  "IsOwnerSignature": false,
  "IsEds": false,
  "StepsIfNotSigned": [],
  "StepSignExtParamsIdForRestriction": [],
  "StepSignExtParamsIdForInfo": [],
  "StepSignatureConditions": [],
  "EdsSignSettings": []
}

Ответ: 200 OK с полной настройкой подписи (поле id — это stepSignatureId).

Важные нюансы:

StepId — это PK из таблицы StatesRoutesInSubcat (не StateID!). Поиск: SELECT StepID, StateID, StateNextID, StepDescr FROM StatesRoutesInSubcat WHERE SubcatID = X
AcceptorsEvalutionBaseUser — число (0=Owner, 1=Performer, 2=ResponsiblePerformer, 3=Requester, 4=SmartExpression), не строка
SignatureOrder — этап согласования (нумерация с 1). Несколько подписей на одном шаге с разными order = последовательное согласование
IsNecessary: true — подпись обязательна (блокирует переход до получения)
Массивы StepsIfNotSigned, StepSignExtParamsIdForRestriction и т.д. можно передавать пустыми []
С 2.267: вместо плоского массива StepSignExtParamsIdForRestriction используется stepExtParamRestrictions: [{ extParamId, isRequiredForSign, isReadOnlyOnSign }]. Два независимых флага:
IsRequiredForSign (по умолчанию = 1) — ДП обязателен к заполнению перед акцептом подписи (старое поведение, сохранено для всех существующих записей).
IsReadOnlyOnSign (по умолчанию = 0) — ДП блокируется (становится только для чтения) на время, пока на шаге активна подпись.
Флаги независимы: один ДП может быть одновременно обязательным к заполнению и блокируемым при подписи (сценарий «заполнить → отправить на подпись → заморозить»). Хранение: колонки IsRequiredForSign и IsReadOnlyOnSign в таблице dbo.StepSignExtParamRestrictions.
Идемпотентность: API не проверяет дубли — при повторном POST создаст дублирующую привязку. Проверяйте через GET ?stepId=X

Параллельные подписи (флаг IsWaitingSign, v2.268.104)¶

Флаг IsWaitingSign на задаче определяет, ожидает ли задача подписи. Логика сброса при выполнении шага:

До 2.268.104: IsWaitingSign = false при завершении любого шага подписи — даже если на других шагах оставались активные подписи. Это приводило к некорректному состоянию задачи.
С 2.268.104: IsWaitingSign сбрасывается только если нет активных подписей на других шагах.

Сценарий: задача на маршруте с параллельными подписями (несколько StepSignature с разными SignatureOrder или на разных шагах). При завершении одной подписи остальные продолжают удерживать задачу в состоянии «ожидание подписи».

Подписи группы и КриптоПро-сервисы¶

Подписи группы (EqualUsersForSignature):

Где настраивается: автоадминка → форма equal-users-for-signature. Таблица БД: dbo.EqualUsersForSignature.

Определяет, какие пользователи из группы могут подписывать за друг друга (взаимозаменяемость подписантов). 6 полей: SignatureId, GroupId, UserId, настройки доступа.

КриптоПро (CryptoProCertificationCenters):

Где настраивается: автоадминка → форма cryptopro-verification-centers. Таблица БД: dbo.CryptoProCertificationCenters.

Подключение к удостоверяющим центрам КриптоПро для электронной подписи. 6 полей: URL, сертификат, настройки подключения.

DSS КриптоПро (DSSCryptoProCredentials):

Недоступно в Certificate Edition (ФСТЭК-сборка UniForm.Barebone, с 2.268.353): модуль UniForm.Module.Eds исключён из сборки, формы и журнал транзакций DSS не публикуются. См. backend.md §9. То же — для Контур.Cloud.

Где настраивается: автоадминка → форма dsscryptopro-service-settings Таблица БД: dbo.DSSCryptoProCredentials

Подключение к сервису облачной ЭЦП КриптоПро DSS. 14 полей:

Параметр	Описание
Сервис	Предварительно созданный сервис с типом DSSCryptoPro (страница Сервисы)
SignServer	Сервер подписания
StsAppName	Сервер регистрации
Host	Стенд
Auth with password	Тип аутентификации: One-factor authentication with password (логин + пароль) или Two-factor authentication with MyDSS (логин + код на привязанный телефон). При 2FA при смене устройства требуется перевыпуск.
ClientId	ID клиента
ClientSecret	Секретный код клиента
Waiting sign time	Максимальное время ожидания подтверждения подписи с телефона при двухфакторной аутентификации, секунды. При превышении транзакция прерывается.

Форма «Сервис DSSCryptoPro»: сервер подписания, метод аутентификации, время ожидания подписи

Порядок подключения (4 шага): установить и настроить DSSCryptoPro по документации производителя → создать сервис в 1Форме → заполнить параметры подключения → указать сервис в настройках подписи на переходе.

PayControl¶

Подключение и параметры сервиса (system_id, Server Signer API, ДП пользователя) описаны в integrations/admin.md.

Здесь — только то, что не покрыто интеграциями: перерегистрация при утере телефона. Перевыпуск сертификата по истечении срока, утеря смартфона или переустановка приложения 1F Mobile — через API PayControl (обновление ключа server_signer: true на сервере PayControl вручную).

Подробнее — раздел PayControl в integrations/admin.md.

PayControl, Контур.Облако и настройка рабочего места для ЭЦП¶

Подключение и параметры сервиса PayControl (system_id, Server Signer API, ДП пользователя) описаны в integrations/admin.md.

Здесь — только то, что не покрыто интеграциями: перерегистрация при утере телефона. Перевыпуск сертификата по истечении срока, утеря смартфона или переустановка приложения 1F Mobile — через API PayControl (обновление ключа server_signer: true на сервере PayControl вручную).

Подробнее — раздел PayControl в integrations/admin.md.

Контур.Облако (УКЭП без локального токена):

Подключение и параметры описаны в integrations/admin.md.

Позволяет подписывать документы УКЭП или НЭП без локального носителя; подтверждение — SMS-кодом.

Подробнее — раздел Контур.Облако в integrations/admin.md.

Настройка рабочего места пользователя для ЭЦП:

КриптоПро (токен КриптоПро):

Плагин КриптоПро — установить и включить в браузере
КриптоПро CSP — криптопровайдер
Корневой сертификат УЦ, выдавшего ЭП — установить в доверенные корневые центры сертификации

РуТокен:

Плагин РуТокен — установить и включить в браузере
Корневой сертификат УЦ, выдавшего ЭП

Выбор на клиенте: если выбран плагин «Определять на клиенте» — в момент подписания у пользователя запрашивается, какой плагин использовать. Требуется установка обоих плагинов.

JS API КриптоПро и смарт-автоматизация для сертификатов¶

УЦ КриптоПро управляет сертификатами (выдача, проверка, отзыв, приостановка, возобновление). Серверные действия автоматизируются смарт-действиями, клиентские (считывание токена) — JS API.

Смарт-действия (CryptoPro CA)¶

Серверные действия с сертификатами автоматизируются смарт-действиями:

Смарт-действие	Назначение	Ключевые параметры
Issue certificate	Выпуск сертификата	ID CA, ID ДП с GUID пользователя в УЦ, ID ДП со строкой запроса, ID ДП с Request ID, ID ДП для записи сертификата
New or update user	Привязка сертификата к пользователю 1Формы	ID CA, ID ДП с XML данными пользователя, Task number
Pause certificate	Приостановка сертификата	ID CA, ID ДП с сертификатом (base64), дата начала/конца, причина
Resume certificate	Возобновление сертификата	ID CA, ID ДП с сертификатом
Revoke certificate	Отзыв сертификата	ID CA, ID ДП с сертификатом, дата отзыва, причина
Get Thumbprint	Получение отпечатка подписи	ID ДП с сертификатом, ID ДП для записи отпечатка

JS API (выполняется на клиенте)¶

Клиентские методы для работы с токеном:

Метод	Что делает	Параметры
`tcCryptoLogic.newRequest(taskId, RequestString_EP_ID, Request_EP_ID, {extParamsId:{ContainerName: 'Container_EP_ID'}})`	Создать запрос на сертификат	ID ДП со строкой запроса, ID ДП для записи Request, ID ДП с названием носителя
`tcCryptoLogic.installCertificate(taskId, Certificate_EP_ID)`	Записать сертификат на носитель	ID ДП с сертификатом
`tcCryptoLogic.changePin(thumbprint_EP_ID)`	Сменить PIN-код (CryptoPro)	ID ДП с отпечатком. Для RuToken — без параметров

Формат XML данных о пользователе (для Issue certificate / New or update user):

<ProfileAttributesChange>
  <From>
    <Attribute Oid="2.5.4.3" Value="Иванов Иван Иванович"/>
    <Attribute Oid="2.5.4.4" Value="Иванов"/>
    <Attribute Oid="2.5.4.42" Value="Иван Иванович"/>
    <Attribute Oid="1.2.840.113549.1.9.2" Value="29U6MCO"/>
    <Attribute Oid="2.5.4.10" Value="ООО Ромашка"/>
    <Attribute Oid="2.5.4.12" Value="Заместитель директора"/>
  </From>
  <To>
    <!-- аналогично для целевых значений -->
  </To>
</ProfileAttributesChange>

Формат атрибутов сертификата:

[
  {"rdn": "commonName", "cpn": "CN", "value": "ИвановИИ"},
  {"rdn": "surname", "cpn": "SN", "value": "Иванов"},
  {"rdn": "givenName", "cpn": "G", "value": "Иван Иванович"},
  {"rdn": "organizationName", "cpn": "O", "value": "ООО Ромашка"},
  {"rdn": "title", "cpn": "T", "value": "Директор"},
  {"rdn": "emailAddress", "cpn": "E", "value": "ivanov@romashka.ru"}
]

Выбор плагина ЭЦП¶

Где настраивается: AdminSPA → /spa/administration/eds-plugin-settings (v2.268+)

Три уровня настройки:

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

Варианты плагинов: CryptoPro, RuToken, DefineOnClient (определить на клиенте).

Страница «КриптоПро: Выбор плагина»: плагин по умолчанию, переопределение по категориям и группам

Удаление записей (категории или группы из списка) выполняется мгновенно, отдельным запросом — без нажатия «Сохранить».

Admin API:

Маршрут	Назначение
`GET /api/admin/eds/plugin`	Получить текущие настройки плагина: плагин по умолчанию, настройки для категорий и групп
`PUT /api/admin/eds/plugin`	Полностью заменить настройки категорий и групп (полная замена)

До v2.268 настройка выполнялась через EntityEditor (/spa/administration/entity/cryptoProPlugin); этот механизм упразднён.

SignaturesGridSettings — настройка колонок списка подписей¶

Версии: v2.256 Феникс — v2.265 Цефей. С v2.266 — нативная настройка колонок. Где настраивается: пользовательский ключ SignaturesGridSettings (SettingsCustom)

Формат ключа:

{"columns":[{"key": "...", "type": "...", "isHidden": true/false}]}

Флаг isHidden управляет видимостью колонки: false — отображается, true — скрыта даже из меню «доступных колонок».

Для вывода значений ДП в список подписей: в качестве type указать "extparam", в key — ID нужного ДП. Работает для обычных ДП; информационные ДП (отображаются серыми блоками под строкой) этим не управляются.

Системные колонки¶

Доступные системные колонки списка подписей:

key	Колонка	type
`taskText`	Текст задачи	`general`
`signatureReason`	Причина запроса подписи	`general`
`signatureOrderedTime`	Срок	`general`
`description`	Описание	`general`
`signatureAndText`	Подпись и текст задачи	`general`
`signatureAcceptants`	Согласующие	`general`
`signatureInitializeDate`	Дата запроса	`general`
`subcatName`	Категория	`general`
`ownerName`	Заказчик	`general`
`responsiblePerformer`	Исполнитель	`general`
`requestorName`	Запросивший подпись	`general`
`timeToSign`	Время на подпись	`general`
`actions`	Действия	`general`
`commentsFromMeCount`	Вопросы от меня	`general`
`commentsToMeCount`	Вопросы мне	`general`
`isAnyUnAnswered`	Мои вопросы	`general`
`taskId`	Номер задачи	`general`
`taskState`	Статус	`general`
`activeSubtasks`	Активных подзадач	`general`
`totalSubtasks`	Всего подзадач	`general`
`subtasksRes`	Подзадачи	`general`
`taskPriority`	Приоритет	`general`
`{ExtParamId}`	Любой ДП (ID задаётся в key)	`extparam`

Совмещение статической и динамической подписи¶

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

При отклонении динамической подписи параметр «Прерывать согласование на переходе, если подпись отклонена» (блок «Динамическая подпись» в настройках подписи) определяет поведение:

Прервать — всё согласование на переходе останавливается
Продолжить — остальные подписи на переходе продолжают выполняться

Оба типа маршрутов (статический и динамический) детально описаны в бизнес-логике подписей, секции «Статическая подпись» и «Динамическая подпись».

Сводная матрица настроек подписей — акцептанты, срок, резолюции¶

Таблица группирует все параметры подписей по функциональным задачам, а не по форме настройки. Колонки: Где настраивается, Область действия (подпись/переход/группа/категория), Смарт-события и смарт-действия.

Тема	Где настраивается	Область	Смарт-события / смарт-действия
Акцептанты	Подпись → блок «Акцептанты»	Подпись	—
Акцептанты на переходе	Настройки подписи на переходе, колонка «Акцептанты»	Переход	—
Акцептанты динамической подписи	Подпись → блок «Динамическая подпись», параметр «Акцептант определяется по»	Подпись	—
Акцептанты от имени группы	Группа → вкладка «Подписи»	Подпись\Группа	—
Изменение списка акцептантов	Группа → вкладка «Права на категорию» / Категория → вкладка «Доступ»	Категория\Группа	—
Предупреждение при пустом акцептанте	Подпись → параметр «Не слать ошибку, если акцептант не указан»	Подпись	—
Добавление в подписчики	Подпись → параметр «Добавлять в подписчики акцептанта»	Подпись	Смарт-действие: «Добавить акцептанта динамической подписи»
Срок подписи	Подпись → блок «Срок», параметры «Минимальное время» и «Время по умолчанию»	Подпись	—
Срок на конкретном переходе	Настройки подписи на переходе, колонка «На подписание»	Переход	—
Обязательность срока	Подпись → блок «Срок», параметр «Срок обязателен»	Подпись	—
Изменение срока	Подпись → блок «Срок», параметр «Срок можно менять»	Подпись	Смарт-событие: «После истечения срока подписи»
Доступные резолюции	Подпись → блок «Резолюции»	Подпись	—
Запрос подписи на переходе	Настройки маршрута категории, колонка «Подписи»	Категория	Смарт-событие: «Перед запросом подписи на переходе»
Обязательность подписи на переходе	Настройки подписи на переходе, колонка «Обязательна»	Переход	—

Сводная матрица настроек подписей — причина, комментарий, резолюции¶

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

Тема	Где настраивается	Область	Смарт-события / смарт-действия
Причина запроса подписи	Настройки подписи на переходе, колонка «Причина»	Переход	—
Причина для динамической подписи	Подпись → блок «Динамическая подпись», параметр «Причина запроса для динамической подписи обязательна»	Подпись	—
Изменение причины	Настройки подписи на переходе, колонка «Причину запроса подписи можно менять»	Переход	Смарт-действие: «Изменить причину динамической подписи»
Комментарий при акцепте	Подпись → параметр «Запрашивать комментарий при подписании»	Подпись	—
Комментарий на переходе	Настройки подписи на переходе, колонка «Запрашивать комментарий при подписании»	Переход	—
Обязательность причины у резолюции	Резолюция → параметр «Обязательна причина»	Резолюция	События: «Перед акцептом/делегированием/отклонением/удалением подписи»

При действии «Отклонить» причина обязательна всегда, независимо от этой настройки.

Сводная матрица настроек подписей — эскалирование, отзыв, динамика, условия¶

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

Тема	Где настраивается	Область	Смарт-события / смарт-действия
Эскалирование	Подпись → параметр «Можно эскалировать»	Подпись	События: «Перед эскалированием», «После эскалирования динамической подписи»
Эскалирование на переходе	Настройки подписи на переходе, колонки «Можно эскалировать», «Эскалировать, когда просрочена»	Переход	—
Подпись начальника	Подпись → блок «Подпись начальника»	Подпись	—
Отзыв подписи	Категория → параметры «Разрешить исполнителям отзывать...»	Категория	Смарт-действие: «Отозвать запрошенную подпись». События: «Перед/После отзыва подписи»
Динамическая подпись	Подпись → блок «Динамическая подпись», параметр «Может быть динамической»	Подпись	Смарт-действия: «Запросить динамическую подпись», «Запросить подпись пользователя». События: «Перед/После запроса динамической подписи»
Право запрашивать динамическую подпись	Группа → вкладка «Специальные права», параметр «Запрашивать динамическую подпись»	Группа	—
Право создавать динамическую подпись	Группа → вкладка «Специальные права», параметр «Создавать динамическую подпись»	Группа	—
Повторный запрос подписи	Подпись → параметр «Не запрашивать повторно»	Подпись	—
Повторный запрос на переходе	Настройки подписи на переходе, колонка «Не запрашивать повторно»	Переход	—
Отдельная копия каждому акцептанту	Настройки подписи на переходе, колонка «Каждому акцептанту отдельную копию»	Переход	—
Условия запроса	Настройки подписи на переходе, колонки «Обязательные ДП», «Условия запроса»	Переход	—
Последовательность подписей	Настройки подписи на переходе, колонка «Этап согласования»	Переход	—
Действие при отклонении	Настройки подписи на переходе, колонки «При отклонении», «В статус если отклонена», «При отклонении выполнить переход»	Переход	—
Действие при отклонении динамической	Подпись → блок «Динамическая подпись», параметр «Прерывать согласование...»	Подпись	—
SQL-процедура на переходе	Настройки подписи на переходе, колонка «Процедура»	Переход	—
Активность подписи	Настройки подписи на переходе, колонка «Активна»	Переход	—

Акцептанты «По параметру» — валидация и несколько акцептантов¶

При выборе алгоритма «По параметру» обязательны два поля:

Акцептант по умолчанию — выбор пользователя; помечено красной звёздочкой *.
Дополнительный параметр — выбор ДП, по которому строится таблица соответствий «значение → акцептант»; помечено красной звёздочкой *.

При попытке «Сохранить» с незаполненным обязательным полем запрос на сервер не отправляется; под полем выводится сообщение:

«Для алгоритма «По параметру» необходимо выбрать дополнительный параметр (ДП)» — для «Дополнительный параметр».
«Необходимо выбрать акцептанта по умолчанию» — для «Акцептант по умолчанию».

Сами поля рамкой не подсвечиваются — индикация только звёздочкой и сообщением под полем.

Несколько акцептантов на одно значение параметра (с 2.268.336 — бэк, с 2.268.346 — фронт). В таблице соответствий «значение ДП → акцептант» на одно значение можно назначить несколько пользователей. В Admin API и в форме настройки подписи каждый акцептант отображается отдельной строкой — со своим Id, ExtParamValue и UserId. До 2.268.336 имена нескольких акцептантов одного значения склеивались в одну запись через ;, а Id/UserId брались от последнего пользователя группы — отсюда поломанные сохранение и удаление.

UI-фикс грида и разрыв между бэк-/фронт-фиксами¶

В форме настройки подписи AdminSPA (signature-acceptors-by-ext-params-grid.component) после фикса работают три ранее сломанных сценария:

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

Способов добавить нескольких акцептантов на одно значение два: (1) сразу при создании строки выбрать нескольких пользователей в поле «Акцептанты», (2) добавить новую строку с тем же значением параметра и другим набором акцептантов.

Между релизами 2.268.336 (бэк) и 2.268.346 (фронт) — 10 версий, на которых API уже отдавал данные корректно, но UI грида в AdminSPA всё ещё склеивал пользователей и терял строки. На версиях 2.268.336 — 2.268.345 включительно использовать алгоритм «По параметру» с несколькими акцептантами на одно значение не следует — данные в БД могут быть корректными, а в интерфейсе отображаться неправильно. Полностью функционал работает с 2.268.346.

Под капотом сохранение приведено к паттерну, уже принятому для алгоритма «По группам» (UpdateSignatureAcceptorsByGroups): диффинг акцептантов идёт по естественному ключу (ExtParamValue, UserId), удаление выполняется точечно по PK строки — не пакетно по значению параметра, как раньше через старый DeleteAcceptorByExtParam(signatureId, extParamValue). Поэтому добавление, изменение или удаление одного акцептанта на конкретное значение параметра не затрагивает остальных, назначенных на то же значение.

Хранится в dbo.SignatureAcceptorsByExtParamValues (см. database.md). Сценарий с одним акцептантом на значение и остальные режимы определения акцептантов (по группам, по руководителю/оргструктуре, SetDefaultAcceptorsForExtParamSignature) фиксом не затронуты.

Обработка резолюции (пошагово)¶

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

Загрузка данных подписи и резолюции из БД.
Выполнение смарт-пакетов «Перед» (акцептом / делегированием / отклонением / удалением / эскалированием).
Проверка прав акцептанта.
Создание снимка задачи.
Запись нового состояния подписи и резолюции в БД.
Публикация комментария и отправка уведомления.
Проверка завершения текущего этапа; инициация следующего этапа при необходимости.
Обновление статуса задачи (снятие «На подписи»).
Отправка файлов в SharePoint.
Выполнение действий, подтверждённых подписью (смена срока, заказчика, трудозатраты).
Выполнение действий при отклонении (если подпись отклонена).
Переход задачи по маршруту.
Выполнение смарт-пакетов «После» (подписания / отклонения / удаления / эскалирования — статических и динамических).

Связи с другими доменами¶

Подписи связаны с другими доменами системы:

Домен	Связь
Задачи	Подписи — часть жизненного цикла задачи; запрашиваются на переходах; создают промежуточный статус «На подписи»
Категории	Маршрут согласования настраивается для каждой категории; настройки отзыва и подписей-для-действий — на уровне категории
Статусы и переходы	Подписи привязаны к конкретным переходам; этапы согласования определяют порядок
ДП (ext-params)	Условия запроса по значениям ДП; определение акцептантов по ДП; обязательные и информационные ДП; файлы для ЭЦП из ДП «Файл»
Пользователи и группы	Акцептанты определяются по группам, оргструктуре, руководителям; специальные права группы на подписи
Смарт-автоматизация	Обширный набор событий и действий; определение акцептантов по смарт-выражениям; условия запроса через смарт-фильтры
Уведомления	Персональные настройки уведомлений для события «Подписи»; почтовые уведомления акцептантам
Файлы	Подписание файлов через ЭЦП; создание системных копий при акцепте; снимки
Заместители	Заместители получают подписи замещаемого; настройка запрета подписания заместителем; отображение в листе согласования

CustomSettings и серверная криптография подписей¶

Дополнительное поведение подписей задаётся ключами CustomSettings:

Ключ	Тип	Назначение
`IsOldSignTicker`	bool	Если `true` — клик на индикатор подписей в SPA открывает старый список подписей. Используется при переходе на новый интерфейс для совместимости
`AddUserLoginToSignedFiles`	bool	Если `true` — логин акцептанта добавляется к имени SIG-файла при ЭЦП-подписании

Серверные ключи криптографии в appsettings.json:

Ключ	Default	Назначение
`DecodeEdsSignatures`	`true`	Серверная криптографическая верификация подписей ЭЦП при акцепте. Только для КриптоПро / РуТокен (`EbdsTypes.CryptoProRuToken`). Для DSS КриптоПро и Контур.Облако серверная проверка не выполняется (верификация на стороне облачного провайдера). При ошибке возвращается `Eds_CryptographicException`. ⚠️ Отключать (`false`), если на сервере не установлен КриптоПро CSP или недоступны корневые сертификаты УЦ — иначе акцепт упадёт

Типичные ошибки настройки подписей¶

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

Симптом	Причина	Где проверить	SQL-диагностика
«Подпись недоступна» на переходе	Подпись не привязана к шагу маршрута	Подписи на шаге маршрута	`select ss.*, s.Name from dbo.StepSignatures ss inner join dbo.Signatures s on ss.SignatureId = s.SignatureID where ss.StepId = {stepId}`
«Нет доступных резолюций»	К подписи не привязаны типы резолюций	Подпись → резолюции	`select s.Name, srt.* from dbo.SignatureResolutions sr inner join dbo.Signatures s on sr.SignatureId = s.SignatureID inner join dbo.SignatureResolutionTypes srt on sr.ResolutionTypeId = srt.Id where s.SignatureID = {id}`
ЭЦП не работает	Неверные настройки КриптоПро / DSS	Формы `cryptopro-verification-centers`, `dsscryptopro-service-settings`	`select * from dbo.CryptoProCertificationCenters; select * from dbo.DSSCryptoProCredentials`
Подпись требует комментарий, но нет поля	Тип резолюции требует комментарий	Форма `signature-resolution-types`	`select * from dbo.SignatureResolutionTypes where Id = {resTypeId}`
Динамическая подпись не появляется	Неверный SQL-маршрут или не настроена видимость	SQL-маршрут подписи на шаге	`select * from dbo.StepSignatures where StepId = {stepId} and IsDynamic = 1`

См. также:

Подписи — бизнес-логика — типы подписей, статическая и динамическая, акцептанты
Настройка категорий — маршруты, к шагам которых привязываются подписи
Интеграции — PayControl, Контур.Облако