Последнее обновление
17 июн. 2026 г.
Заметки к выпуску Adobe Acrobat Sign: 2026
Выпуск Adobe Acrobat Sign 17.0
Рабочее развертывание: 3 февраля 2026 г.
Развертывание GovCloud: 10 февраля 2026 г.
Улучшенные функциональные возможности
- Сгруппированные флажки при авторинге и в шаблонах. Теперь отправители могут создавать группы флажков в современном интерфейсе Запросить подпись и Шаблонах библиотеки, а также средах авторинга с такими правилами проверки, как выбор точно, минимум, максимум или диапазон X из Y. Пакетная отправка, веб-формы и пользовательские рабочие процессы поддерживаются с помощью шаблонов библиотеки. Данное улучшение обеспечивает согласованную логику формы и повышает точность данных в технологических процессах подписания.
- Разрешенные диапазоны IP — расширенное управление доступом через API и мобильные приложения — администраторы теперь могут явно контролировать, применяются ли IP-ограничения к клиентам на основе API, включая мобильные приложения Acrobat Sign и сертифицированные интеграции.
- Поддержка аутентификации для современного электронного подписания — современное электронное подписание теперь поддерживает три метода аутентификации: аутентификацию Acrobat Sign, пароль и двухфакторную аутентификацию по телефону.
- Добавление групп получателей в гибридной маршрутизации для современного запроса подписи. Теперь группы получателей могут быть включены в гибридную маршрутизацию, что позволяет нескольким получателям или группам действовать параллельно в рамках одного этапа маршрутизации. Режимы группы поддерживают выполнение действия либо одним, либо всеми участниками, обеспечивая большую гибкость для сложных технологических процессов утверждения и подписания.
- Копирование соглашений в завершающей стадии, отправленных через интерфейс Запросить подпись. Теперь отправители могут создать новый черновик соглашения, копируя ранее завершенное, отмененное или истекшее соглашение. Все получатели, настройки, файлы и поля форм заполняются автоматически. Скопированное соглашение открывается на странице Создание для быстрого редактирования перед отправкой, что сокращает время настройки, сводит к минимуму ошибки и повышает производительность для повторяющихся рабочих процессов, таких как продление или исправление.
- Отключение ссылки «Загрузить соглашение» для соглашений в работе — администраторы теперь могут удалить ссылку «Загрузить копию» со страниц подтверждения после подписания на уровне учетной записи или группы, предотвращая загрузку соглашений получателями со страницы после подписания.
- Вкладка «Ресурсы» в верхней области навигации. Для администраторов и пользователей в верхней области навигации доступна новая страница Ресурсы, которая обеспечивает прямой доступ к обучающему контенту Acrobat Sign, вебинарам, блогам и видео с обновлениями продукта. Страница упорядочивает учебные пособия по уровню пользователя — начинающий, опытный и администратор — и содержит прямые ссылки на дополнительную справочную документацию.
- Динамическое участие в текущих соглашениях — удаление получателей. Теперь отправители могут удалять получателей из уже запущенных соглашений без отмены или перезапуска транзакции. Когда получатели удаляются, Acrobat Sign автоматически отзывает их доступ, обновляет напоминания, журналы аудита, удаляет назначенные поля и плавно возвращает соглашение в активное состояние подписания. Эта гибкость помогает организациям поддерживать точность в работающих технологических процессах маршрутизации — например, когда подписывающий становится недоступным — сохраняя при этом юридическую целостность, соответствие требованиям и полную историю аудита.
- Требование цифровых подписей для отдельных получателей при настройке соглашения. Теперь отправители могут требовать цифровые подписи для выбранных получателей, обеспечивая более строгие требования к подписанию там, где это необходимо, не влияя на других получателей. Процесс подписания адаптируется автоматически, применяя обязательные поля цифровой подписи и предоставляя проверки личности при их наличии, сокращая ошибки и улучшая соответствие требованиям для регулируемых рабочих процессов.
- Поставщики цифровых удостоверений как методы аутентификации по умолчанию. Теперь администраторы могут выбрать поставщика шлюза для цифрового удостоверения в качестве метода аутентификации подписанта по умолчанию для внутренних и внешних получателей в настройках отправки. Конфигурация автоматически применяется к соглашениям, веб-формам, пакетным отправкам и рабочим процессам, обеспечивая последовательную и соответствующую требованиям проверку получателей. Данное улучшение упрощает настройку аутентификации, применяет организационные политики идентификации и улучшает поддержку для государственных и корпоративных заказчиков, которые полагаются на аутентификацию на основе цифровой идентификации.
- Проверенные поля форм с использованием данных с подтвержденной идентификацией. Теперь авторы форм могут создавать проверенные поля форм, которые автоматически заполняются данными, полученными от поставщика услуг идентификации (например, OneID) во время аутентификации подписанта. Эти поля можно сделать как доступными только для чтения, так и редактируемыми, что обеспечивает точный сбор проверенных данных идентификации и возможность защиты от изменений (например, имя, адрес или номер счета). Это усиливает гарантию идентификации, сокращает ошибки ручного ввода и упрощает соответствие требованиям для технологических процессов, которые требуют проверенных данных подписывающего.
- Группы получателей в файле CSV для пакетной отправки. Теперь отправители могут определять группы получателей непосредственно в файле CSV пакетной отправки, позволяя нескольким получателям действовать на одном этапе маршрутизации. Каждая группа может быть настроена в режиме ОДИН или ВСЕ, что требует выполнения действия либо одним участником, либо всеми участниками до продвижения маршрутизации. Определения групп, проверка и отслеживание аудита обрабатываются для каждой строки CSV, а об ошибках сообщается через загружаемые файлы проверки.
- Шаблон библиотеки — общий доступ для нескольких групп. Современный интерфейс создания шаблона библиотеки теперь поддерживает общий доступ к шаблонам для нескольких групп в рамках одной учетной записи, соответствуя функциональности, ранее доступной в классическом рабочем процессе. Пользователи могут выбрать одну или несколько групп при создании или редактировании шаблона, что обеспечивает согласованное поведение между группами. Данное улучшение исключает переход к классическому интерфейсу, улучшает совместную работу и упрощает управление шаблонами для многогрупповых организаций.
- Вложения файлов для всех получателей, использующих цифровые подписи. Теперь все получатели в процессе цифрового подписания могут прикреплять файлы (не только первый подписант). Новый метод вложения с использованием аннотаций в виде скрепок показывает видимый значок скрепки в документе и остается совместимым с несколькими цифровыми подписями. Каждое вложение добавляется до применения цифровой подписи, сохраняя действительность подписи и обеспечивая четкий визуальный индикатор вложенных файлов. Данное улучшение повышает юридическую целостность, прозрачность и согласованность в технологических процессах электронной подписи и цифровой подписи.
Изменения интерфейса
- Уведомления об отмене соглашений в рабочем процессе — уведомление об отмене обновлено для отражения поведения рабочего процесса.
При отмене соглашения, созданного технологическим процессом, флажок «Уведомить получателей» больше не отображается. Уведомления всегда отправляются на основе настроек технологического процесса. Это изменение корректирует сообщение для отражения данного поведения в запросе подтверждения отмены.
- Улучшения страницы входа. Страница входа в Acrobat Sign теперь обеспечивает более чистый и последовательный интерфейс. Как только вы введете адрес электронной почты, страница автоматически определит тип вашей учетной записи и направит вас к правильному способу входа, устраняя ненужные шаги и устаревшие экраны. Это делает вход в систему быстрее, проще и интуитивнее для всех.
- Новый формат адресов электронной почты для пользователей Acrobat Sign для организаций, которые входят непосредственно через веб-интерфейс. Acrobat Sign теперь ограничивает локальную часть адреса электронной почты (часть до символа «@») 64 символами при редактировании существующего адреса или создании нового пользователя.
Все пользователи, у которых длина локальной части адреса превышает 64 символа, были проверены и определены как неактивные или тестовые идентификаторы пользователей.
- Новый формат адресов электронной почты для пользователей Acrobat Sign для организаций, которые входят непосредственно через веб-интерфейс. Acrobat Sign теперь ограничивает локальную часть адреса электронной почты (часть до символа «@») 64 символами при редактировании существующего адреса или создании нового пользователя.
Обратите внимание, что данный интерфейс предоставляется через постепенное развертывание на основе серверной среды Acrobat Sign.Расписание развертывания публикуется в техническом уведомлении Updated Login experience.
- Включение управления данными неактивных пользователей. Теперь администраторы могут редактировать данные неактивных пользователей непосредственно в интерфейсе администратора и через добавление файлов CSV без повторной активации учетных записей. Сюда относится обновление назначений в группы (для конфигураций как с одной, так и с несколькими группами), управление атрибутом «Пользователь может подписывать документы» и выполнение массового редактирования для соответствия требованиям и ведения записей. Изменение упрощает управление жизненным циклом корпоративных пользователей, сокращает административные накладные расходы и поддерживает более четкую организацию групп и обработку записей в соответствии с GDPR.
Решенные проблемы
| Проблема | Описание |
|---|---|
| 4528600 | Сводка. Настройки проверки полей не работают, когда слой полей формы прикреплен к пользовательскому рабочему процессу. Правила проверки, такие как регулярные выражения или ограничения числового диапазона, удаляются при запуске рабочего процесса, что приводит к принятию полями недопустимых данных. |
| Решение. Правила проверки теперь применяются корректно, когда слои полей формы включены в пользовательские рабочие процессы. Поля сохраняют свое поведение проверки как в классическом, так и в новом интерфейсе создания. От пользователей не требуется никаких действий. | |
| 4528748 | Сводка. При добавлении администраторами участия в группе для недавно синхронизированных пользователей (синхронизация Azure) периодически возникает «Необработанная ошибка». У некоторых новых пользователей в группе groupID установлен как null |
| Решение. Если после создания значение группы пользователя — null, он помещается в группу по умолчанию в учетной записи. | |
| 4529934 | Сводка. В разделе «Управление» > «Веб-формы» функция «Загрузить данные полей формы» продолжает загружаться, и процесс никогда не завершается — особенно для веб-форм с большим количеством отправок. Клиенты Teams без доступа к API не могут экспортировать данные (например, с 1 по 31 мая) для отчетности |
| Решение. В пользовательский интерфейс добавлен постраничный, более быстрый экспорт CSV. Загрузки данных форм завершаются надежно для выбранных диапазонов дат без зависания. | |
| 4532186 | Сводка. В новом интерфейсе авторинга цветовое выделение полей не соответствует поведению в классическом интерфейсе авторинга. Когда задействовано несколько получателей, все поля остаются полностью окрашенными, а не затемняют поля невыбранных получателей. Это затрудняет проверку назначений полей. |
| Решение. Восстановлена визуальная четкость путем затемнения (20% непрозрачности) полей, принадлежащих невыбранным получателям. Это воспроизводит четкость классического режима создания, сохраняя при этом современную систему дизайна. Выделение теперь помогает пользователям легко определить поля текущего выбранного получателя и снижает риск неправильного назначения. | |
| 4534061 | Сводка. Ссылка «Загрузить копию» появляется на странице подтверждения после подписания, даже когда параметр учетной записи или группы настроен на ее отключение. |
| Решение. Добавлена новая настройка для явного отключения параметра «Загрузить» на всех страницах после отправки. Страница после подписания теперь корректно учитывает настройку контроля загрузки, скрывая ссылку «Загрузить копию», когда настройка отключена. | |
| 4536347 | Сводка. В классическом интерфейсе отправители не могли добавить второй файл (или повторить попытку добавления файла) при запуске определенных рабочих процессов, что приводило к блокировке отправки рабочих процессов с несколькими документами. Эта проблема возникала из-за ошибки, связанной с тем, как средство выбора файлов обрабатывает шаблоны, используемые в нескольких группах. |
| Решение. Исправлена обработка используемых в нескольких группах шаблонов, выполняемая средством выбора файлов, чтобы пользователи могли добавлять дополнительные файлы или повторять выбор файлов в классическом интерфейсе без ошибок. | |
| 4537504 | Сводка. Условное значение раскрывающегося списка отсутствовало в подписанном документе, хотя оно было правильно выбрано во время подписания, так как логический элемент видимости выполнял оценку с учетом скрытого зависимого поля и не сохранял отображаемое значение в итоговом подписанном документе PDF. |
| Решение. Обновлен рендеринг условных полей для корректного разрешения зависимостей видимости во время подписания и сохранения выбранного в раскрывающемся списке значения в подписанном документе при выполнении условий. | |
| 4537995 | Сводка. В группах получателей при изменении метода аутентификации для внешних пользователей после сохранения возвращался прежний вариант «По телефону», что не позволяло применить «Одноразовый пароль по эл. почте», из-за ошибки обработки состояния интерфейса, которая перезаписывала выбор пользователя. |
| Решение. Исправлен логический элемент пользовательского интерфейса группы получателей для правильного сохранения и повторного применения выбранного метода аутентификации при действиях сохранения, обеспечивая сохранение выбранного значения вместо сброса до значения по умолчанию. | |
| 4539214 | Сводка. В пользовательских рабочих процессах длинная метка сообщения приводит к наложению текста сообщения и закрытию гиперссылки шаблона сообщения на странице отправки из-за неправильной обработки макета избыточного контента метки. |
| Решение. Обновлен логический элемент макета страницы отправки для корректного ограничения и переноса длинных меток сообщений, чтобы гиперссылка шаблона сообщения оставалась видимой и доступной. | |
| 4539854 | Сводка. Некоторые подписанты перенаправляются из интерфейса подписания при открытии определенных соглашений из-за неправильно сформированного поля ссылки в базовом документе, в котором отсутствует обязательный атрибут имени. |
| Решение. Процесс подписания теперь корректно обрабатывает поля ссылок без имени, назначая действительное имя во время обработки. Это предотвращает ошибки и позволяет подписантам завершать соглашения без перенаправления. | |
| 4539858 | Сводка. На устройствах iOS утверждающие, использующие рукописную клавиатуру на китайском языке, не могут завершить утверждение, поскольку кнопка «Утвердить» остается неактивной после ввода имени, так как страница подписания не распознает рукописный ввод как действительный ввод текста. |
| Решение. Обновлен логический элемент обработки ввода для распознавания рукописного ввода текста на iOS, обеспечивая корректную активацию кнопки «Утвердить» после ввода действительных символов. | |
| 4540392 | Сводка. Для администраторов периодически отображаются ошибки HTTP 400, и группы получателей кажутся отсутствующими в рабочих процессах, хотя группы существуют и доступ правильно настроен. Это происходит из-за превышения заголовками запроса ограничения для размера заголовков платформы, когда пользователи принадлежат к большому количеству групп. |
| Решение. Лимит размера заголовка запроса на стороне сервера был увеличен, поэтому поиск групп получателей больше не завершается неудачей, когда у пользователей много участий в группах. | |
| 4541258 | Сводка. Администраторы могли видеть только первые 100 шаблонов в пользовательском интерфейсе синхронизации производственной и изолированной сред, при этом дополнительные шаблоны отсутствовали в локальных и удаленных списках, так как страница синхронизации загружала ограниченный набор данных, а функция поиска фильтровала только шаблоны, уже загруженные в браузере. |
| Решение. Пользовательский интерфейс синхронизации был обновлен так, что ввод текста в поле поиска загружает все шаблоны для выбранной среды (до 5000), обеспечивая доступность шаблонов за пределами первых 100 для поиска и выбора. | |
| 4541739 | Сводка. Замененным получателям блокировалась возможность цифрового подписания, и они видели сообщение «Соглашение не может быть подписано цифровой подписью, поскольку оно не находится в фазе цифрового подписания» из-за того, что рабочий процесс не смог перевести будущих замененных подписантов в фазу цифрового подписания при наличии полей цифровой подписи. |
| Решение. Рабочий процесс подписания был обновлен для корректного перевода замененных или делегированных получателей в фазу цифрового подписания при наличии полей цифровой подписи, позволяя им подписывать и завершать соглашение. | |
| 4541849 | Сводка. Однострочные текстовые поля с автоматическим размером шрифта, предварительно заполненные многобайтовыми символами, обрезаны в подписанных файлах PDF, а это приводит к обрезанию части текста из-за неправильного размера текста при рендеринге PDF. |
| Решение. Исправлено измерение текста и поведение автоматического изменения размера шрифта для многобайтовых символов, чтобы полное значение помещалось в поле без обрезания. | |
| 4542574 | Сводка. Редактирование шаблона библиотеки позволяло обязательным раскрывающимся полям включать непарные значения, из-за чего кнопка «Подписать» оставалась недоступной во время подписания при выборе этих значений ввиду отсутствия проверки, обеспечивающей правильное формирование пар отображаемых и экспортируемых значений раскрывающегося списка. |
| Решение. Редактирование шаблона теперь обеспечивает проверку раскрывающихся полей, чтобы можно было сохранять только правильно сформированные пары значений, избегая появления непарных записей и обеспечивая отсутствие блокировки подписания при выборе обязательных раскрывающихся списков. | |
| 4542942 | Сводка. В веб-формах обязательные поля, отключенные условной логикой, продолжали отображать обязательную звездочку, вводя подписантов в заблуждение относительно необходимости ввода, поскольку пользовательский интерфейс не обновлял индикаторы обязательности при отключении полей. Отдельная проблема выравнивания подписи на мобильных устройствах была выявлена, но решена в рамках другой области. |
| Решение. Пользовательский интерфейс веб-формы теперь скрывает обязательную звездочку, когда поле отключено условным логическим элементом. Индикаторы обязательного поля точно указывают на то, требуется ввод данных или нет. | |
| 4543157 | Сводка. В представлении «В процессе» на странице «Управление» столбец «Получатели» продолжал показывать имя делегирующей стороны после делегирования роли подписания, хотя активно подписывал другой подписант, поскольку пользовательский интерфейс не обновлял отображаемого получателя для отражения стороны, в отношении которой выполнено делегирование. |
| Решение. Логический элемент страницы «Управление» обновлен, чтобы столбец «Получатели» теперь отображал имя активного пользователя, в отношении которого выполняется делегирование роли подписания, обеспечивая точное отражение в представлении «В процессе» того, кто в данный момент подписывает документ. | |
| 4543253 | Сводка. В классическом интерфейсе рабочего процесса назначенные заверителю поля (подпись, имя, дата), исчезали после сохранения соглашения в состоянии «Черновик», хотя поля существовали во внутренней части. Это происходило, так как логическому элементу рендеринга черновика не удавалось восстановить поля заверителя после сохранения изменений. |
| Решение. Логический элемент рендеринга черновика исправлен для сохранения и отображения всех полей, назначенных заверителю, после сохранения изменений, обеспечивая сохранение в соглашениях, открытых в состоянии «Черновик», той же видимости полей, что и при создании и подписании. | |
| 4543513 | Сводка. Для пользователей была заблокирована возможность отправки соглашений в веб-интерфейсе Sign с ошибкой «Язык недействителен или отсутствует», так как проверка языка неправильно применяла правила языка на уровне API в веб-интерфейсе, когда язык отправляющей группы отличался от унаследованного языка основной группы пользователя. |
| Решение. Проверка языка исправлена, чтобы веб-интерфейс Sign правильно разрешал и принимал действительные комбинации языков группы и пользователя, предотвращая блокировку отправки соглашений в веб-интерфейсе из-за ограничений языка только на уровне API. | |
| 4543592 | Сводка. Некоторые отчеты об аудите показывали «Получатель выполнил аутентификацию с помощью Adobe Acrobat Sign» после «Документ подписан электронно» и «Соглашение завершено», так как события сохранялись с временными метками на уровне секунд, что приводило к неправильному порядку действий аутентификации и подписания, происходящих в одну и ту же секунду. |
| Решение. Ведение журнала событий аудита обновлено для хранения и отображения временных меток с точностью до миллисекунд, что обеспечивает правильную последовательность событий аутентификации, подписания и завершения в отчете об аудите. | |
| 4543617 | Сводка. Создание шаблона из соглашения запускает классический интерфейс вместо нового интерфейса, несмотря на то, что новый интерфейс является интерфейсом по умолчанию, поскольку действие по-прежнему направляется к устаревшему процессу создания. |
| Решение. Действие «Создать шаблон из соглашения» обновлено для открытия в новом интерфейсе, сопоставляя поведение призыва к действию с пользовательским интерфейсом по умолчанию и избегая неожиданных переключений контекста для пользователей. | |
| 4544564 | Сводка. Скрытые поля, добавленные или обновленные через API (visible:false), отображались как видимые в новом интерфейсе электронного подписания. Пользовательский интерфейс подписания игнорировал флаг видимости поля, поэтому получатели могли видеть поля, которые должны оставаться скрытыми. |
| Решение. Обновлен новый пользовательский интерфейс электронного подписания для фильтрации полей, где visible равно false, в логическом элементе рендеринга и навигации, чтобы скрытые поля никогда не отображались и не влияли на поведение страницы. | |
| 4544571 | Сводка. Параметр доставки WhatsApp отсутствовал в настройках отправки, хотя WhatsApp был включен для учетной записи и доступен при отправке соглашений, что вызывало непоследовательное поведение и путаницу у администраторов. |
| Решение. Параметр доставки WhatsApp восстановлен в параметрах отправки везде, где эта функция доступна. Это обеспечивает единое отображение и конфигурацию между настройками администратора и интерфейсом отправки соглашений. | |
| 4545381 | Сводка. Шрифт Roboto отсутствовал в новом интерфейсе запроса подписи, хотя он был доступен в классическом интерфейсе, поскольку новый интерфейс авторинга не включал все шрифты, поддерживаемые в устаревшей версии. |
| Решение. Roboto был добавлен в список шрифтов в новом интерфейсе запроса подписи, что позволило восстановить соответствие шрифтов классическому интерфейсу и выполнять последовательное форматирование при создании соглашений. | |
| 4545484 | Сводка. Некоторые администраторы не могли получить доступ к группам получателей или создать их в разделе «Администрирование > Адресная книга» из-за сбоя запроса сервера, что приводило к ошибке 400 при загрузке данных группы получателей. Проблема блокировала первоначальную настройку групп получателей для затронутых администраторов. |
| Решение. Обработка запросов на сервере исправлена, поэтому поиск и создание групп получателей больше не завершается ошибкой 400. Администраторы теперь могут надежно получать доступ к группам получателей и управлять ими независимо от сети или местоположения. | |
| 4545547 | Сводка. Соглашения, созданные из файлов PDF в AutoCAD, не отправлялись при добавлении поля цифровой подписи и показывали общую ошибку отправки из-за того, что система неправильно обрабатывала поворот страницы при проверке размещения поля цифровой подписи. |
| Решение. Координаты поля цифровой подписи теперь корректируются с учетом повернутых страниц, обеспечивая проверку полей относительно правильных границ страницы, чтобы файлы PDF, созданные в AutoCAD, можно было успешно отправлять с цифровыми подписями. | |
| 4545894 | Сводка. Когда используется группа получателей и поле подписи не размещается вручную, в автоматически созданном блоке подписи отображается текст адреса электронной почты очень маленького размера. Текст становится все меньше по мере добавления получателей в группу. |
| Решение. Автоматически созданный блок подписи теперь правильно отображает адрес электронной почты нормального, удобного для чтения размера, независимо от количества получателей в группе получателей. | |
| 4546085 | Сводка. При использовании функции «Добавить себя» в новом интерфейсе «Запрос подписи» адреса электронной почты, содержащие апостроф, отображаются неправильно. Неправильно сформированный адрес не позволяет отправить соглашение, если адрес электронной почты не введен повторно вручную или не используется классическая отправка. |
| Решение. Адреса электронной почты с апострофами теперь правильно декодируются и отображаются при выборе функции «Добавить себя» в новом интерфейсе «Запрос подписи», что позволяет отправлять соглашения без исправления вручную. | |
| 4546110 | Сводка. В интерфейсе создания нового шаблона добавление поля «Гиперссылка», назначенного конкретному участнику, приводит к сбою сохранения шаблона. То же поле работает при назначении всем участникам или при использовании классического интерфейса. |
| Решение. Поля гиперссылок теперь поддерживают назначения участников-заполнителей в интерфейсе создания нового шаблона, что позволяет правильно сохранять шаблоны при назначении поля конкретному участнику. | |
| 4546257 | Сводка. В изолированной среде соглашения, отправленные через пользовательский API приложения, неправильно показывают кнопку «Назад» на странице создания из-за того, что изолированная среда загружает настройки из приложения, управляемого Adobe, с включенным удобным интерфейсом создания, в отличие от Swagger или производственной среды. |
| Решение. Поведение изолированной среды приведено в соответствие с производственной средой и Swagger путем обеспечения того, чтобы страница создания учитывала предполагаемые настройки приложения, предотвращая появление кнопки «Назад» для соглашений, отправленных через пользовательские API приложений. | |
| 4546547 | Сводка. Веб-формы не могли обновить сторону, скрепляющую подпись, и возвращали неизвестную ошибку из-за того, что в старых записях пользователей отсутствовал необходимый внутренний флажок. Это приводило к обработке нулевого значения при замене стороны, скрепляющей подпись. |
| Решение. Логический элемент обновления стороны, скрепляющей подпись, улучшен обработкой, безопасной для нулевых значений, чтобы веб-формы могли успешно заменять стороны, скрепляющие подпись, даже при отсутствии ожидаемого внутреннего флажка в старых записях пользователей. | |
| 4546553 | Сводка. Пользователи, назначенные в несколько групп, могли создавать шаблоны в группе, где создание шаблонов отключено, когда включен новый интерфейс создания шаблона. Это позволяло обходить ограничения на уровне группы. |
| Решение. Создание шаблонов теперь последовательно применяет разрешения на уровне группы в новом и классическом интерфейсах. Пользователи больше не могут создавать шаблоны в группах, где создание шаблонов отключено, даже если они принадлежат к другим группам с включенным разрешением. | |
| 4547744 | Сводка. Администраторы групп могли назначать права администратора учетной записи пользователям на новой странице управления пользователями. Это превышало область их разрешений и создавало риск нарушения соответствия, позволяя повышение привилегий за пределы роли администратора группы. |
| Решение. Элемент управления выбором роли больше не доступен администраторам групп. Только существующие администраторы учетных записей могут назначать или отзывать права администратора учетной записи, обеспечивая соответствие изменений ролей границам разрешений. | |
| 4547796 | Сводка. Некоторые отправители, использующие интерфейс на польском языке, иногда получают подтверждающее сообщение электронной почты с неправильным текстом «не может предоставить цифровую подпись», хотя соглашение отправляется и подписывается нормально. |
| Решение. Исправлены переводы на польский язык для писем отправителя с подтверждением, чтобы сообщение показывало «отправлено на подпись» вместо неправильного текста «не может предоставить цифровую подпись». | |
| 4548315 | Сводка. Когда отправитель добавлен как получатель копии в новом рабочем процессе отправки, ошибка проверки не отображается, и уведомления по электронной почте не отправляются получателям копии, указанным после отправителя в списке копий. Это отличается от поведения классического рабочего процесса и может привести к тому, что получатели копий пропустят уведомления. |
| Решение. Обновлен логический элемент нового рабочего процесса отправки, чтобы все получатели копий, кроме отправителя, получали уведомления по электронной почте независимо от их позиции в списке копий, приводя поведение в соответствие с ожидаемыми результатами. | |
| 4548583 | Сводка. PDF/A нельзя было включить для группы, если в группе пользователя по умолчанию были включены рукописные подписи, даже когда рукописные подписи были отключены для редактируемой группы. Это блокировало корректную настройку PDF/A для групп, не являющихся группами по умолчанию. |
| Решение. Обновлено подтверждение для проверки настроек рукописных подписей в изменяемой группе, а не в группе пользователя по умолчанию, что позволяет корректно включать PDF/A там, где это разрешено. | |
| 4549337 | Сводка. SMS-уведомления об отмененных соглашениях скрывались, когда была отключена настройка Уведомление об отмене соглашения по электронной почте. Это не позволяло клиентам, отключившим уведомления по электронной почте, отправлять обязательные SMS-оповещения об отмене. |
| Решение. Уведомления об отмене по SMS и WhatsApp отделены от настройки электронной почты путем включения специального контроля уведомлений, что позволяет доставлять SMS об отмененных соглашениях даже при отключенных уведомлениях по электронной почте. | |
| 4549472 | Сводка. В Acrobat Sign for Government пользователи не могли создавать многоразовые шаблоны с помощью нового интерфейса для создания шаблонов. После добавления документа рабочий процесс останавливался на пустом экране, блокируя создание шаблона. |
| Решение. Восстановлена отсутствующая зависимость авторинга, необходимая для нового интерфейса для создания шаблонов в государственных средах, что позволяет корректно загружать экран авторинга и успешно создавать шаблоны. | |
| 4549862 | Сводка. Когда целевая страница настроена на новый интерфейс запроса подписи, настроенное предупреждающее сообщение при входе не отображается после авторизации. Это не позволяет организациям показывать критически важные уведомления о техническом обслуживании или сбоях, когда пользователи попадают непосредственно на страницу отправки. |
| Решение. Восстановлена поддержка отображения предупреждающего сообщения при входе в новом интерфейсе запроса подписи. Когда пользователи попадают на страницу отправки после входа, настроенное предупреждающее сообщение теперь появляется как уведомление, соответствуя предыдущему поведению и ожиданиям клиентов. | |
| 4550175 | Сводка. При нажатии клавиши Enter после ввода номера телефона для аутентификации по телефону в рабочем процессе выполняется преждевременная отправка формы и появляется системная ошибка, что приводит к прерыванию рабочего процесса из-за отправки формы вместо ожидания явного подтверждения. |
| Решение. Обновлено диалоговое окно получателя для предотвращения отправки формы при нажатии клавиши Enter в полях аутентификации по телефону. Это позволяет пользователям оставаться в диалоговом окне и нажимать «Продолжить», чтобы избегать случайного прерывания рабочего процесса. | |
| 4550302 | Сводка. В сообщениях электронной почты с запросом подписи и напоминаниями на немецком языке использовались разные формы обращения в одном сообщении — неформальная форма «Du» (Ты) и формальная «Sie» (Вы). Это приводило к путанице и формированию непрофессионального стиля общения. |
| Решение. Обновлены переводы сообщений электронной почты на немецкий язык для использования единой формы обращения во всем шаблоне, что обеспечивает использование одного языка во всех письмах с запросом подписи и напоминаниями. | |
| 4550556 | Сводка. Соглашения, содержащие большие архитектурные планы в формате PDF, не удавалось отправить при добавлении полей цифровой подписи, что возвращало ошибку во время авторинга из-за обработки поворота страниц и размера при размещении цифровой подписи. |
| Решение. Обновлена обработка полей цифровой подписи для корректной работы с повернутыми страницами большого формата, что позволяет успешно отправлять соглашения с архитектурными планами с применением цифровых подписей. | |
| 4550579 | Сводка. Когда соглашение было завершено путем удаления последних оставшихся получателей в состоянии «На пересмотре», система не создавала событие AGREEMENT_WORKFLOW_COMPLETED, поэтому уведомление веб-перехватчика не отправлялось, что нарушало рабочие процессы, которые полагаются на это событие для определения завершения работы над соглашением. |
| Решение. Обновлена обработка событий, чтобы соглашения, завершенные путем удаления получателя в состоянии «На пересмотре», теперь создавали соответствующие события завершения, обеспечивая корректный запуск веб-перехватчиков AGREEMENT_WORKFLOW_COMPLETED. | |
| 4550998 | Сводка. Предварительно заполненные флажки отображались как установленные при создании, но были сняты для подписантов, поскольку значения флажков сохранялись как непустые текстовые строки вместо явных состояний «ДА/НЕТ», что приводило к тому, что процесс подписания рассматривал их как снятые. |
| Решение. Обновлена обработка значений флажков, чтобы любое непустое предварительно заполненное значение интерпретировалось как установленное, а пустые или отсутствующие значения — как снятые, обеспечивая согласованность состояний флажков для подписантов. |
Выпуск Adobe Acrobat Sign 17.0.1
Рабочее развертывание: 17 марта 2026 г.
Развертывание GovCloud: 19 марта 2026 г.
Улучшенные функциональные возможности
- Создать копию — расширенные точки доступа, более быстрое повторное использование соглашений.
Функция «Создать копию» теперь доступна непосредственно из фильтров В процессе и Ожидает вас на странице Управление, а также со страницы подтверждения после отправки. Эти дополнительные точки входа упрощают повторное использование соглашений на большем количестве этапов жизненного цикла отправки, снижая необходимость начинать с нуля.
Примечание. В этом выпуске административные элементы управления для отключения этой функции будут удалены из меню администратора, что сделает функцию Создать копию стандартной возможностью, доступной всем подходящим пользователям.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: учетная запись и группа; включено по умолчанию.
Изменения интерфейса
- Видимость истечения срока действия ключа интеграции — даты истечения срока теперь отображаются на вкладке Токены доступа
Вкладка Токены доступа в меню Личные настройки отображает дату истечения срока действия для каждого ключа интеграции. Это обеспечивает пользователям и администраторам более четкую видимость возраста ключей и времени их замены, упрощая мониторинг существующих ключей и предотвращая неожиданные перебои, когда ключ достигает конца своего 10-летнего периода действия.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания:Acrobat Sign Solutions | Диапазон настроек: API
REST Обновления API/вебхуков
Обновления API и вебхуков для этого выпуска можно найти в документации Acrobat Sign API.
- Персонализированное отображение электронной почты OEM 2.0 — более четкая идентификация отправителя и получателя во встроенных интерфейсах и корректная доставка электронной почты.
Для партнеров OEM 2.0, использующих встроенные рабочие процессы, Acrobat Sign теперь может отображать персонализированный адрес электронной почты пользователя вместо зарегистрированного партнером адреса в ключевых элементах интерфейса и уведомлениях. Соглашения, очереди, такие как «Ожидает вас» и электронные письма «Просмотр и подпись», последовательно отражают персонализированную идентичность, сохраняя при этом зарегистрированный адрес электронной почты внутренне для аутентификации и прав доступа. Это повышает ясность для отправителей и подписантов и предотвращает отправку писем на недоставляемые зарегистрированные адреса.
Доступные среды: изолированная программная, коммерческая | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: API - OEM 2.0 Partners; только по запросу
- Уведомление веб-перехватчика о сбоях доставки SMS — видимость неудачных отправок SMS в режиме реального времени, автоматическое исправление и согласование с возвратами электронных писем.
Acrobat Sign теперь генерирует новое событие webhook AGREEMENT_PHONE_BOUNCED, когда соглашение, отправленное через SMS, не может быть доставлено из-за проблем, таких как неверные номера телефонов, отклонение оператором или заблокированные линии. Это позволяет заказчикам обнаруживать сбои доставки SMS практически в реальном времени и автоматически запускать последующие действия, такие как исправление номеров телефонов, повторная попытка доставки или открытие обращений в службу поддержки, устраняя слепые зоны и сокращая задержки в технологических процессах подписания, ориентированных на мобильные устройства.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: API
- Полезные данные веб-перехватчиков — добавлено условное поле участника extendedStatus для динамического обновления участия, что улучшает видимость состояний участников.
Уведомления webhook теперь включают поле extendedStatus в каждом объекте участника (memberInfos[]), когда отправитель изменяет соглашение в процессе выполнения, используя динамическое участие. Это поле предоставляет дополнительные сведения о жизненном цикле участника, оставляя существующее поле статуса неизменным для обратной совместимости.
Значения status (без изменений): ACTIVE, REPLACED.
Значения extendedStatus: ACTIVE, REPLACED, REMOVED, COMPLETED.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: API
Решенные проблемы
| Проблема | Описание |
|---|---|
| 4543515 | Сводка. Событие отклонения электронного письма веб-перехватчика может быть неправильно создано для действительного подписанта после того, как подписант подпишет документ и соглашение перейдет к следующему шагу. Это может произойти, когда у делегата в той же группе подписания есть недействительный адрес электронной почты, и отправитель заменяет первоначальную делегирующую сторону. В таких случаях система может неправильно приписать событие отклонения «подписано от имени...» действительному подписанту вместо участника, чья электронная почта фактически отклоняется. |
| Решение. Логика атрибуции событий исправлена, поэтому события отклонения электронных писем связываются только с участником, чье электронное письмо фактически отклоняется. Событие отклонения больше не создается для действительного подписанта, который уже завершил подписание, и уведомления веб-перехватчика теперь отражают правильного участника и адрес электронной почты. | |
| 4544548 | Сводка. Ключи интеграции, созданные через веб-интерфейс, могут истечь через 10 лет, хотя на странице создания указано, что ключ обеспечивает «постоянный доступ». Когда ключ достигает 10-летнего срока службы, вызовы API начинают возвращать ошибку истекшего токена, что может неожиданно нарушить существующие интеграции. |
| Решение. Сообщения пользовательского интерфейса обновлены, чтобы удалить формулировку «постоянный доступ» и четко отображать дату истечения срока действия ключей интеграции. Обновленный текст теперь указывает, что ключ сохраняет доступ до даты истечения срока действия или до его ручной отмены, обеспечивая прозрачность относительно 10-летнего срока службы по умолчанию. | |
| 4546301 | Сводка. Доставка событий веб-перехватчика может быть задержана на несколько часов для соглашений с очень большими документами, даже когда создание соглашения завершается и ранние этапы обработки, по-видимому, завершаются в течение нескольких минут. Во время окна задержки служба доставки веб-перехватчика может многократно получать ответы DOCUMENT_NOT_AVAILABLE при попытке получить документы соглашения, и событие веб-перехватчика может не быть доставлено до тех пор, пока служба не прекратит повторные попытки или документы не станут доступными. |
| Решение. Обработка доступности документов исправлена, поэтому большие соглашения надежно переходят в состояние, когда документы можно получить без расширенных ответов DOCUMENT_NOT_AVAILABLE. В результате события веб-перехватчика доставляются без многочасовых задержек, вызванных повторными попытками получения документов против недоступных документов. | |
| 4547823 | Сводка. Личное сообщение получателя может не отображаться для некоторых подписантов, когда соглашение создается в состоянии «Создание» через API, а затем редактируется из интерфейса «Управление». В этом сценарии пользовательский интерфейс может показывать значение личного сообщения как «Нет» или пустое, хотя данные соглашения включают правильное значение личного сообщения. Такое поведение появляется в сценариях общей учетной записи, когда пользователь переключается в учетную запись другого пользователя для редактирования черновика, и это может затрагивать только определенных получателей, в то время как другие отображаются правильно. |
| Решение. Добавлена проверка для получения активного контекста общего доступа и возврата личного сообщения для авторизованных пользователей с общим доступом. В результате значение личного сообщения теперь отображается правильно при просмотре или отправке созданного через API черновика из потока «Создание». | |
| 4548274 | Сводка. Дата изменения для шаблонов библиотеки может не обновляться после редактирования и сохранения шаблона в новом интерфейсе шаблонов. Пользователи могут видеть недавно добавленные или обновленные поля в шаблоне, но дата изменения остается неизменной в пользовательском интерфейсе «Управление» и в административных представлениях, что создает впечатление, что шаблон не был недавно изменен. Это происходит потому, что новый интерфейс обновляет поля формы через путь, который также не обновляет временную метку изменения шаблона. |
| Решение. Поведение обновления даты изменения было согласовано в новом интерфейсе шаблонов и связанных операциях API. Путь кода, который сохраняет изменения полей шаблона, теперь также обновляет дату изменения шаблона, чтобы она отражала фактическое время последнего изменения. | |
| 4548564 | Сводка. Подписи и поля форм могут отображаться невидимыми в подписанном файле PDF, если они размещены поверх уже существующих комментариев типа «Штамп» в исходном документе. В затронутых шаблонах комментарии типа «Штамп» перекрывают или скрывают интерактивные поля во время обработки, что приводит к тому, что завершенные подписи и другие поля скрываются в окончательном подписанном документе. |
| Решение. Обработка комментариев типа «Штамп» обновлена для безопасной обработки и сведения уже существующих комментариев типа «Штамп», чтобы они больше не скрывали поля форм или подписи. Поля, размещенные поверх областей со штампами, теперь остаются видимыми на протяжении всего процесса подписания и в полностью выполненном файле PDF. | |
| 4549103 | Сводка. Событие отклонения электронного письма может быть зарегистрировано повторно для ранее неправильного получателя после того, как отправитель заменит этого получателя действительным адресом электронной почты. В некоторых случаях журнал аудита может показать второе событие отклонения для старого электронного письма, а статус соглашения может отражать «электронное письмо отклонено», даже если новый получатель успешно получает, просматривает или подписывает соглашение. Такое поведение может создать впечатление, что соглашение все еще направлено как на старый, так и на новый адрес электронной почты. |
| Решение. Технологический процесс замены подписанта был обновлен, чтобы предотвратить отправку дополнительных уведомлений по электронной почте замененному получателю, чье электронное письмо уже была отклонено. Система теперь проверяет историю предыдущих отклонений перед отправкой уведомлений, связанных с заменой, гарантируя, что новые события отклонения не генерируются для старого адреса электронной почты после замены. | |
| 4549306 | Сводка. Пользователи, чьи адреса электронной почты содержат определенные специальные символы (например, апостроф), могут быть не в состоянии войти в систему с общих публичных страниц входа adobesign.com или echosign.com. После ввода адреса электронной почты и нажатия в поле пароля страница может перезагрузиться и очистить поле электронной почты вместо перенаправления пользователя на правильную страницу входа shard или SSO. Это не позволяет затронутым пользователям завершить аутентификацию и блокирует интеграции, которые полагаются на публичную конечную точку входа. |
| Решение. Логика разрешения входа shard исправлена для правильной обработки и декодирования адресов электронной почты, содержащих специальные символы, перед построением URL-адреса перенаправления между shard. Пользователи с затронутыми форматами электронной почты теперь правильно перенаправляются на назначенную им страницу входа shard и SSO без очистки поля электронной почты. | |
| 4549331 | Сводка. Подписи и другие поля форм могут отображаться отсутствующими или невидимыми в подписанном файле PDF, когда включены определенные функции обработки документов, а исходный файл PDF содержит недействительные координаты границ страницы (например, неправильные значения CropBox или MediaBox). В этом сценарии поля, которые полагаются на координаты страницы, могут отображаться за пределами видимой области страницы, что делает завершенные подписи отсутствующими, даже если подписание завершается успешно. |
| Решение. Обработка границ страницы PDF исправлена для безопасной нормализации недействительных значений CropBox и MediaBox во время обработки документа. В результате размещение подписей и полей форм теперь выравнивается по видимой области страницы, а подписанные файлы PDF отображают подписи как ожидается. | |
| 4550367 | Сводка. Создание веб-формы может завершиться сбоем с общей ошибкой «Ошибка сервера» после выбора «Предварительный просмотр и добавление полей», когда аутентификация подписанта по умолчанию для группы отправителя установлена на «Телефон», а у учетной записи нет доступной квоты для аутентификации по телефону, даже если аутентификация подписанта веб-формы установлена на метод, не связанный с телефоном (например, Adobe Sign). В результате все пользователи в затронутой учетной записи могут быть заблокированы от создания веб-форм для всех документов. |
| Решение. Создание веб-форм теперь оценивает квоту только для метода аутентификации, фактически настроенного для подписанта веб-формы, и больше не применяет проверки квоты аутентификации по телефону исключительно на основе настройки аутентификации по умолчанию для группы. Это предотвращает ложные ошибки исчерпания квоты и позволяет создавать веб-формы в обычном режиме. | |
| 4551011 | Сводка. Когда отправитель загружает определенные отсканированные файлы PDF, добавляет поля подписи и отправляет соглашение, подписанный файл PDF может не отображать видимых подписей после завершения подписания. Такое поведение может происходить, когда загруженный файл PDF содержит недействительные метаданные границ страницы (координаты MediaBox и CropBox отображаются в обратном порядке), что может привести к тому, что слои внешнего вида подписи и других полей отображаются за пределами видимой области страницы. |
| Решение. Обработка границ страницы PDF обновлена для правильной обработки файлов PDF с недействительными или обращенными значениями координат MediaBox и CropBox, чтобы контент внешнего вида подписи и полей форм отображался в пределах видимой области страницы и оставался видимым в окончательном подписанном файле PDF. | |
| 4551427 | Сводка. Некоторые получатели, у которых уже есть активные правильно настроенные учетные записи, получают соглашения как получатели «псевдопользователи», поэтому соглашение не отображается в их обычном представлении «Управление». Это происходит, когда адреса электронной почты получателей содержат начальные или конечные пробелы, что не позволяет системе сопоставить адрес электронной почты с существующим пользователем и приводит к созданию записи псевдопользователя. |
| Решение. Анализ электронной почты и поиск пользователей обновлены для нормализации адресов электронной почты получателей (удаление начальных и конечных пробелов) перед их сопоставлением с существующими пользователями. В результате соглашения, адресованные существующим пользователям, привязываются к зарегистрированной учетной записи вместо создания получателя-псевдопользователя, даже если адрес электронной почты был введен с пробелами (в полезных данных API и списках получателей технологического процесса). | |
| 4553198 | Сводка. Когда соглашение включает по крайней мере одного получателя, настроенного для доставки SMS, и по крайней мере одного получателя, настроенного только для доставки по электронной почте, отмена соглашения через API не отправляет SMS-уведомление об отмене получателю SMS. Соглашение успешно отменяется, и уведомления по электронной почте доставляются, но получатели SMS не получают сообщение об отмене. |
| Решение. Рабочий процесс отмены исправлен, чтобы обеспечить отправку SMS-уведомлений об отмене всем получателям, настроенным для доставки SMS, при отмене соглашения, независимо от способов доставки других получателей. | |
| 4554463 | Сводка. Когда соглашения включают клонированные переключатели, которые имеют одинаковое имя поля в объединенных документах, только один экземпляр выбранного параметра остается выбранным в окончательном подписанном файле PDF. Хотя поля визуально отображаются как флажки, они реализованы как переключатели. После подписания выбранное значение не распространяется последовательно на все клонированные экземпляры, что приводит к неправильному или неполному сопоставлению ожидаемого выбора. |
| Решение. Логика обработки полей формы исправлена, чтобы клонированные переключатели сохраняли и распространяли выбранное значение экспорта, а не внутреннее значение индекса. Это гарантирует, что все клонированные экземпляры одного и того же поля переключателя отражают правильный выбор в подписанном файле PDF. | |
| 4554593 | Сводка. Некоторые партнерские интеграции, которые используют устаревшие конечные точки OAuth для обновления токенов доступа, начали завершаться с ошибками HTTP 401. Служба отклонила запросы на обновление токенов с ошибкой, указывающей, что приложению не разрешено использовать устаревшие конечные точки OAuth и вместо этого должно использовать конечные точки OAuth v2. Это заблокировало клиентам аутентификацию Acrobat Sign через партнерские приложения, даже для интеграций, которые ранее работали. |
| Решение. Служба аутентификации исправлена, чтобы партнерские приложения, настроенные для использования устаревшего потока OAuth, могли снова успешно обновлять токены, вместо того чтобы неправильно принуждаться к конечным точкам OAuth v2. | |
| 4554614 | Сводка. Когда подписант использует современный интерфейс электронной подписи для соглашения, которое требует аутентификации подписанта и настроено на требование принятия условий использования перед подписанием, нажатие «Нажмите для подписания» запускает 5-секундное перенаправление к классическому интерфейсу подписания. Сообщение о перенаправлении предупреждает, что подписи и инициалы, введенные в современном подписании, будут очищены, заставляя подписанта повторно вводить их и фактически подписывать дважды. |
| Решение. Поток обновления токена подписания исправлен, чтобы когда подписант принимает условия использования перед подписанием, перевыпущенный токен подписания сохранял детали аутентификации подписанта. Это предотвращает сбой аутентификации на финальном этапе подписания и устраняет принудительный переход от современного подписания к классическому интерфейсу. | |
| 4555656 | Сводка. При определенных временных условиях переход состояния соглашения может казаться успешным, но фактически не изменяет состояние соглашения. Когда уведомление веб-перехватчика получено до завершения обработки на сервере, последующие вызовы API могут использовать устаревшие данные о статусе соглашения. В этом окне определенные методы перехода состояния возвращают HTTP 200 OK, даже если соглашение не находится в допустимом состоянии для запрошенного перехода. В результате технологические процессы автоматизации могут предполагать, что переход прошел успешно, в то время как соглашение остается в исходном состоянии. |
| Решение. Логика перехода состояния соглашения обновлена для обеспечения строгой проверки перед применением перехода. Если соглашение находится в недопустимом состоянии, API теперь возвращает четкий ответ об ошибке вместо молчаливого возврата успеха. Это гарантирует, что недопустимые переходы явно отклоняются, позволяет вызывающим системам повторять попытки соответствующим образом и предотвращает сохранение соглашений в непредусмотренном состоянии без видимости. |
Выпуск Adobe Acrobat Sign 17.1
Рабочее развертывание: 05 мая 2026 г.
Развертывание GovCloud: 12 мая 2026 г.
Улучшенные функциональные возможности
- Личное подписание — включение сеансов организованного подписания в веб-приложении
Личное подписание позволяет отправителю назначить внутреннего организатора, который проводит сеанс личного подписания с помощью веб-браузера. Организатор запускает контролируемый сеанс подписания со страницы «Управление» или из уведомления по электронной почте, временно передает устройство подписанту для выполнения необходимых действий и восстанавливает контроль после завершения. Создание и завершение сеанса записываются в журнал аудита, и подписывающие могут дополнительно предоставить адрес электронной почты для получения копии соглашения.
- Массовая цифровая подпись на странице «Управление» — применение цифровой подписи к нескольким соглашениям с помощью одной авторизации
Подписанты могут выбрать несколько соглашений в представлении Ожидает ваших действий и применить цифровые подписи как массовое действие, используя одну авторизацию подписания. Это сокращает повторяющиеся шаги подписания для рабочих процессов с большим объемом, сохраняя при этом существующие средства безопасности, аутентификации и аудита облачного подписания. Массовое подписание требует от подписывающих лиц просмотра или пропуска всех соглашений перед выполнением массового действия.
- Отправка только внутренним получателям — ограничение отправки соглашений получателям в рамках одной учетной записи Acrobat Sign.
Настройка «Отправка только внутренним получателям» не позволяет пользователям отправлять соглашения получателям за пределами их учетной записи Acrobat Sign. При включении соглашения могут отправляться только получателям, чьи идентификаторы учетных записей совпадают с идентификатором отправителя. Этот контроль поддерживает требования внутренней безопасности и предотвращает внешний обмен соглашениями.
- Отчетность по использованию телефонных транзакций — расширенная отчетность с видимостью на уровне группы и доступом к запланированным отчетам
Отчетность по телефонным транзакциям теперь обеспечивает видимость приобретенных количеств, дат начала квот и подробного потребления по транзакциям SMS и WhatsApp. Заказчики могут отслеживать использование на уровне группы и получать доступ к запланированным отчетам CSV через единый интерфейс отчетности, что обеспечивает более точное бюджетирование, внутреннее распределение и проактивный мониторинг для предотвращения сбоев в обслуживании при достижении лимитов транзакций.
Отчетность теперь создается через запланированные отчеты в интерфейсе отчетности, с доступом к API для получения последних результатов отчета.
Новая конечная точка: POST /api/rest/v6/reportDownload
Эта конечная точка принимает scheduleId и возвращает адрес URL загрузки для самого недавно созданного CSV-отчета, связанного с этим расписанием.
Изменения интерфейса
- Отображение подписи в отчетах аудита — регистрирует метод ввода подписи, используемый каждым подписантом, повышая видимость соответствия требованиям и сокращая ручную проверку
Отчеты аудита теперь записывают метод ввода подписи, используемый при применении подписи подписантом. Для каждого события ESIGNED журнал аудита определяет, использовал ли подписант набранную подпись, нарисованную подпись, добавленное изображение, рисование на мобильном устройстве или съемку изображения подписи. Это улучшение позволяет командам по соответствию и операциям проверять методы подписи непосредственно из отчета аудита, уменьшая неопределенность и предотвращая ненужные отклонения соглашений.
Типы внешнего вида подписи:- Текст: подписант вводит свое имя и выбирает стиль подписи на основе шрифта.
- Рисование: подписант рисует свою подпись с помощью мыши или трекпада на ПК.
- Изображение: подписант добавляет файл изображения подписи с ПК.
- Мобильное рисование: подписант рисует свою подпись касанием на мобильном устройстве.
- Мобильное изображение: подписант добавляет или фотографирует изображение подписи на мобильном устройстве.
- Сохраненные подписи для URL-адресов подписания API — позволяет использовать сохраненные подписи профиля во время подписания на основе API
Позволяет зарегистрированным пользователям применять свои сохраненные подписи профиля при подписании соглашений через URL-адреса подписания, созданные API (GET /agreements/{agreementId}/signingUrls). Сохраненные подписи отображаются для внутренних подписантов и для внешних подписантов, которые проходят аутентификацию с помощью одноразового пароля по электронной почте или Adobe ID. Эта возможность упрощает рабочие процессы подписания для интеграций с серверной частью, сохраняя при этом средства безопасности на уровне учетной записи.
Включается Adobe на основе отдельной учетной записи после проверки безопасности.
- Управление личной адресной книгой в современном интерфейсе — пользователи могут удалять сохраненные адреса электронной почты непосредственно из своей личной адресной книги в современном интерфейсе «Запросить подпись» , упрощая поддержание точности и актуальности личных списков получателей.
- Окно истечения срока действия соглашения — расширенный период истечения срока по умолчанию до 365 дней
Максимальный срок завершения соглашений был увеличен со 180 дней до 365 дней. Когда включено истечение срока действия документа, соглашениям теперь автоматически назначается срок действия 365 дней, который нельзя удалить. Данное изменение гарантирует, что все соглашения имеют определенный жизненный цикл, улучшает долгосрочное отслеживание и соответствие требованиям, и снижает риск того, что соглашения останутся открытыми бесконечно, при этом по-прежнему позволяя пользователям устанавливать более ранние сроки при необходимости.
- Обновленная Главная страница — улучшает доступ к рабочим процессам, выделяет важные действия
Главная страница обновлена, чтобы упростить создание соглашений, отслеживание активности и доступ к ключевым функциям, включая возможность копировать недавно отправленные соглашения, просматривать плитки действий в более удобном порядке, быстро определять элементы в состояниях Выполняется и Ожидает ваших действий, а также использовать упрощенный баннер Новые возможности, который уменьшает визуальный беспорядок, помогает пользователям быстрее переключаться, сокращает количество пропущенных соглашений и обеспечивает более продуманную работу с Главной страницей.
Новая Главная страница будет развернута в течение 10 дней после выпуска. Обратитесь к техническому уведомлению для получения расписания.
- Улучшения пробной версии — в пробную версию Sign добавлен новый процесс адаптации.
Пробная версия Sign теперь включает улучшенный процесс подключения и функции, представленные в недавних платных выпусках.
- Новый конструктор пользовательских технологических процессов становится по умолчанию — продвижение современного конструктора, удаление пользовательских элементов управления переключением, сохранение гибкости администратора
Новый интерфейс «Конструктор пользовательских технологических процессов» теперь является по умолчанию для всех учетных записей.Пользователи больше не видят ссылки переключения для возврата к классическому дизайнеру, в то время как администраторы сохраняют возможность повторно включить доступ к предыдущему интерфейсу при необходимости. Это обновление способствует переходу к современному интерфейсу проектирования технологических процессов, сохраняя при этом административное управление в переходный период.
REST Обновления API/вебхуков
Обновления API и вебхуков для этого выпуска можно найти в документации Acrobat Sign API.
- Управление ключами mTLS для веб-перехватчиков — добавление опции ключа, созданного Acrobat Sign, включение технологического процесса подписания сертификатов, улучшение соответствия требованиям безопасности
Разработчики теперь могут выбирать способ управления закрытыми ключами для аутентификации mTLS веб-перехватчиков в Acrobat Sign. В дополнение к существующей модели, где заказчики создают и загружают свой собственный закрытый ключ и сертификат, Acrobat Sign теперь может создать закрытый ключ и запрос на подписание сертификата (CSR). Заказчики могут использовать CSR для получения сертификата от своего центра сертификации и загрузить его для завершения конфигурации. Эта опция повышает безопасность, сохраняя закрытые ключи в Acrobat Sign, обеспечивая при этом совместимость с существующим поведением webhook mTLS.
- Инициализация цифровой идентификации через параметр login_hint — позволяет отправителям API инициализировать аутентификацию цифровой идентификации с идентификатором входа, специфичным для получателя.
Несколько конечных точек v6 REST API /agreements теперь поддерживают параметр loginHint, который позволяет отправителям API инициализировать аутентификацию Digital Identity Gateway с использованием известного идентификатора входа, такого как адрес электронной почты или номер пользователя. Поставщик идентификации контролирует пользовательский интерфейс, но идентификатор обычно предварительно заполняет экран входа для усиления рабочих процессов аутентификации высокого доверия и снижения риска подмены личности. Идентификатор отображается в замаскированном формате на целевой странице Digital Identity Gateway и в отчете об аудите для сохранения отслеживаемости при защите конфиденциальных данных.
Следующие конечные точки были обновлены с добавлением параметра loginHint:- POST /agreements
- PUT /agreements/{agreementId}
- PUT /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}
- GET /agreements/{agreementId}/members/participantSets/{participantSetId}
- GET /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}/members
- Улучшения границ идентификации и доверия OEM 2.0 — функция «Показывать персонализированный/OEM адрес электронной почты везде» теперь отдает приоритет пользователям, созданным тем же партнером, и автоматически создает получателя, когда соответствие не найдено
Когда включена функция показа персонализированного/OEM адреса электронной почты везде, разрешение участников соглашения отдает приоритет пользователям, созданным тем же партнером, и автоматически создает запись получателя, когда соответствующий пользователь не существует, обеспечивая согласованную обработку идентификации в учетных записях.
Кроме того, при включенной функции Показывать персонализированный/OEM адрес электронной почты везде отчеты аудита указывают, является ли отправитель пользователем, созданным партнером, или личной учетной записью, а процессы подписания направляют пользователей к переключению учетных записей, когда идентичные адреса электронной почты существуют в разных типах учетных записей, снижая путаницу и предотвращая нежелательный доступ.
Решенные проблемы
| Проблема | Описание |
|---|---|
| 4520028 | Сводка. Столбец «Группа» на странице «Управление» отображал неправильные или непоследовательные значения, когда пользователи принадлежали к нескольким группам. Изменение основной группы пользователя приводило к тому, что соглашения показывали неправильную группу, включая последнюю выбранную основную группу или несколько групп, вместо группы, из которой соглашение было первоначально отправлено. |
| Решение. Обновлен логический элемент страницы «Управление» для использования группы отправки соглашения (agreement_group_id) вместо текущей основной группы пользователя при рендеринге столбца «Группа». | |
| 4532690 | Сводка. Пользователи не могли редактировать черновики соглашений, созданных из пользовательских рабочих процессов, когда были включены оба параметра: «Включить отправку соглашений только с помощью рабочего процесса» и «Включить новую функцию "Настраиваемый рабочий процесс отправки"». Система неправильно блокировала доступ к странице создания при редактировании существующего черновика, рассматривая это как новое действие отправки вместо редактирования черновика. |
| Решение. Обновлен логический элемент страницы создания для обнаружения сценариев редактирования черновиков и обхода проверки ограничений рабочего процесса, что позволяет пользователям редактировать существующие черновики соглашений, созданные из пользовательских рабочих процессов. | |
| 4536764 | Сводка. Отправка соглашений через пользовательский рабочий процесс привела к ошибке сервера из-за сбоя обработки определенных PDF-шаблонов. Ошибка была вызвана недействительными или отсутствующими данными внешнего вида комментариев в одном или нескольких исходных документах, что вызвало исключение рендеринга во время предварительного заполнения. Проблема не воспроизводилась последовательно и не могла быть воспроизведена вне затронутых технологических процессов. |
| Решение. Улучшена обработка исключений рендеринга в слое обработки PDF. | |
| 4537197 | Сводка. При использовании нового интерфейса «Пакетная отправка» с именами получателей, введенными вручную, второе поле имени удалялось во время подписания из-за неправильной обработки обязательных данных имени получателя в документах. |
| Решение. Обновлен логический элемент обработки документов для правильного сохранения всех полей имени получателя при отправке соглашений в пакетном режиме. | |
| 4538172 | Сводка. Копирование рабочих процессов, включающих группы получателей, завершалось сбоем во время синхронизации песочницы, отображалось сообщение «Ошибка выполнения запроса» из-за недопустимых ссылок на группы получателей. Рабочий процесс использовал идентификаторы групп получателей, специфичные для среды, которые не переносятся между средами, что приводило к сбою проверки во время синхронизации. |
| Решение. Обновлена обработка синхронизации песочницы для корректной проверки и обработки ссылок на группы получателей во время операций копирования рабочего процесса, предотвращая сбои при наличии групп получателей в обеих средах. | |
| 4538251 | Сводка. В новом интерфейсе «Пакетная отправка» поля со сведениями о полном имени подписывающей стороны и адресе электронной почты не отображались во время подписания или в итоговом документе, когда исходный файл содержал существующие поля AcroForm. Проблема была вызвана неправильной обработкой данных полей слияния при объединении полей информации о подписанте с уже существующими полями формы, что приводило к тому, что поля не отображались в дочерних соглашениях |
| Решение. Обновлен логический элемент объединения и обработки полей формы для корректного применения полей информации о подписывающей стороне в документах, содержащих существующие поля AcroForm. | |
| 4545485 | Сводка. Создание соглашения периодически завершалось сбоем, когда при создании миниатюр появлялись плохо сформированные поля формы PDF. Сбой был вызван исходными документами, содержащими поля формы без действительных имен и недопустимые вложенные структуры полей, что вызывало ошибки обработки во время генерации PDF. |
| Решение. Добавлена проверка и проверки на пустые значения во время обработки файлов PDF для обработки неправильно сформированных полей формы и предотвращения сбоев во время создания миниатюр и соглашений. | |
| 4545814 | Сводка. Поля смещены, и текстовые теги остаются видимыми при обработке документов альбомной ориентации, созданных из рабочих процессов на основе XDP. Неправильные вычисления координат в альбомных макетах вызывают неправильное размещение полей и препятствуют правильному анализу и удалению текстовых тегов. |
| Решение. Обновлен логический элемент рендеринга полей для корректного вычисления и размещения полей формы в документах альбомной ориентации, обеспечивая правильное выравнивание и удаление текстовых тегов во время обработки. | |
| 4545978 | Сводка. Символы с диакритическими знаками в именах подписывающих сторон отображаются неправильно в видимом блоке подписи при использовании локального цифрового подписания. Проблема возникает из-за того, что шрифт по умолчанию, встроенный в документ, не имеет правильной кодировки для западноевропейских символов, что вызывает неправильную замену символов во время отображения внешнего вида подписи. |
| Решение. Обновлена конфигурация встроенного шрифта для включения корректной кодировки символов с диакритическими знаками, обеспечивая правильное отображение имен подписывающих сторон во внешнем виде подписи | |
| 4547100 | Сводка. Непоследовательное выполнение рендеринга клонированных многострочных текстовых полей в подписанном файле PDF. В многострочных клонированных полях отсутствует словарь внешнего вида по умолчанию, что приводит к тому, что клонированные поля отображают меньше строк, чем исходное поле, даже когда оба поля используют одинаковый размер и настройки. |
| Решение. Добавлен словарь внешнего вида по умолчанию к многострочным клонированным полям, чтобы рендеринг клонированных и исходных полей выполнялся одинаково в подписанных документах. | |
| 4548305 | Сводка. Контрольный список подготовки показывает, что «Готовность запроса BAA для HIPAA» в состоянии ожидания, даже когда HIPAA включен. Логика оценки контрольного списка неправильно рассматривает унаследованные настройки, связанные с HIPAA, как неполные, что приводит к тому, что статус задачи остается ожидающим, несмотря на то, что функция включена. |
| Решение. Обновлен логический элемент оценки контрольного списка для корректной интерпретации настроек, связанных с HIPAA, включая унаследованные значения, чтобы задача подготовки отражала завершенное состояние, когда HIPAA включен. | |
| 4550731 | Сводка. При подписании документов с помощью функции «Заполнить и подписать» между подчеркиванием подписи и временной меткой появляется большой промежуток. Проблема возникает, когда поле подписи недостаточно широкое для размещения отображаемого содержимого подписи, что вызывает неправильные интервалы во внешнем виде подписи |
| Решение. Обновлен рендеринг подписи для соблюдения определенных размеров поля и соответствующей настройки интервалов, что уменьшает промежуток между подчеркиванием и временной меткой. | |
| 4550906 | Сводка. Ссылка «Изменить пароль» указывает на недействительный URL-адрес для определенных пользователей, что вызывает ошибку браузера. Проблема возникает, когда приложение считывает устаревшую конечную точку из конфигурации вместо правильного URL-адреса, что приводит к непоследовательному поведению в разных средах. |
| Решение. Обновлена настроенная конечная точка изменения пароля для использования правильного URL-адреса во всех затронутых средах. | |
| 4550992 | Сводка. Редактирование определенных шаблонов в новом интерфейсе перенаправляет на страницу создания шаблона вместо открытия шаблона в режиме редактирования. Проблема возникает из-за того, что система определяет интерфейс на основе настроек владельца шаблона, а не настроек текущего пользователя, что приводит к неправильной маршрутизации при редактировании общих шаблонов. |
| Решение. Обновлен логический элемент редактирования шаблонов для использования настроек интерфейса текущего пользователя вместо настроек владельца шаблона, обеспечивая открытие шаблонов в правильном режиме редактирования. | |
| 4551756 | Сводка. Электронные письма с запросами на утверждение отображают неразрешенные переменные шаблона в поле получателя, что приводит к неправильному форматированию электронного письма. Проблема возникает из-за сбоя в логике отображения шаблона электронной почты при создании уведомлений о конфликте прав. |
| Решение. Обновлен рендеринг шаблона электронного письма для корректного разрешения и заполнения полей получателя, обеспечивая отображение действительных адресов электронной почты в письмах с запросами на утверждение. | |
| 4551768 | Сводка. Подписывающие стороны сталкиваются с необработанной ошибкой при доступе к соглашениям или их завершении из-за сбоя в обработке внешнего вида полей формы. Неправильно сформированный объект внешнего вида вызывает исключение ClassCastException во время создания документа, что приводит к сбою отображения соглашения. |
| Решение. Обновлен логический элемент обработки полей формы для проверки типов объектов внешнего вида перед отправкой, предотвращая исключения и обеспечивая корректный рендеринг соглашений для подписания. | |
| 4552272 | Сводка. Отмененные или прерванные соглашения отображаются в разделе «Ожидает ваших действий» на странице управления. Проблема возникает, когда событие перезапуска технологического процесса не очищает должным образом данные о статусе участника, оставляя устаревшие данные видимости и индексации, которые отображают соглашение в неправильных представлениях |
| Решение. Обновлен логический элемент обработки перезапуска и индексации рабочего процесса для корректной очистки предыдущих данных о статусе участника и обеспечения отображения соглашений только в их правильном состоянии. | |
| 4553158 | Сводка. В средах с языками RTL на iOS панель подписи не реагирует корректно при рисовании подписи. Панель прокручивается вместо захвата ввода, что требует от пользователей ручной прокрутки для рисования и применения подписи, что препятствует нормальному поведению подписания при включенном новом интерфейсе подписи получателя. |
| Решение. Обновлена обработка взаимодействия с панелью подписи для макетов RTL на iOS для корректного захвата рисунка без непреднамеренной прокрутки, обеспечивая нормальное создание и применение подписи. | |
| 4553583 | Сводка. Рабочие процессы разрешают адреса электронной почты с начальными или конечными пробелами, что приводит к тихому сбою соглашений при отправке в новом интерфейсе. Система не проверяет и не нормализует ввод, и не отображается сообщение об ошибке для указания проблемы. |
| Решение. Обновлена обработка ввода для автоматического удаления пробелов из адресов электронной почты и предотвращения сохранения недействительных значений, а также добавлена обработка для существующих рабочих процессов, чтобы соглашения могли быть отправлены. | |
| 4553676 | Сводка. Гиперссылки отображаются неправильно в представлении «Управление», где название соглашения добавляется к URL-адресу, что приводит к неработающим ссылкам. Проблема возникает из-за неправильного анализа URL-адреса при рендеринге гиперссылок в интерфейсе «Управление». |
| Решение. Обновлен рендеринг гиперссылок для использования правильного анализа URL-адреса, что обеспечивает неизменность ссылок и их корректную работу во всех представлениях. | |
| 4555021 | Сводка. Проверка OTP завершается ошибкой «истек срок действия», даже когда код вводится немедленно. Проблема возникает из-за состояния гонки в потоке аутентификации, где несколько событий отправки приводят к преждевременной недействительности OTP. |
| Решение. Обновлен поток проверки OTP для правильной обработки дублированных или быстрых событий отправки, предотвращая преждевременное истечение срока действия и обеспечивая успешную обработку действительных записей OTP. | |
| 4555028 | Сводка. При удалении следующего получателя, которому требуется поставить подпись, может появиться системная ошибка, а соглашение останется в состоянии ожидания пересмотра. Проблема возникает, когда у получателя есть активное напоминание, которое препятствует успешному завершению обновления соглашения. |
| Решение. Обновлен логический элемент удаления получателя для обработки случаев, когда у следующей подписывающей стороны есть активные напоминания, что позволяет завершить обновление соглашения без ошибок. | |
| 4555319 | Сводка. При предварительном просмотре формы создатели веб-форм видят только параметры, которые позволяют ввести или нарисовать подпись, в то время как подписывающие стороны видят все доступные параметры (ввести подпись, нарисовать, использовать изображение, подписать на мобильном устройстве). Проблема возникает из-за того, что режим предварительного просмотра неправильно применяет включенные настройки ввода подписи, когда создатель не выступает в роли подписанта. |
| Решение. Обновлено поведение предварительного просмотра веб-формы для применения полного набора включенных типов ввода подписи, что позволяет создателям видеть те же параметры подписи, что и подписывающим сторонам. | |
| 4555345 | Сводка. Соглашения с несколькими получателями «Подписант с заверителем» не открываются в предварительном просмотре из черновика, и отображается ошибка «Невозможно изменить ParticipantSetsInfo». Проблема возникает из-за неправильного логического элемента систематизации участников и свидетелей в пользовательских рабочих процессах, что препятствует переходу соглашения обратно в состояние авторинга. |
| Решение. Обновлен логический элемент систематизации участников и свидетелей в пользовательских рабочих процессах для корректного расчета порядка выполнения, позволяя соглашениям возвращаться в состояние авторинга и продолжать работу в обычном режиме. | |
| 4555615 | Сводка. Полезные данные событий веб-перехватчика для делегированных и замененных получателей не включают поле privateMessage. Проблема возникает из-за того, что личное сообщение не передается в состояние получателя, используемое для создания полезных данных веб-перехватчика, что приводит к отсутствию данных для затронутых событий. |
| Решение. Обновлена обработка данных участников, чтобы обеспечить включение личных сообщений в полезные данные веб-перехватчика для делегированных и замененных получателей. | |
| 4555687 | Сводка. Соглашения могут быть автоматически отменены и перемещены в скрытое состояние после подписания из-за сбоя проверки видимости документа. Когда участник делегируется или заменяется, сопоставление видимости документа передается неправильно, что вызывает несоответствие между назначенными полями и видимыми документами, что может привести к автоматической отмене. |
| Решение. Логический элемент делегирования и замены теперь правильно клонирует сопоставления видимости документов для новых участников, предотвращая сбои проверки и непреднамеренную отмену соглашения. | |
| 4556516 | Сводка. Поля формы могут игнорировать настроенные размеры шрифта, а их рендеринг может выполняться непоследовательно в созданных соглашениях. Проблема возникает в многострочных полях, когда механизм обработки документов корректирует размер шрифта для предотвращения обрезания текста, переопределяя настройки фиксированного размера шрифта. |
| Решение. Обновлено поведение рендеринга шрифта, чтобы многострочные поля учитывали настройки фиксированного кегля, выравнивая поведение с ожидаемым результатом и предотвращая непреднамеренные корректировки размера. | |
| 4556967 | Сводка. Выбранные флажки могут отображаться невыбранными в окончательном подписанном файле PDF для веб-форм. Проблема возникает при использовании определенных скрытых значений (например, «no», «false», «0», «off», «unchecked»), которые могут привести к неправильной интерпретации состояний флажков во время обработки документа при включенном Gibson. |
| Решение. Обновлена обработка флажков для правильной интерпретации скрытых значений и сохранения выбранных состояний в финальном документе, обеспечивая согласованность между подписываемым и подписанным файлом PDF. | |
| 4557222 | Сводка. Поля ссылок из шаблонов полей могут исчезать на странице авторинга при использовании в рамках рабочего процесса. Проблема возникает из-за того, что поля ссылок не включаются в данные полей формы соглашения, возвращаемые во время авторинга на основе технологического процесса, что приводит к отсутствию полей. |
| Решение. Обновлена обработка полей формы для включения полей ссылок из шаблонов полей во время обработки рабочего процесса, обеспечивая их правильное объединение и отображение на странице авторинга. | |
| 4557272 | Сводка. Поле «Дата подписания» может не отображаться в финальном подписанном файле PDF. Проблема возникает при сбое отображения текстового поля во время обработки документа, что препятствует отображению поля даты в выходном документе. |
| Решение. Обновлен рендеринг текстовых полей для правильной обработки пустых значений или значений null, обеспечивая постоянное отображение поля «Дата подписания» в подписанных документах. | |
| 4557282 | Сводка. Поля переключателей в веб-формах могут отображать неожиданное значение подсказки («object Object») при создании с использованием нового интерфейса шаблонов. Проблема возникает из-за неправильной обработки пустых значений всплывающих подсказок, что приводит к отображению данных-заполнителей вместо их подавления. |
| Решение. Обновлен логический элемент обработки подсказок для правильного игнорирования пустых значений, предотвращая появление нежелательного текста-заполнителя в веб-формах. | |
| 4557589 | Сводка. Предварительно заполненные поля флажков могут отображаться неотмеченными при отправке соглашения на подпись. Проблема возникает, когда для флажков или переключателей определены дублирующиеся или конфликтующие скрытые значения, что может привести к неправильной интерпретации выбранного состояния во время обработки документа. |
| Решение. Обновлена обработка значений полей для правильной обработки скрытых значений и сохранения предварительно заполненных значений, обеспечивая согласованность состояний флажков в созданных и отправленных соглашениях. | |
| 4557672 | Сводка. Новый интерфейс запроса подписи может отображать общую ошибку («Предоставленный запрос недействителен») при отправке соглашения, не указывая конкретное поле, вызывающее сбой. Это может произойти, когда данные получателя (например, формат номера телефона) не проходят проверку, но ошибка не отображается пользователю четко. |
| Решение. Обновлена обработка проверки для предоставления конкретных сообщений об ошибках на уровне полей, помогая пользователям выявлять и исправлять недопустимые данные перед отправкой соглашения. | |
| 4557680 | Сводка. Сопоставления флажков или переключателей могут не работать в некоторых соглашениях при объединении нескольких документов, в результате чего ожидаемые значения не применяются. Проблема возникает, когда значения по умолчанию не точно соответствуют определенным экспортируемым значениям, что может привести к тому, что поля будут рассматриваться как отдельные группы и нарушится поведение сопоставления. |
| Решение. Обновлен логический элемент сопоставления полей, чтобы игнорировать несоответствующие значения по умолчанию и правильно связывать поля в документах, что улучшает согласованность поведения флажков и переключателей. | |
| 4557902 | Сводка. Может появляться лишний пробел между подписью и отметкой даты и времени в соглашениях, где используется инструмент «Заполнить и подписать». Проблема возникает из-за неправильного расчета интервалов в хорошо отформатированных подписях, что приводит к несогласованному макету по сравнению с другими процессами подписания. |
| Решение. Обновлен расчет макета подписи для правильного размещения подписи и отметки времени, устраняя нежелательные интервалы и обеспечивая согласованное форматирование. | |
| 4557947 | Сводка. Поля флажков могут отображаться неотмеченными в финальном подписанном файле PDF при использовании шаблонов библиотеки, даже если подписывающая сторона устанавливала флажки. Проблема может возникнуть, когда поля флажков неправильно настроены или используют определенные скрытые значения, что приводит к неправильной интерпретации выбранного состояния во время обработки документа. |
| Решение. Обновлена обработка флажков для правильной интерпретации скрытых значений и сохранения выбранных состояний, обеспечивая сохранение установленных флажков в подписанном документе. | |
| 4558295 | Сводка. Значения обязательных переключателей могут отсутствовать в окончательном подписанном файле PDF. Проблема может возникнуть, когда значения полей содержат специальные символы (например, кавычки или символы), которые не обрабатываются должным образом, что приводит к тому, что выбранное значение не отображается в выводе документа. |
| Решение. Обновлена обработка значений полей для корректной работы со специальными символами, что обеспечивает сохранение и отображение выбранных значений в подписанном файле PDF. | |
| 4558307 | Сводка. Поля формы могут игнорировать настроенные размеры шрифта, а их рендеринг может выполняться непоследовательно в созданных соглашениях. Проблема может возникнуть в многострочных полях, когда механизм обработки документов корректирует размер шрифта для предотвращения обрезания текста, переопределяя настройки фиксированного размера шрифта. |
| Решение. Обновлено поведение рендеринга шрифта, чтобы многострочные поля учитывали настройки фиксированного кегля, предотвращая нежелательное изменение размера и обеспечивая последовательный результат. | |
| 4558554 | Сводка. Подписанты могут завершать соглашения без взаимодействия с блоком подписи. Проблема может возникнуть в учетных записях с поддержкой Gibson, когда для блока подписи рендеринг выполняется неправильно или блок подписи не применяется во время подписания, что позволяет завершить процесс только с полем подписи. |
| Решение. Обновлен логический элемент рендеринга и проверки подписи для обеспечения правильного и обязательного отображения блоков подписи перед завершением соглашения. | |
| 4558725 | Сводка. Для текстовых тегов может не выполняться рендеринг или преобразование в поля форм во время предварительного просмотра. Проблема может возникать, когда добавленный файл PDF содержит неподдерживаемые или недопустимые элементы (например, null-аннотации или существующие заполняемые поля), которые препятствуют успешному завершению обработки текстовых тегов. |
| Решение. Обновлена обработка текстовых тегов для более надежной работы с файлами PDF, содержащими недопустимые или неподдерживаемые аннотации, что позволяет создавать поля как ожидается во время предварительного просмотра. | |
| 4559285 | Сводка. Аутентификация по телефону может не работать для определенных регионов при выборе кода страны в новом интерфейсе запроса подписи. Проблема возникает, когда в интерфейсе отображается неполный или неправильный код страны (например, «+1» вместо «+1246» для Барбадоса), что может вызвать ошибки проверки при отправке соглашения. |
| Решение. Обновлена обработка кодов стран для использования правильных полных телефонных кодов, что обеспечивает корректную проверку и обработку номеров телефонов в новом интерфейсе. | |
| 4560119 | Сводка. Текст в полях форм может отображаться неровно или перекрываться в созданных соглашениях. Проблема может возникнуть в многострочных текстовых полях, когда механизм обработки документов вносит различия в отображении, приводящие к смещению макета по сравнению с представлением при создании. |
| Решение. Обновлен рендеринг текста и обработка макета для многострочных полей для улучшения выравнивания и предотвращения перекрытия, обеспечивая более единообразное отображение между документами на этапе авторинга и уже завершенными документами. | |
| 4562058 | Сводка. Имя получателя может оставаться неизменным при выборе другого адреса электронной почты в адресной книге на странице отправки. Проблема возникает из-за того, что поле имени не обновляется при выборе нового контакта, что приводит к несоответствию между отображаемым именем и выбранным адресом электронной почты. |
| Решение. Обновлено поведение выбора получателя, чтобы поле имени всегда обновлялось при выборе нового контакта, обеспечивая синхронизацию имени и электронной почты. | |
| 4566339 | Сводка. Некорректные состояния флажков могут появляться при обработке статических XFA в формате PDF с некорректными значениями полей. Проблема может возникнуть, когда неподдерживаемые или недопустимые данные XFA (например, строковые значения в числовых полях) обрабатываются непоследовательно, особенно в средах с поддержкой Gibson, где значения флажков по умолчанию могут быть неправильно интерпретированы. |
| Решение. Обновлена обработка XFA в конвейере обработки документов для более последовательной нормализации или игнорирования неправильных значений, предотвращая неправильные состояния флажков и обеспечивая единообразное поведение в разных средах. | |
| 4567278 | Сводка. Текстовые поля только для чтения могут не отображаться на странице подписания при включенных динамических участниках. Проблема возникает из-за несогласованности отображения полей во время разрешения участников, что может привести к исключению нередактируемых полей из представления подписывающего. |
| Решение. Обновлен логический элемент рендеринга полей для динамических участников, чтобы обеспечить единое включение и отображение полей только для чтения во время подписания. | |
| 4568023 | Сводка. Параметры ввода подписи с помощью добавления изображения или ввода на мобильном устройстве могут не отображаться в веб-формах во время подписания. Проблема может возникнуть из-за непоследовательной загрузки параметров подписи в потоке ввода веб-формы, где определенные методы подписания не отображаются до перезагрузки сеанса или доступа через альтернативный путь. |
| Решение. Обновлена инициализация подписания веб-форм для последовательной загрузки всех включенных параметров подписи, обеспечивая доступность методов ввода подписи с помощью добавления изображения или ввода на мобильном устройстве во всех точках входа. |
Выпуск Adobe Acrobat Sign 17.1.1
Рабочее развертывание: 16 июня 2026 г.
Развертывание GovCloud: 18 июня 2026 г.
Улучшенные функциональные возможности
- Фильтр получателей в отчетности — добавление фильтрации по получателям в отчеты и экспорт данных.
Добавьте фильтр Получатели в Отчеты в современном интерфейсе для отчетов по Соглашениям, Транзакциям и Экспорту данных. Администраторы могут фильтровать по электронной почте получателя, чтобы получить все соглашения, которые включают указанного получателя, независимо от роли или порядка подписания. Фильтр поддерживает автозавершение и множественный выбор, что соответствует существующему фильтру отправителя, и применяется как к визуальным отчетам, так и к экспорту CSV.
Изменения интерфейса
- Поддержка биофармацевтической отрасли (CFR) в современном интерфейсе электронного подписания — добавляет фиксацию причины подписания и принудительную повторную аутентификацию во время подписания
Настройки подписания для биофармацевтической отрасли, включая фиксацию причины подписания и повторную аутентификацию во время подписания, теперь поддерживаются в современном интерфейсе электронного подписания. Соглашения, использующие эти настройки, больше не возвращаются к классическому интерфейсу подписания. Никаких действий клиента или изменения настроек администратора не требуется.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: поддержка настроек Bio Pharma в современном интерфейсе электронного подписания включена по умолчанию.
REST Обновления API/вебхуков
Обновления API и вебхуков для этого выпуска можно найти в документации Acrobat Sign API.
- Подавление уведомлений о соглашениях через API — добавьте детальный контроль над сообщениями получателей
Используя REST v6 POST /agreements API, контролируйте, какие уведомления отправляются при создании соглашений, подавляя определенные типы электронных писем для участников, копий или отправителя. Это уменьшает количество ненужных писем и поддерживает более чистые, контролируемые процессы подписания в интегрированных рабочих процессах.
Доступные среды: изолированная программная, коммерческая, государственная | Доступные уровни обслуживания: Acrobat Sign Solutions | Диапазон настроек: REST v6 API
Решенные проблемы
| Проблема | Описание |
|---|---|
| 4545881 | Сводка. Подписанты, использующие функцию «Загрузить и подписать» в Acrobat, могли получать ошибку «Adobe Acrobat Sign не может распознать» после добавления файла PDF с цифровой подписью, когда сертификат цифрового удостоверения не содержал ожидаемого значения имени подписанта, например commonName, givenName или pseudonym. Соглашение не могло быть завершено, несмотря на то что подписанный файл PDF добавлен. |
| Решение. Adobe Acrobat Sign теперь обрабатывает сертификаты цифрового удостоверения с отсутствующими значениями имени подписанта без выдачи ошибки в процессе проверки загрузки. Подписание может быть успешно завершено, хотя имя подписанта может не отображаться, если сертификат его не содержит. | |
| 4547132 | Сводка. Когда соглашения создавались через API-запрос POST /agreements, а для securityOption установлено значение null, внешним получателям мог назначаться метод аутентификации «Нет», даже если настройки учетной записи требовали одноразового пароля по электронной почте в качестве метода аутентификации по умолчанию. Аутентификация внутренних получателей применялась корректно, но аутентификация внешних получателей — нет. |
| Решение. Acrobat Sign теперь корректно применяет настроенный в учетной записи метод аутентификации по умолчанию, когда созданные через API соглашения включают получателей со значением securityOption равным null. Внешние получатели теперь получают требуемый метод аутентификации по умолчанию вместо «Нет». | |
| 4553171 | Сводка. В учетных записях разработчиков, использующих новый интерфейс создания шаблонов, многоразовые шаблоны могли показывать префикс [DEMO USE ONLY] на странице управления, но префикс был недоступен при редактировании названия шаблона. Пользователи не могли удалить префикс из существующего названия шаблона, если не заменяли полное название или не переключались на классический интерфейс шаблонов. |
| Решение. Новый интерфейс создания шаблонов теперь поддерживает синхронизацию названия шаблона для многократного использования и названия соглашения и поведения водяного знака в учетной записи разработчика. Пользователи могут редактировать полное название шаблона, включая префикс [DEMO USE ONLY], не переключаясь на классический интерфейс | |
| 4556731 | Сводка. После того как отправитель заменил получателя собой, а затем делегировал соглашение другому получателю, соглашение возвращалось в статус «В процессе», но параметр «Добавить подписанный документ» оставался недоступным. Это не позволяло отправителю добавить подписанную копию для подходящих соглашений в процессе после такой последовательности делегирования. |
| Решение. Acrobat Sign теперь корректно восстанавливает опцию «Загрузить подписанный документ» после замены получателя отправителем с последующим делегированием другому получателю, когда соглашение подходит для добавления подписанного документа. | |
| 4557576 | Сводка. Когда блок подписи назначался группе получателей с несколькими участниками, значение электронной почты в блоке подписи могло обрезаться вместо четкого отображения. Это могло затруднить чтение информации о группе получателей до того, как участник группы завершал подписание. |
| Решение. Acrobat Sign теперь отображает информацию об адресах электронной почты группы получателей в блоках подписи без резкого обрезания видимого текста. Длинные значения электронной почты группы получателей обрабатываются так, чтобы отображаемая информация оставалась читаемой в блоке подписи. | |
| 4561898 | Сводка. Некоторые получатели могли столкнуться с ошибкой сервера после аутентификации или при завершении подписания соглашений, использующих определенные PDF-документы. Сбой был вызван проблемой обработки данных структуры PDF при создании подписанного документа, что не позволяло подписывающему завершить соглашение. |
| Решение. Acrobat Sign теперь более надежно обрабатывает данные структуры PDF во время подписания и создания документов. Исправление предотвращает блокировку завершения из-за конфликтов дерева структуры, позволяя получателям успешно проходить аутентификацию, подписывать и завершать затронутые соглашения. | |
| 4562041 | Сводка. Некоторые уведомления веб-перехватчиков могли задерживаться или не публиковаться, когда Acrobat Sign получал внутреннюю ошибку сервера при создании полезной нагрузки веб-перехватчика. Для затронутой учетной записи несколько событий 19 марта 2026 года оказались под воздействием, включая AGREEMENT_WORKFLOW_COMPLETED и другие события соглашений, что задержало последующие рабочие процессы клиента |
| Решение. Acrobat Sign теперь более надежно обрабатывает сбои создания полезной нагрузки веб-перехватчиков, поэтому неудачные внутренние ответы не кэшируются таким образом, который блокирует или задерживает доставку событий. Исправление было проверено с помощью регрессионного тестирования и предназначено для предотвращения задержки затронутых событий веб-перехватчиков из-за того же пути сбоя генерации полезной нагрузки. | |
| 4562458 | Сводка. Получатели могли получить ошибку «Указан недопустимый ID соглашения» при открытии URL подписания для соглашений, отправленных неактивным пользователям в заявленных доменах учетных записей, когда использовалась аутентификация получателя, такая как одноразовый пароль по электронной почте или аутентификация по паролю. Поток подписания создавал одноразового ожидающего пользователя для продолжения процесса подписания, но запрос информации о подписании мог читать устаревшие данные соглашения, которые не включали вновь созданное участие, блокируя доступ до повторного создания ссылки подписания или обновления данных. |
| Решение. Acrobat Sign теперь получает текущие данные участия в соглашении при открытии аутентифицированных URL-адресов подписания в этом рабочем процессе. Это предотвращает возникновение ошибок недопустимого ID соглашения из-за устаревших кэшированных данных соглашения и позволяет получателям успешно завершить аутентификацию и получить доступ к странице электронного подписания. | |
| 4566894 | Сводка. Некоторые истекшие соглашения, созданные из нескольких шаблонов, нельзя было скопировать со страницы управления. Когда пользователи выбирали «Создать копию», операция копирования завершалась неудачей с сообщением «Не удалось скопировать соглашение». Повторите попытку позже», поскольку проверка доступа к шаблону завершилась неудачей при копировании соглашений с более чем одним шаблоном. |
| Решение. Acrobat Sign теперь правильно проверяет информацию о шаблоне при копировании соглашений, созданных из нескольких шаблонов. Затронутые соглашения теперь можно копировать без вызова ошибки серверной сессии. | |
| 4568666 | Сводка. Уведомления веб-перехватчиков могли периодически не отправляться для соглашений, включающих участников-свидетелей без назначенного ID пользователя. Основное событие соглашения было создано, но генерация полезной нагрузки веб-перехватчиков могла завершиться неудачей при обработке данных участников в непредсказуемом порядке, что приводило к недоставке некоторых ожидаемых событий веб-перехватчиков после AGREEMENT_CREATED. |
| Решение. Acrobat Sign теперь безопасно обрабатывает данные участников веб-перехватчиков с отсутствующими идентификаторами пользователей во время генерации полезных данных. Это предотвращает сбои полезной нагрузки веб-перехватчиков из-за участников-заполнителей свидетелей и позволяет стабильно доставлять ожидаемые события веб-перехватчиков соглашения. | |
| 4571682 | Сводка. В некоторых соглашениях, где Power Automate изменил группы получателей перед очередью последующего заполнителя формы, поля только для чтения могли не отображаться для этого заполнителя формы. После того как заполнитель формы завершал редактирование своих полей, эти поля также могли исчезнуть из соглашения, хотя поля по-прежнему были правильно назначены и помечены как видимые через API. |
| Решение. Acrobat Sign теперь сохраняет видимость полей для последующих групп получателей после изменения состава группы получателей. Поля только для чтения, блоки подписи, выбранные значения в выпадающих списках и другие заполненные значения полей остаются доступными для последующих получателей и в загруженном PDF для исправленных сценариев. | |
| 4571845 | Сводка. Личное подписание может завершиться ошибкой сервера, если адрес электронной почты подписывающего лично совпадает с существующей учетной записью пользователя на другом сегменте, что препятствует завершению соглашения. |
| Решение. Обновлена обработка подписантов с личной подписью для корректного создания и использования временной записи подписанта, предотвращения конфликтов пользователей между сегментами и успешного завершения сеанса подписания. | |
| 4573019 | Сводка. Порядок групп получателей может быть рассчитан неправильно после динамических обновлений участников, которые удаляют смешанный набор получателей и групп получателей, что приводит к отображению неправильного порядка маршрутизации для оставшейся группы. |
| Решение. Обновлен пересчет порядка участников, чтобы группы получателей сохраняли правильный порядок после сложных динамических удалений участников, включая случаи, когда группа сокращается до одного оставшегося участника. | |
| 4572455 | Сводка. Некоторые подписанты могли видеть сообщение «Необработанная ошибка» или «Что-то пошло не так» после завершения подписания, несмотря на то что подпись была применена и соглашение перешло к следующему получателю. Проблема возникала при включенных динамических участниках, когда процесс подписания пытался подготовить документ для следующего подписанта, но не мог найти ожидаемую версию подписанного документа. |
| Решение. Acrobat Sign теперь проверяет правильную версию подписанного документа при подготовке соглашения для следующего подписанта. Это предотвращает отображение ошибки в процессе подписания после успешной подписи при включенных динамических участниках. |
