Ключ задачи
Последнее обновление
2 апр. 2026 г.
Заметки о выпуске Adobe Sign (2021 г.)
Adobe Sign: март 2021
Улучшенные функциональные возможности
Веб-формы с несколькими подписантами
Аккаунты, использующие веб-формы, теперь могут разрешать участие нескольких внешних получателей в процессе подписания.
Дополнительные получатели определяются первоначальным подписантом:
Используйте шаблоны библиотеки для создания веб-форм
Авторы теперь могут использовать существующие шаблоны библиотеки для создания новых веб-форм.Файл импортируется с сохранением всех полей:
«Адаптивный режим» в Adobe Sign для мобильного просмотра
Liquid Mode — это дополнительная функция адаптивного просмотра, которая позволяет улучшить отображение документов в зависимости от типа устройства подписанта.
Подписанный документ сохраняется в стандартной версии «PDF», а получатели могут видеть Liquid Mode на мобильных телефонах и переключаться для просмотра исходного документа.
Теперь вы можете загрузить документ HTML и создать представление в адаптивном режиме для мобильных телефонов.
Заблокировать значение имени для известных пользователей при подписании методами изображения или нарисованной подписи
В некоторых ситуациях нежелательна возможность изменения имени получателя во время церемонии подписания. Adobe Sign обеспечивает гибкость с учетом имени, предпочитаемого подписантом. В более совместимых средах такая гибкость неприемлема, поэтому появился новый инструмент управления для блокировки имен получателей в документе.
Администраторы теперь могут запретить получателям с известными значениями имени изменять эти значения при применении нарисованной или подписи-изображения.
Ситуации, в которых известно значение имени:
- При отправке получателю с идентификатором Adobe Sign
- При отправке имени через API
- Когда поля Signer Info заполняются при заполнении формы
- Когда имя блокируется во время завершения аутентификации проверки знаний или удостоверения личности
Улучшения аутентификации на основе знаний
Добавлены элементы управления к методу аутентификации личности на основе проверки знаний, которые могут потребовать от отправителя указать имя для получателя, и это значение имени блокируется на протяжении всего процесса подписания.
Варианты усиленной безопасности электронной почты
Для повышения безопасности электронной почты добавлено два новых параметра. Оба параметра включены по умолчанию:
- Включить ссылку в электронные письма для просмотра подписанного документа
- Включить изображение первой страницы документа в электронные письма
- Этот параметр включен по умолчанию.
- При включении изображение первой страницы соглашения видно в некоторых рассылках электронной почты
Обновления REST API v6
Стандартные заголовки в каждом запросе V6 REST API
По умолчанию каждый запрос REST API v6 теперь имеет следующие стандартные заголовки:
/AGREEMENTS
Все конечные точки /agreements, которые имеют agreement id путь, теперь возвращают код ошибки 404 AGREEMENT_DESTROYED, если соглашение было удалено через инструменты GDPR.
ШАБЛОНЫ БИБЛИОТЕКИ
PUT /libraryDocuments/{libraryDocumentId} — расширен и включает новое поле ownerId
Примечание
Применяется только REST API v6.
Любой вызов v6 REST API, который не включает эти заголовки, будет явно документировать их отсутствие.
- GET /libraryDocuments — расширен и включает новое поле ownerEmail
- GET /libraryDocuments/{libraryDocumentId} — расширен и включает новые поля: ownerId, ownerEmail и ownerName
Новые поля в объекте LibraryDocumentInfo:
Поля с обновленным поведением:
ВЕБ-ФОРМЫ (/ВИДЖЕТЫ)
- POST /widgets — использование libraryDocumentId для создания веб-формы теперь поддерживается при наличии действительного идентификатора
Добавлен код статуса:
- PUT /widgets — использование libraryDocumentId для создания веб-формы теперь поддерживается с действительным идентификатором
Добавлен код статуса:
- PUT /widgets/{widgetId} — расширен и включает новое поле ownerId
Добавлен код статуса:
Изменения интерфейса
- GET /widgets/{widgetId} — Расширен и включает новые поля: ownerId, ownerEmail, ownerName, и creatorName
Новые поля в объекте WidgetInfo:
Поля с обновленным поведением:
/MEGA SIGN
НОВИНКА:
- GET /megaSigns/{megaSignId}/formFields - Получает сведения о полях формы родительского соглашения Mega Sign
Параметры:
Объект ответа:
- PUT /megaSigns/{megaSignId}/formFields - Обновляет поля формы соглашения Mega Sign
Параметры:
Объект ответа:
ОБНОВЛЕНО:
- POST /megaSigns - AUTHORING добавлено в качестве значения состояния для поддержки создания шаблона Mega Sign
Изменен параметр:
- PUT /megaSigns/{megaSignId}/state - AUTHORING добавлено как значение состояния для поддержки создания шаблона Mega Sign.В результате megaSignCancellationInfo больше не является обязательным полем
Обновленная главная страница и страница «Управление» включены для всех оставшихся учетных записей
Для всех учетных записей настройки управления обновлены с целью включения современных страниц «Главная» и «Управление» для пользователей.
Элементы управления в меню администратора остаются доступными для учетных записей, которым необходимо вернуться к классическому интерфейсу:
Уровень сервиса Adobe Sign и идентификатор учетной записи отображаются в меню администратора
Администраторы теперь могут найти свой Account ID на странице Глобальные настройки:
Group ID можно найти на странице Настройки группы:
Явная настройка HIPAA
Доступна новая страница, которая четко показывает, когда учетная запись позволяет управлять документами, на которые распространяются требования HIPAA.
- Этот элемент управления доступен только на уровне учетной записи. У администраторов на уровне группы нет доступа.
- Этот элемент управления доступен только для просмотра, чтобы четко указать, когда учетная запись настроена
- Обратитесь к менеджеру по работе с клиентами или в службу поддержки, чтобы включить конфигурацию HIPAA.
Дополнительные сведения о настройках HIPAA можно найти здесь >
Кнопка «Призыв к действию» изменилась для заказчиков, использующих приложение Outlook для настольных ПК в системах Windows
Получатели, использующие клиент электронной почты Outlook для ПК, увидят изменение кнопки «Призыв к действию» в сообщениях электронной почты Adobe Sign.
Новый интерфейс убирает синюю кнопку HTML и вместо этого предоставляет кликабельную текстовую ссылку:
Примечание
Это изменение влияет только на приложения Outlook для настольных ПК в системах Windows. В других почтовых клиентах и операционных системах остается синяя кнопка для получения шаблона.
Делегирование соглашений с цифровыми подписями
Возможность делегировать соглашение с прикрепленными цифровыми подписями была улучшена, чтобы разрешить делегирование от уведомления в исходном электронном письме получателю через автоматическое делегирование при настройке пользователем, а также через действие Заменить текущего подписывающего на странице Управление .
Обновленный интерфейс для интеграции платежей
Интерфейс Платежи был обновлен для лучшего отображения элементов управления аутентификацией, что упрощает процесс настройки.
Максимальное значение для управления данными увеличено до 5475 дней (15 лет)
Заказчики, которые используют правила управления данными для автоматического удаления соглашений из системы Adobe Sign, теперь могут установить дату удаления на максимум 15 лет (вместо десяти).
Текстовая метка на уровне поля для проверки номера социального страхования США была обновлена:
Текстовая метка на уровне поля для проверки номера социального страхования США была обновлена для уточнения, что SSN является американским:
Напоминание. Социальная аутентификация была удалена
Как было объявлено в ноябре, метод аутентификации с использованием социальной идентификации был удален из списка методов аутентификации в меню администратора.
Напоминание. Личная интеграция с Twitter была удалена
Как было объявлено в декабре, удалена возможность устанавливать персональные подключения для аутентификации через Twitter.
Неактивные пользователи получат уведомление по электронной почте при включении в соглашение
Пользователи со статусом Неактивный теперь получают уведомление по электронной почте с инструкцией делегировать соглашение другому пользователю.
Решенные проблемы
Adobe Sign: май 2021
Улучшенные функциональные возможности
Передача прав владения шаблонами библиотеки и веб-формами другому владельцу
Теперь изменить владельца ресурса может любой администратор с соответствующим доступом.
Администратор может назначить право владения активом любому пользователю под своим управлением.
- Администраторы учетной записи имеют доступ ко всем общим ресурсам и всем пользователям. Поэтому они могут переназначить права владения шаблоном библиотеки или веб-формой любому пользователю в их учетной записи.
- Если ресурс доступен только одному пользователю (владельцу), он не является общим и не может быть переназначен другому владельцу.
- Администраторы групп имеют доступ только к шаблонам библиотек и веб-формам групп, в которых у них есть соответствующие права.
- Администраторы групп могут переназначить актив только пользователю, основная группа которого находится под их административным управлением
ОБНОВЛЕННЫЕ КОНЕЧНЫЕ ТОЧКИ API С ПОДДЕРЖКОЙ ПЕРЕДАЧИ АКТИВОВ
Указанные ниже конечные точки доступны только в REST API v6.
Расширение для поддержки обновления владельца документа библиотеки.
LibraryDocumentInfo:
Дополнительные коды состояния ошибок:
Дополнительные коды состояния ошибок:
Новые поля в объекте LibraryDocument:
Новые поля в объекте LibraryDocumentInfo:
Поля с обновленным поведением:
Новые поля в объекте WidgetInfo:
Поля с обновленным поведением:
Изменения интерфейса
Стандартное возвращаемое значение v6 REST GET /workflows{workflowId} изменилось
Вызов API v6 REST GET /workflows{workflowId} был обновлен для возврата текущей версии WorkflowID (вместо исходной версии ID, которая была возвращаемым значением до майского релиза)
Данное обновление приводит стандартный API в соответствие с Webhook, предоставляя одинаковый WorkflowID, что должно улучшить разработку и управление приложениями.
Если по какой-либо причине вашей учетной записи требуется, чтобы API возвращал исходный ID (как это было до майского выпуска), обратитесь в поддержку с запросом на возврат базовых версий ID для рабочих процессов
Решенные проблемы
Adobe Sign: июнь 2021
Пользователи, состоящие в нескольких группах (UMG)
Администраторы нескольких учетных записей с несколькими группами теперь могут предоставлять пользователям доступ к нескольким группам в рамках их учетных записей, что позволяет использовать группы в качестве формы шаблона рабочего процесса, требующей определенных элементов управления для отправки и подписи шаблонов библиотеки, доступных группе.
Для существующих корпоративных учетных записей и учетных записей для бизнеса, которые необходимо обновить, см. инструкции по обновлению здесь >
Примечание
В настоящее время Liquid Mode доступен только в средах NA1, NA2 и NA4.
Удобное обновление веб-форм
Веб-формы в статусе Черновик можно отредактировать, чтобы изменить:
- имя веб-формы;
- редактирование адресов электронной почты подписантов
- адрес электронной почты сторон, получающих копию
- прикрепленные файлы для редактирования;
- поля веб-формы, которые были ранее доступны.
Обновление веб-формы Активная позволяет редактировать элементы формы без изменения исходного URL-адреса, что упрощает процесс обновления содержимого веб-формы, которое уже встроено или отправлено аудитории. Элементы, которые можно редактировать:
- файлы (документы) и примененные поля для получателей;
- подписантов (со страницы «Управление»);
- получателей в копии (со страницы «Управление»).
Примечание
Для обеспечения оптимальной работы веб-форм необходимо включить параметр Разрешить присутствие дополнительных участников в меню Глобальные настройки:
Штамп участника: управление отображением должности и названия компании
Были добавлены элементы управления, позволяющие отображать или скрывать Должность и Название компании получателя (из профиля пользователя) в поле штампа участника.
Дополнительная информация представлена на странице «Типы полей» >
Улучшенные параметры поиска: сопоставления префиксов и фраз
Расширенные параметры поиска были представлены для обеспечения более точной работы шаблонов поиска, которые позволят сократить список искомых документов.
Дополнительная информация о работе поисковых механизмов в Adobe Sign представлена здесь >
OAuth 2.0 теперь устанавливается по умолчанию
Чтобы избежать ошибок при использовании, добавлена новая (улучшенная) версия конечной точки OAuth. В этой версии:
- api_access_point / web_access_point возвращает только запрос маркера доступа (в теле)
- Adobe Sign не принимает секретный ключ в качестве параметра запроса
- Поддерживается ротация секрета клиента
Конечная точка OAuth v1 будет по-прежнему работать для существующих подключений еще несколько месяцев для обеспечения непрерывного доступа.
Уведомление об отказе от OAuth v1 будет опубликовано на странице технических уведомлений после составления расписания.
Изменение секретного ключа клиента
Любой администратор сможет изменить секретные ключи приложений благодаря доступу к идентификатору приложения в пользовательском интерфейсе Adobe Sign.
Изменения интерфейса
Администраторы группы могут видеть только те приложения API, на которые распространяются их полномочия
В списке приложений, прикрепленных к учетной записи, теперь отображаются только приложения, на которые распространяются административные права пользователя. Только администраторы группы увидят изменения:
- Пользователям отображаются только их приложения
- Администраторам группы отображаются приложения, на которые распространяются их полномочия
- Администраторам учетных записей приложения отображаются в учетной записи
Обновлено сообщение эл. почты для отправителя при завершении работы с документом
Обновлено уведомление по эл. почте о завершении работы с документом, получаемое отправителем, для отображения полного списка всех сторон, осведомленных о завершении документа.
Только изначальный отправитель получит этот шаблоны сообщений эл. почты.
Обновленный результат v6 REST API для GET /agreements/{agreementId}/signingUrls
До июньского выпуска при вызове API-интерфейса GET /agreements/{agreementId}/signingUrls сразу после создания документа отображалась ошибка 404.
Почти сразу после устранения ошибки 404 она больше не появится, но будут возращены адреса signingURL отправителя. (Пока участие подписанта все еще определяется.)
После запуска в июне 2021 г. код 404: AGREEMENT_NOT_EXPOSED будет возвращен, пока не будет завершен полный список URL-адресов для подписи, после чего будет доставлен код 200.
Клиентам, которые не желают вызывать API-интерфейс до возращения ответа 200, рекомендуется использовать веб-перехватчики и ответить на событие AGREEMENT_CREATED.
Решенные проблемы
Adobe Sign: август 2021 г.
Изменения интерфейса
- Международная поддержка Aadhaar — заказчики с любыми экземплярами Adobe Sign теперь могут использовать дополнительную службу Aadhaar в качестве поставщика цифровой подписи. Ранее этой возможностью обладали только учетные записи в экземпляре IN1. Дополнительный модуль Aadhaar можно приобрести за дополнительную плату в рамках каждой транзакции подписания.
- Обновление REST v6: POST /users — вызов API REST v6 POST /users обновлен для создания пользователя в группе по умолчанию учетной записи, если дополнительный параметр primaryGroupId не задан. Это изменение затрагивает только версию 6 REST API.
Решенные проблемы
|
|
Описание |
|---|---|
|
4299495 |
Исправлена проблема в конструкторе технологического процесса, из-за которой определенный заказчиком URL в инструкциях не работал. |
|
4308294 |
Исправлена проблема в CSV-файле отчета, где поля «Кому» и «Имя получателя» могли оставаться пустыми, когда один и тот же адрес электронной почты получателя использовался более одного раза в соглашении. |
|
4310569 |
Шаблоны Adobe Sign исключены из параметров песочницы. |
|
4311098 |
Исправлена проблема, из-за которой администраторы групп не могли обновлять пользователей в группе через загрузку CSV. |
|
4311723 |
Исправлена проблема, из-за которой API-вызов GET /groups/ID/users завершался ошибкой, если пользователь находился в другом экземпляре Adobe Sign. |
|
4312103 |
Исправлена проблема, из-за которой пользователи SAML, созданные через массовую загрузку, находились в состоянии «Создан» (вместо «Активный»). |
|
4312309 |
Исправлена проблема, из-за которой администраторы групп не могли переназначать владельца веб-форм, если их создавали другие пользователи в их группе. |
|
4312840 |
Исправлена проблема с активацией новых пользователей, когда новому пользователю отправлялось второе письмо активации и использовалась ссылка из этого второго письма. |
|
4314751 |
Исправлена проблема, из-за которой параметр «Отклонить соглашение» не отображался при подписании от имени другого пользователя. |
|
4315033 |
Исправлена проблема, при которой администраторы учетной записи не могли сбросить пароли, когда режим SAML был установлен в «Обязательный». |
|
4315605 |
Исправлена проблема, из-за которой изображения удостоверения личности не обрабатывались успешно. |
|
4316057 |
Исправлена проблема, при которой удостоверение личности выдавало ошибку, указывающую на то, что четыре угла документа не найдены. |
|
4316474 |
Исправлена проблема, из-за которой функция «Подписать от имени» отображалась в учетных записях, где этот параметр не был включен. |
|
4316659 |
Решена проблема, при которой адрес электронной почты «actingUserEmail» в вызове GET /agreements/id возвращал сгенерированный системой адрес электронной почты после того, как соглашение было полностью подписано. |
|
4317095 |
Исправлена проблема, из-за которой имя получателя импортировалось в метку «Участник 1» при использовании аутентификации на основе знаний для первого подписывающего. |
|
4317221 |
Исправлена проблема, из-за которой автоматические уведомления по электронной почте о сбоях веб-хуков отправлялись создателю веб-хука, несмотря на настройку не уведомлять создателя. |
|
4317347 |
Исправлена проблема, при которой аутентификация OAuth в Power Automate перенаправляла пользователя на главную страницу. |
|
4317429 |
Исправлена проблема, из-за которой администраторы не могли обновить свойство «Может отправлять» для пользователей при обновлении через загрузку CSV. |
|
4317548 |
Исправлена проблема, из-за которой некоторые заказчики, использующие iPad, видели веб-страницу вместо страницы, оптимизированной для мобильных устройств. |
|
4317629 |
Исправлена проблема отображения имен, содержащих апостроф, при которой отображался HTML-код апострофа. |
|
4318175 |
Исправлена проблема, при которой пользователи получали ошибку при архивации учетной записи по ссылке из сообщения электронной почты. |
|
4319012 |
Решена проблема, при которой пользователи, созданные с помощью POST /users в REST v5 и v6 не создавались в группе по умолчанию. |
|
4320197 |
Исправлена проблема, при которой отчет об удостоверении личности подписавшего нельзя было загрузить со страницы «Управление» из-за неактивности кнопки. |
Adobe Sign: сентябрь 2021 г.
Улучшенные функциональные возможности
- Изолированная программная среда — заказчики уровня «Организация» могут приобрести доступ к изолированной программной среде для тестирования шаблонов, своих рабочих процессов, приложений API и многого другого. Эти объекты можно переместить из производственной среды в изолированную для безопасного обновления и вернуть обратно после проверки и подготовки обновлений к развертыванию.
- Поддержка цифровых подписей ECDSA — Adobe Sign теперь поддерживает более безопасные и эффективные цифровые подписи на основе формата ECDSA, который использует криптографию эллиптических кривых, как определено в стандарте ANS X9.62-2005.
Теперь поддерживаются кривые NIST с хэш-функциями SHA-2 по стандартам FIPS, что позволяет нашим доверенным поставщикам услуг (TSP) из консорциума Cloud Signature Consortium быстрее предоставлять подписывающим сторонам более надежные учетные данные на основе эллиптических кривых, включая соответствующие рекомендуемым требованиям для использования в федеральных учреждениях США и госучреждениях в Сингапуре.
- Обновленный режим Liquid Mode. Процесс подписания в режиме Liquid Mode был расширен: теперь подписывать можно не только документы, но и веб-формы. Формы Liquid Mode значительно упрощают процесс подписания. Больше не нужно изменять масштаб, чтобы увидеть содержимое формы. Кроме того, поля, требующие заполнения, теперь находятся «в фокусе».
Кроме того, режим Liquid Mode больше не ограничивается североамериканскими шардами.Все корпоративные и бизнес-аккаунты теперь имеют доступ независимо от местоположения.
- Новые доверенные поставщики услуг. Новыми доверенными поставщиками услуг консорциума Cloud Signature Consortium стали Cleverbase (Нидерланды), PrimeSign (Австрия), Sectigo (междунар.), TrustPro (Ирландия), которые предоставляют сертификаты для применения безопасных цифровых подписей в соответствии с самыми высокими стандартами и требованиями.
- Настройка полей «Кому» и «Копия» в заголовках писем получателям — заказчики, обеспокоенные утечкой адресов электронной почты через заголовки писем получателям, могут скрыть значения адресов электронной почты в полях «Кому» и «Копия».
- Этот параметр доступен для учетных записей уровня «Организация» и «Бизнес» и его можно настроить на уровне учетной записи и группы.
- Чтобы открыть элементы управления функцией, перейдите в «Настройки учетной записи» > «Настройки электронной почты» > «Настроить поля «Кому» и «Копия»».
Изменения интерфейса
- Принятие условий использования Adobe на странице электронного подписания. Для обеспечения соответствия юридическим требованиям Adobe Sign изменяет процедуру принятия условий использования на странице электронного подписания. При использовании нового интерфейса все «неизвестные» получатели будут должны принять условия использования и политику конфиденциальности Adobe Sign (нажав кнопку Продолжить), прежде чем выполнять действия с документом. Этот процесс принятия отличается от других пользовательских процедур принятия условий, которые могут быть настроены в учетной записи пользователя. Узнайте больше о настройке процедуры принятия условий использования/соглашения о неразглашении.
- «Неизвестный» получатель — это любой адрес электронной почты, который не является зарегистрированным активным пользовательским адресом электронной почты в доверенной учетной записи.
- «Известные» пользователи приняли условия использования Adobe Sign в процессе регистрации при подтверждении учетной записи пользователя, поэтому им больше не предлагается принять условия использования.
Ниже приведен пример явного согласия для документа с пользовательскими условиями, настроенными клиентом:
- Примите условия использования Adobe Sign, нажав кнопку Продолжить (после открытия документа).
- Заполните необходимые поля в документе.
- Примите Customer Disclosure и custom ToU, нажав кнопку «Нажмите, чтобы подписать».
- Блокировка имен теперь распространяется также на напечатанные подписи. В выпуске за март появилась настройка для включения/отключения возможности получателя редактировать значение имени при подписании при условии, что имя было предоставлено или уже было известно (через API или профиль пользователя). Эта настройка не применялась к напечатанным подписям, что приводило к изменению имен некоторыми лицами в процессе подписания. Это функция была обновлена в выпуске за сентябрь. Теперь имена блокируются во всех типах подписей, включая напечатанные.
- Клиенты, которые включили «Ввод имени и инициалов» и отключили «Подписывающие могут изменять свое имя или инициалы», столкнутся с изменением в поведении — значение имени больше нельзя будет редактировать в процессе подписания для набранных подписей.
- Пользователи, которые хотят разрешить редактирование значения имени во время процесса подписания, должны включить параметр Подписывающие стороны могут изменять свое имя или инициалы при подписи документа от руки или при загрузке подписи (в меню Настройки подписи).
- Подписание документов неактивными пользователями. Теперь неактивные пользователи в Adobe Sign рассматриваются как неизвестные системе (для подписания входящих документов). Когда неактивный пользователь получает запрос на подписание документа, создается новый одноразовый идентификатор пользователя для подписания этого документа. Одноразовый идентификатор пользователя не связан с идентификатором неактивного пользователя и учетной записью, которая им управляет. Это влечет за собой определенные последствия.
- Документы, отправляемые неактивному пользователю, могут быть подписаны, так как статус «Неактивный» не применяется к одноразовым идентификаторам пользователей, созданным для работы с этим документом.
- Документы, подписанные с помощью одноразового идентификатора пользователя, не связаны с идентификатором неактивного пользователя и не принадлежат к учетной записи неактивного пользователя.
- Документы, подписанные с помощью одноразового идентификатора пользователя, не будут входить в список общих файлов, доступных неактивному пользователю.
- Документы, подписанные с помощью одноразового идентификатора пользователя, не будут входить в отчеты, связанные с документами неактивного пользователя.
- При повторной активации неактивного идентификатора пользователя на странице «Управление» не будут отображаться записи о документах, подписанных с помощью одноразового идентификатора пользователя.
Существует два исключения из вышеуказанного поведения:
- Документы, отправленные пользователю до того, как они были отмечены как неактивные, не могут быть подписаны (документ уже привязан к неактивному идентификатору пользователя).
- Пользователям, для которых явно настроен запрет на подписание соглашений, по-прежнему будут недоступны любые действия по подписанию.
Неактивные пользователи по-прежнему не смогут входить в систему Adobe Sign и отправлять документы в рамках своих полномочий (любым способом).
- Улучшенная защита доступа к веб-форме с помощью пароля — веб-формы теперь предусматривают задержку после нескольких неудачных попыток доступа к URL-адресу, защищенному паролем.
- Международная поддержка Aadhaar — заказчики с любыми экземплярами Adobe Sign теперь могут использовать дополнительную службу Aadhaar в качестве поставщика цифровой подписи. Ранее этой возможностью обладали только учетные записи в экземпляре IN1. Дополнительный модуль Aadhaar можно приобрести за дополнительную плату в рамках каждой транзакции подписания.
- Ограниченный обмен соглашениями — обмен соглашениями был ограничен при отправке соглашения на внешний адрес электронной почты.
- Учетные записи с несколькими лицензиями могут предоставлять доступ к одному документу не более десяти раз.
- Индивидуальные аккаунты могут поделиться соглашением до 5 раз.
- Ограничения на предоставление общего доступа к документу внутренним пользователям отсутствуют.
- Учетные записи с несколькими лицензиями могут предоставлять доступ к одному документу не более десяти раз.
- Из раздела «Аутентификация по телефону» сервиса удалено настраиваемое название компании — настраиваемое значение названия компании, которое можно было указать в методе аутентификации по телефону, было удалено из службы, как указано в техническом уведомлении за июнь.
- Учетные записи, соответствующие HIPAA, теперь могут получать доступ к элементам управления изображениями и ссылками в сообщениях электронной почты для получателя на странице Глобальные настройки/настройки группы.
- Порядок включения вложенных файлов в итоговый PDF был обновлен для сортировки сначала по номеру страницы, а затем по позиции поля (при чтении слева направо; сверху вниз)
- Функция Замена получателя на новой странице Управление не позволяет отправителю включать дополнительное сообщение для нового получателя.
- Теперь внешние подписанты, получающие доступ к завершенным документам, должны пройти аутентификацию, если для документа настроена многофакторная аутентификация (вместо получения запроса на вход в Adobe Sign).
- Теперь веб-формы сообщают о значениях полей в неподтвержденных веб-формах при доступе к данным полей с помощью функции Загрузка данных полей формы на странице Управление.
Обновления API
- Возможность чтения документа при использовании веб-форм — доступны два новых вызова API REST v6 для предоставления доступа для просмотра веб-форм:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} теперь возвращает ответ с ролью участника.
Решенные проблемы
| 4292343 | Улучшена четкость подписи при использовании функции подписи TYPE на мобильных устройствах. |
| 4295123 | Устранена проблема, из-за которой цифровые подписи могли не отображаться при открытии в браузере. |
| 4299289 | Улучшена функция «Замена получателя»; теперь отправитель может добавить сообщение новому получателю. |
| 4299857 | Устранена проблема, при которой к подписанному документу могла не применяться печать сертификата. |
| 4304261 | Устранена проблема, при которой параметр «Прочитать документ» не указывался в меню «Параметры». |
| 4308516 | Устранена проблема, при которой пользователям постоянно требовалось разрешение администратора для использования OneDrive. |
| 4310225 | Устранена проблема с документами, содержащими несколько подписей, которая могла привести к ошибке сервера: «Сообщение об ошибке: подпись, поставленная в этом документе, недействительна. Очистите документ и снова подпишите». |
| 4310416 | Обновлен API-интерфейс REST v5 для создания пользователей в активном состоянии при создании с помощью POST /users. |
| 4311287 | Устранена проблема, при которой кнопка навигации группы не появляется в учетных записях с включенной функцией UMG после удаления пользователя из группы. |
| 4311956 | Устранена проблема, при которой заданный размер шрифта для поля не применяется в интерфейсе подписывающей стороны. |
| 4312302 | Устранена проблема, при которой параметр «Сбросить пароль» не отображается, если режим SAML является обязательным. |
| 4312735 | Устранена проблема, при которой общие уведомления о событиях доставлялись при отключении общих уведомлений. |
| 4313025 | Устранена проблема, при которой роль «Заполняющий» не могла заполнить неназначенные роли, если включен гибридный порядок подписания. |
| 4313030 | Устранена проблема, при которой учетные записи с включенной функцией UMG получали ошибку при использовании пользовательского рабочего процесса, если основная группа отправителя не имеет разрешений для отправки. |
| 4313264 | Обновлен параметр, соответствующий HIPAA, чтобы разрешить доступ к настройкам ссылок / изображений электронной почты на странице «Глобальные настройки». |
| 4315839 | Исправлена ошибка пользовательских рабочих процессов, которая не позволяла предварительно заполнять поля, если отправитель также являлся вторым получателем. |
| 4316058 | Обновлено поведение поля отчета; начальные нули теперь допускаются в текстовых полях. |
| 4317382 | Исправлена ошибка переключателей, при которой код HTML отображался для апострофов во всплывающей подсказке. |
| 4317978 | Обновлен порядок размещения вложенных файлов в окончательном документе PDF; вложения вначале группируются по номеру страницы поля, затем по относительному положению поля (при чтении слева направо, сверху вниз). |
| 4318598 | API-вызов REST v6 GET/workflows/{workflowId} теперь возвращает ответ с ролью участника. |
| 4318606 | Функция «Загрузка данных полей формы» на странице «Управление» теперь возвращает значения полей веб-форм, которые еще не проверены. |
| 4318617 | Устранена проблема, при которой учетные записи с включенной функцией UMG не позволяли администратору группы повторно отправлять приглашение. |
| 4318679 | Устранена периодическая проблема, которая могла привести к сбою загрузки документов с рукописной подписью. |
| 4318926 | Исправлена проблема, которая могла привести к ошибке («Функция cookie отключена в браузере») при создании документа на мобильном устройстве. |
| 4318991 | Устранена проблема, при которой параметр максимального числа ошибок входа игнорировался, если для SAML установлено значение «Разрешено». |
| 4319068 | Внешние получатели теперь должны пройти процесс двухфакторной аутентификации (вместо входа в Adobe Sign), чтобы получить доступ к заполненным документам, если многофакторная аутентификация включена. |
| 4319422 | Устранена проблема, при которой получатель мог быть заменен без подтверждения пароля (для документов, требующих ввода пароля). |
| 4319455 | Устранена проблема расширенного общего доступа, при которой настройки не сохранялись после сохранения. |
| 4320123 | Устранена проблема, которая могла вызвать ошибку при попытке просмотра и утверждения документа на странице «Управление». |
| 4320205 | Устранена проблема, которая могла препятствовать сохранению хода работы при предварительном заполнении документа с помощью расширенного общего доступа. |
| 4320542 | Устранена проблема учетных записей с включенной функцией UMG, при которой принадлежность пользователя ко всем группам могла быть удалена, если одна группа была удалена с помощью поиска. |
| 4321357 | Устранена проблема, которая могла вызвать ошибку на странице отправки, если для проверки подлинности выбрана аутентификация на основе знаний и включена функция «Требуется имя при отправке». |
| 4322445 | Улучшена среда авторинга для обеспечения согласованного цвета фона. |
| 4322956 | Устранена проблема пользовательских шаблонов электронной почты, при которой получатели не видели фактический адрес электронной почты подписывающей стороны. |
| 4323609 | В разработке — устранена проблема, при которой документы, работа над которыми завершена путем загрузки подписанного документа, не запускали уведомление веб-перехватчика AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | Улучшена функция блокировки подписи для включения напечатанных подписей, если значение имени указывается через профиль или API. |
Adobe Sign: октябрь 2021 г.
Улучшенные функциональные возможности
- Ссылки для сообщения о нарушениях — учетные записи малых компаний и индивидуальных пользователей теперь содержат ссылку, по которой клиенты могут сообщить о потенциальном нарушении работы с запросами входящих документов.
- Интеграция с Notarize — интеграция Adobe Sign с платформой Remote Online Notarization (RON) компании Notarize, Inc. позволяет клиентам добавлять сервис удаленного нотариального заверения в транзакции Adobe Sign. Эта функция доступна пользователям уровня «Организация» и «Бизнес» в США и продается непосредственно компанией Adobe в рамках программы ETLA. Только участники этой программы могут приобретать транзакции нотариального заверения за дополнительную плату.
- Обновленная страница Отправка — пользователи с активированной функцией нотариального заверения могут выбрать опцию Требует нотариального заверения для получателей справа от метода аутентификации.
- Обновленная страница Отправка — пользователи с активированной функцией нотариального заверения могут выбрать опцию Требует нотариального заверения для получателей справа от метода аутентификации.
Примечание
Клиенты, использующие встроенную страницу Отправка в приложениях или интеграциях, также получат доступ к функции нотариального заверения.
После настройки документа и нажатия отправителем кнопки «Далее» отправитель может настроить дополнительные параметры конфигурации для процедуры нотариального заверения.
- Обновления API — API-интерфейсы были существенно изменены для поддержки интеграции с Notarize.
POST /agreements
API-интерфейс POST /agreements был обновлен для поддержки отправки документа для нотариального заверения.
- Для обозначения участника сеанса нотариального заверения необходимо использовать новую роль NOTARY_SIGNER.
- В определение AgreementInfo добавлен новый атрибут NotaryInfo, содержащий все параметры, связанные с созданием нового документа, требующего нотариального заверения.
|
Имя параметра |
Объект REST |
Описание |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Массив объектов ParticipantInfo, содержащий данные об участнике (например, адрес электронной почты). Все участники в массиве относятся к одному набору. |
||||||||||||||||
|
role |
|
Роль применяется ко всем участникам в наборе (подписант, утверждающий и т. д.). |
Расширение FileInfo
Определение FileInfo должно быть развернуто, чтобы указать, какие документы должны быть нотариально заверены.
|
Имя параметра |
Тип |
По умолчанию |
Обязательно |
Описание |
|---|---|---|---|---|
|
документ |
Document |
|
необязательно |
Документ, связанный с соглашением. |
|
label |
Строка |
|
необязательно |
Уникальное значение метки элемента информации файла. Для пользовательского рабочего процесса файл будет сопоставлен с соответствующим элементом файла в определении рабочего процесса. |
|
libraryDocumentId |
Строка |
|
необязательно |
Идентификатор для существующего документа библиотеки, который будет добавлен в документ. |
|
transientDocumentId |
Строка |
|
необязательно |
Идентификатор для промежуточного документа, который будет добавлен в документ. |
|
notarize |
true |
false |
необязательно |
Указывает, что документ требует нотариального заверения. |
Расширение ParticipantInfo
Определение ParticipantInfo было развернуто, чтобы указать метод аутентификации нотариального заверения.
|
Имя параметра |
Тип |
По умолчанию |
Обязательно |
Описание |
|---|---|---|---|---|
|
|
Строка |
— |
обязательно |
Адрес электронной почты участника. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
необязательно |
MULTI_FACTOR_AUTHENTICATION — аутентификация нотариального заверения выполняется методом двухфакторной аутентификации. |
NotaryInfo
В определение AgreementInfo добавлено новое необязательное поле notaryInfo , содержащее объект NotaryInfo, в котором указаны дополнительные параметры, связанные с нотариальным заверением.
|
Имя параметра |
Тип |
По умолчанию |
Обязательно |
Описание |
|---|---|---|---|---|
|
notaryType |
Enum |
Если только опция Использовать услугу «Нотариальное заверение по требованию» включена для учетной записи, |
обязательно |
NOTARIZE_NOTARY — сервис Notarize обеспечивает возможности нотариального заверения. |
|
payment |
Enum |
BY_SENDER |
необязательно |
Применимо, только если type == NOTARIZE_NOTARY. |
|
appointmentStart |
Строка |
"" |
необязательно |
ISO_DATE_TIME строка с форматированием. См. ISO_ZONED_DATE_TIME. |
|
note |
Строка |
нет |
необязательно |
Примечания для сеанса нотариального заверения. |
|
notaryEmail |
Строка |
"" |
необязательно |
адрес электронной почты «Предоставьте собственного нотариуса». |
Пример /agreement
PUT|GET /agreements/{aid}
PUT /agreements/{aid} API-интерфейс будет поддерживать обновление документа с параметрами нотариального заверения. API-интерфейс GET /agreement/{aid} возвращает любые параметры, установленные для нотариального заверения документа. Для просмотра обновленных атрибутов см. раздел POST /agreements.
Коды ошибок
Существующие коды ошибок для POST /agreements остаются без изменений. Определен новый код ошибки (см. ниже).
|
Код ошибки REST |
Код состояния HTTP |
Сообщение |
Ситуация |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
Настройки пользователя или маркер области OAuth не допускают отправку документа для нотариального заверения. |
Эта ошибка возникает, если задана роль NOTARY_SIGNER, а вызывающая сторона API (например, возможный отправитель) не имеет включенной функции нотариального заверения и/или если поставщик услуг нотариального заверения не задан. |
Влияние на документацию
В объекте AgreementInfo запроса элемент «status» будет включать новое состояние документа WAITING_FOR_NOTARIZATION.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
API-интерфейс может использоваться клиентами (подписантами с нотар. заверенной подписью) для получения маркера подписания, необходимого для завершения этапа электронного подписания в потоке.
- Добавлена новая функция подписания для новой роли — ACCEPT_BEFORE_NOTARIZATION.
- Маркеры подписания не следует получать для завершения этапа нотариального заверения.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
API-интерфейс может использоваться клиентами (подписантами с нотар. заверенной подписью) для завершения этапа электронного подписания в потоке. Для новой роли добавлено новое значение состояния enum — ACCEPTED_BEFORE_NOTARIZATION.
|
Атрибут |
Тип |
Описание |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Статус |
Enum<String>
|
|
||||||||||||||
Подписант с нотариально заверенной подписью может выполнить следующую последовательность вызовов API для завершения этапа электронного подписания.
- GET /agreements/{agreementId}/members — для получения идентификатора участника и идентификатора набора участников подписанта с нотариально заверенной подписью.
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens — для запроса маркера подписания для подписанта с нотариально заверенной подписью с функцией ACCEPT_BEFORE_NOTARIZATION.
- POST /transientDocuments — для загрузки просмотренного документа.
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status — для отправки просмотренного документа и завершения этапа электронного подписания.
Новое событие веб-перехватчика
Клиенты могут подписаться на новое событие веб-перехватчика AGREEMENT_READY_FOR_NOTARIZATION, чтобы получать уведомления, когда документ готов для нотариального заверения. Событие не отображается в пользовательском интерфейсе веб-перехватчиков; подписку можно создать через API-вызов POST /webhooks.
Влияние на документацию
Следующие API-интерфейсы не изменены, но их документация была обновлена, чтобы включить новое состояние документа «WAITING_FOR_NOTARIZATION» или новую роль «NOTARY_SIGNER».
GET /agreements
В ответном объекте UserAgreements/UserAgreement элемент «status» теперь содержит соответствующее состояние «WAITING_FOR_NOTARIZATION».
GET /agreements/{agreementId}
В ответном объекте AgreementInfo элемент «status» теперь содержит соответствующее состояние «WAITING_FOR_NOTARIZATION».
GET /agreements/{agreementId}/events
API-интерфейс обновлен для поддержки новых событий READY_TO_NOTARIZE и NOTARIZED.
В ответном объекте Event
- элемент «participantRole» теперь содержит новую роль NOTARY_SIGNER;
- элемент «type» включает новые события READY_TO_NOTARIZE и NOTARIZED. Элемент «description» будет иметь значения «Документ отправлен на нотариальное заверение» и «Нотариально заверенный документ получен» соответственно.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
В ответном объекте DetailedParticipantSetInfo элемент «status» теперь содержит соответствующее состояние «WAITING_FOR_NOTARIZATION».
PUT /agreements/{agreementId}
Объект запроса AgreementInfo теперь содержит состояние «WAITING_FOR_NOTARIZATION».
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
Состояние WAITING_FOR_NOTARIZATION является одним из значений элемента «status» в объекте DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
Статус WAITING_FOR_NOTARIZATION добавлен в качестве одного из разрешенных режимов просмотра.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Если участник, указанный в пути запроса, обладает ролью подписанта с нотариально заверенной подписью, API возвращает конфигурацию подписания ACCEPT_BEFORE_NOTARIZATION в соответствии со всеми остальными конфигурациями подписания для данного документа/участника.
Решенные проблемы
| Проблема | Описание |
| 4308901 | Исправлена ошибка, при которой при передаче документа с использованием аутентификации по телефону появлялось сообщение об ошибке, если у номера телефона для передачи был тот же код страны. |
| 4314113 | Исправлена ошибка, при которой пользователям не удавалось изменить сроки действия по умолчанию при отправке нового документа. |
| 4318558 | Исправлена ошибка, при которой при замене получателя с использованием аутентификации по телефону отображалось сообщение об ошибке «Недействительный идентификатор указанного участника». |
| 4319038 | Исправлена ошибка, при которой у отправителя не отображалась опция «Подтверждение личности внешних получателей» при отправке с помощью рабочего процесса «Пакетная отправка». |
| 4319798 | Исправлена ошибка, при которой при выборе переключателя курсор мог переместиться на другое поле. |
| 4320154 | Исправлена ошибка, при которой шаблон библиотеки не удавалось сохранить в новой группе. |
| 4323013 | Исправлена ошибка, при которой при открытии веб-формы на странице «Управление» появлялась ошибка «Документ еще недоступен или не содержит страницы, которые можно просмотреть». |
| 4323554 | Исправлена ошибка, при которой штампы времени/даты для обновления прав администратора не могли создать две записи с одинаковым значением времени. |
| 4323609 | Исправлена ошибка, при которой при добавлении подписанного документа на страницу «Управление» не запускался веб-перехватчик AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | Исправлена ошибка, при которой пользовательские шаблоны электронных писем не отображали правильное значение имени участника, если документ был отменен. |
| 4326747 | Исправлена ошибка, при которой страница «Пакетная отправка» не выполняла процесс загрузки, пропуская действия добавления и отправки. |
| 4326855 | Исправлена ошибка, при которой участники не могли отклонить утверждение документа. |
| 4327000 | Исправлена ошибка, которая могла привести к сбою учетных данных Smart-Id с ошибкой, сообщающей, что алгоритмы не найдены. |
