Problem-Schlüssel
Zuletzt aktualisiert am
2. April 2026
Adobe Sign-Versionshinweise: 2021
Adobe Sign: März 2021
Verbesserte Funktionalität
Webformulare für mehrere Unterzeichner
Konten, die Webformulare verwenden, haben jetzt die Möglichkeit, mehrere externe Empfänger im Signaturprozess zuzulassen.
Weitere Empfänger werden vom ersten Unterzeichner definiert:
Verwende Bibliotheksvorlagen, um Webformulare zu erstellen
Autoren können jetzt vorhandene Bibliotheksvorlagen verwenden, um neue Webformulare zu erstellen.Die Datei wird mit intakten Feldern importiert:
„Liquid Mode" in Adobe Sign für mobile Anzeige
Der Liquid Mode ist eine optionale Funktion zum Generieren einer responsiven Ansicht, sodass Sie die Anzeige Ihrer Dokumente je nach Gerätetyp des Unterzeichners verbessern können.
Das signierte Dokument wird in der standardmäßigen „PDF"-Version gespeichert, während die Empfänger den Liquid Mode auf Mobiltelefonen sehen können und zur Anzeige des ursprünglichen Dokuments wechseln können.
Du kannst jetzt dein HTML-Dokument hochladen und eine Liquid Mode-Ansicht für Mobiltelefone generieren.
Sperre den Name-Wert für bekannte Benutzer beim Signieren über Bild- oder gezeichnete Signaturmethoden
Es gibt Situationen, in denen es nicht erwünscht ist, dass der Name des Empfängers während des Signierprozesses geändert werden kann. Aus Respekt vor Namenspräferenzen des Unterzeichners hat Adobe Sign in dieser Hinsicht bislang Flexibilität geboten. In richtlinienkonformen Umgebungen ist diese Flexibilität jedoch nicht akzeptabel. Aus diesem Grund gibt es eine neue Option, mit der die Namen der Empfänger der Vereinbarung gesperrt werden können.
Administratoren haben jetzt die Möglichkeit, Empfänger mit bekannten Name-Werten daran zu hindern, diese Werte zu ändern, wenn sie eine gezeichnete oder Bild-Signatur anwenden.
Situationen, in denen der Namenswert bekannt ist:
- Wenn der Name an einen Empfänger mit einer Adobe Sign-ID gesendet wird
- Wenn der Name über die API gesendet wird
- Wenn die Unterzeichnerinformationen-Felder während des Ausfüllens des Formulars ausgefüllt werden
- Wenn der Name während des Abschlusses einer KBA- oder amtlicher Lichtbildausweis-Authentifizierung gesperrt wird
Verbesserungen der wissensbasierten Authentifizierung
Steuerelemente wurden zur KBA-Methode der Identitätsauthentifizierung hinzugefügt, die vom Absender verlangen können, einen Name für den Empfänger anzugeben, und dieser Name-Wert wird während des Signaturprozesses gesperrt.
Optionen für erweiterte E-Mail-Sicherheit
Es stehen zwei neue Optionen zur Verbesserung der E-Mail-Sicherheit zur Verfügung. Beide Einstellungen sind standardmäßig aktiviert:
- Link in E-Mails einfügen, um die signierte Vereinbarung anzuzeigen
- Bild der ersten Seite der Vereinbarung in E-Mails einfügen
- Ist standardmäßig aktiviert.
- Wenn aktiviert, ist ein Bild der ersten Seite der Vereinbarung in einigen E-Mail-Verteilungen sichtbar
v6 REST API Updates
Standard-Header in jeder V6 REST-API-Anfrage
Standardmäßig verfügt jede v6 REST-API-Anfrage jetzt über die folgenden Standard-Header:
/AGREEMENTS
Alle /agreements-Endpunkte, die einen agreement id -Pfad haben, geben jetzt einen 404 AGREEMENT_DESTROYED-Fehlercode zurück, wenn die Vereinbarung über GDPR-Tools gelöscht wurde.
Bibliotheksvorlagen
PUT /libraryDocuments/{libraryDocumentId} - Erweitert um das neue Feld ownerId
Anmerkung
Nur die v6 REST API ist betroffen.
Jeder v6 REST API-Aufruf, der diese Header nicht enthält, wird das Fehlen explizit dokumentieren.
- GET /libraryDocuments - Erweitert um das neue Feld ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Erweitert um die neuen Felder: ownerId, ownerEmail und ownerName
Neue Felder im LibraryDocumentInfo-Objekt:
Felder mit aktualisiertem Verhalten:
WEBFORMULARE (/WIDGETS)
- POST /widgets - Die Verwendung einer libraryDocumentId zum Erstellen eines Webformulars ist jetzt mit einer gültigen ID möglich
Hinzugefügter Statuscode:
- PUT /widgets - Die Verwendung einer libraryDocumentId zum Erstellen von Webformularen wird jetzt mit einer gültigen ID unterstützt
Hinzugefügter Statuscode:
- PUT /widgets/{widgetId} - Erweitert um das neue Feld ownerId
Hinzugefügter Statuscode:
Änderungen der Experience
- GET /widgets/{widgetId} - Erweitert um die neuen Felder: ownerId, ownerEmail, ownerName, und creatorName
Neue Felder im WidgetInfo-Objekt:
Felder mit aktualisiertem Verhalten:
/MEGA SIGN
NEU:
- GET /megaSigns/{megaSignId}/formFields - Ruft die Formularfelddetails eines übergeordneten Mega Sign-Vertrags ab
Parameter:
Antwortobjekt:
- PUT /megaSigns/{megaSignId}/formFields - Aktualisiert die Formularfelder eines Mega Sign-Vertrags
Parameter:
Antwortobjekt:
AKTUALISIERT:
- POST /megaSigns - AUTHORING wurde als Statuswert hinzugefügt, um die Erstellung einer Mega Sign-Vorlage zu unterstützen
Geänderter Parameter:
- PUT /megaSigns/{megaSignId}/state - AUTHORING wurde als Statuswert hinzugefügt, um die Erstellung einer Mega Sign-Vorlage zu unterstützen.Daher ist megaSignCancellationInfo kein Pflichtfeld mehr
Die neue, moderne Startseite und die moderne Seite „Verwalten“ wurden für alle verbleibenden Konten aktiviert.
Alle Accounts haben ihre Steuerungseinstellungen aktualisiert bekommen, um die modernen Startseite- und Verwalten-Seiten für ihre User zu aktivieren.
Die Steuerungen im Administrator-Menü bleiben für Accounts verfügbar, die zur klassischen Erfahrung zurückkehren müssen:
Adobe Sign Service-Level und Account-ID im Administrator-Menü freigelegt
Administratoren können jetzt ihre Account-ID auf der Seite Globale Einstellungen finden:
Die Gruppen-ID findest du auf der Seite Gruppeneinstellungen:
Explizite HIPAA-Konfiguration
Es ist eine neue Seite verfügbar, auf der deutlich angegeben wird, wenn das Konto zur Verwaltung von Vereinbarungen aktiviert ist, die HIPAA-Anforderungen unterliegen.
- Die betreffende Option wird nur auf Kontoebene angezeigt. Administratoren auf Gruppenebene haben keinen Zugriff darauf.
- Diese Steuerung ist nur lesbar, um klar anzuzeigen, wann das Konto konfiguriert ist
- Wenden Sie sich an Ihren Success Manager oder an den Support, um die HIPAA-Konfiguration zu aktivieren.
Der „Call to Action"-Button hat sich für Kundschaft geändert, die die Outlook Desktop-Anwendung auf Windows-Systemen verwenden
Empfänger, die einen Outlook Desktop-E-Mail-Client verwenden, werden feststellen, dass die Schaltflächen mit einer Handlungsaufforderung in Adobe Sign-E-Mails geändert wurden.
Das neue Erlebnis entfernt den blauen HTML-Button und stellt stattdessen einen klickbaren Textlink bereit:
Anmerkung
Diese Änderung betrifft nur Outlook Desktop-Anwendungen auf Windows-Systemen. Andere E-Mail-Clients und Betriebssysteme erhalten die Vorlage weiterhin mit der blauen Schaltfläche.
Delegation von Vereinbarungen mit digitalen Signaturen
Die Möglichkeit, eine Vereinbarung mit angebrachten digitalen Signaturen zu delegieren, wurde verbessert, um die Delegation von der ursprünglichen E-Mail-Benachrichtigung an den Empfänger zu ermöglichen, durch automatische Delegation, wenn sie von einem User konfiguriert wurde, und durch die Aktion Aktuellen Unterzeichner ersetzen auf der Seite Verwalten .
Aktualisierte Benutzeroberfläche für die Zahlungsintegration
Die Zahlungen-Schnittstelle wurde aktualisiert, um die Authentifizierungssteuerelemente besser zugänglich zu machen und so einen einfacheren Konfigurationsprozess zu ermöglichen.
Der maximale Wert für Data Governance wurde auf 5475 Tage (15 Jahre) erhöht
Kundschaft, die Data Governance-Regeln verwendet, um Vereinbarungen automatisch aus dem Adobe Sign System zu löschen, kann nun dieses Löschdatum auf maximal 15 Jahre festlegen (von zehn Jahren erhöht).
Das Textlabel auf Feldebene zur Validierung der US-Sozialversicherungsnummer wurde aktualisiert:
Das Textlabel auf Feldebene zur Validierung der US-Sozialversicherungsnummer wurde aktualisiert, um zu verdeutlichen, dass die SSN auf die USA bezogen ist:
Erinnerung: Social Authentication wurde entfernt
Wie im November angekündigt, wurde die Authentifizierungsmethode mit sozialer Identität aus der Liste der Authentifizierungsmethoden im Admin-Menü entfernt.
Erinnerung: Persönliche Twitter-Integration wurde entfernt
Wie im Dezember angekündigt, wurde die Möglichkeit für Benutzer, persönlich authentifizierte Verbindungen zu Twitter herzustellen, aufgehoben.
Inaktive Benutzer erhalten eine E-Mail-Benachrichtigung, wenn sie in eine Vereinbarung einbezogen werden
Benutzer, die auf einen inaktiven Status gesetzt sind, erhalten jetzt eine E-Mail-Benachrichtigung mit der Anweisung an den Empfänger, die Vereinbarung an einen anderen Benutzer zu delegieren.
Behobene Probleme
Adobe Sign: Mai 2021
Verbesserte Funktionalität
Übertragen des Eigentums an Bibliotheksvorlagen und Webformularen auf einen anderen Benutzer
Der Eigentümer eines Assets kann jetzt von jedem Administrator im Konto geändert werden, der Zugriff auf das Asset hat.
Der Administrator kann die Asset-Eigentümerschaft jedem Benutzer unter seiner Autorität zuweisen.
- Kontoadministratoren haben Zugriff auf alle freigegebenen Assets und alle Benutzer. Administratoren können also auf Kontoebene das Eigentum an einer beliebigen Bibliotheksvorlage oder einem Webformular einem anderen Benutzer in ihrem Konto zuweisen
- Wenn das Asset so konfiguriert ist, dass es nur einem Benutzer zur Verfügung steht (dem Eigentümer), wird es nicht freigegeben und kann daher einem neuen Eigentümer nicht neu zugewiesen werden.
- Gruppenadministratoren können nur auf Bibliotheksvorlagen und Webformulare innerhalb der Gruppen zugreifen, für die sie Administratorrechte haben.
- Gruppenadministratoren können ein Asset nur einem Benutzer neu zuweisen, dessen primäre Gruppe unter ihre administrative Autorität fällt
AKTUALISIERTE API-ENDPUNKTE ZUR UNTERSTÜTZUNG DER ASSET-ÜBERTRAGUNG
Die unten beschriebenen Endpunkte sind nur in der v6 REST-API verfügbar.
Erweitert, um die Aktualisierung des Bibliotheksdokumenteigentümers zu unterstützen.
LibraryDocumentInfo:
Zusätzliche Fehlerstatuscodes:
Erweitert, um die Aktualisierung des Widgeteigentümers zu unterstützen.
WidgetInfo:
Zusätzliche Fehlerstatuscodes:
Neue Felder im Objekt LibraryDocument:
Neue Felder im LibraryDocumentInfo-Objekt:
Felder mit aktualisiertem Verhalten:
Neue Felder im WidgetInfo-Objekt:
Felder mit aktualisiertem Verhalten:
Änderungen der Experience
Der Standard-Rückgabewert von v6 REST GET /workflows{workflowId} hat sich geändert
Der v6 REST GET /workflows{workflowId} API-Aufruf wurde aktualisiert, um die aktuelle Version der WorkflowID zurückzugeben (im Gegensatz zur ursprünglichen Versions-ID, die vor dem Mai-Release der zurückgegebene Wert war)
Dieses Update bringt die Standard-API-Erfahrung mit der Webhook-Erfahrung in Einklang und stellt dieselbe WorkflowID bereit, was die Entwicklung und Verwaltung von Anwendungen verbessern sollte.
Falls dein Konto aus irgendeinem Grund erfordert, dass die API die ursprüngliche ID zurückgibt (wie vor dem Mai-Release), wende dich an den Support, um zu beantragen, dass dein Konto die Basis-Versions-IDs für Workflows zurückgibt
Behobene Probleme
Adobe Sign: Juni 2021
Benutzer in mehreren Gruppen (UMG)
Administratoren in Konten mit mehreren Gruppen können Benutzern in ihrem Konto jetzt Zugriff auf mehrere Gruppen gewähren. Dadurch können Gruppen als eine Art Workflow-Vorlage verwendet werden, wodurch bestimmte Steuerelemente für die Funktion „Senden und signieren“ für die Bibliotheksvorlagen, die für die Gruppe verfügbar sind, durchgesetzt werden.
Vorhandene Unternehmens- und Geschäftskonten, die ein Upgrade durchführen möchten, können den Upgrade-Prozess hier überprüfen >
Eine Zusammenfassung der wirksamen Unterschiede finden Sie hier >
Wir stellen vor: Liquid Mode in Sign
Aktivieren Sie die Liquid Mode-Ansicht für Mobiltelefone für HTML, das über „Seite senden“ oder „Agreement API senden“ gesendet wird. Die Option zum Aktivieren des Liquid Mode in Sign für HTML ist jetzt in der Admin-Menüliste sowohl auf der Konto- als auch auf der Gruppenebene verfügbar.
Weitere Informationen zu Dokumenten zum Liquid Mode finden Sie hier >
Anmerkung
Der Liquid Mode ist derzeit nur in den Umgebungen NA1, NA2 und NA4 verfügbar.
Nahtlose Aktualisierung von Webformularen
Webformulare mit dem Status Entwurf können bearbeitet werden, um Folgendes zu ändern:
- den Namen des Webformulars
- die E-Mail-Adresse des/der Gegenzeichner(s)
- die E-Mail-Adresse der CC-Empfänger
- die angehängten Dateien, die bearbeitet werden sollen
- die Felder im Webformular (zuvor verfügbar)
Durch die Aktualisierung eines aktiven Webformulars können Sie die Formularelemente bearbeiten, ohne die ursprüngliche URL zu ändern. Dies sorgt für einen reibungslosen Ablauf, wenn Sie den Inhalt eines Webformulars aktualisieren müssen, das bereits eingebettet oder an die Zielgruppe gesendet wurde. Elemente, die bearbeitet werden können:
- die Dateien (Dokumente) und angewendeten Felder für die Empfänger
- Gegenzeichner (auf der Seite „Verwalten“)
- Parteien in CC (auf der Seite „Verwalten“)
Anmerkung
Um die nahtlose Funktionalität von Webformularen zu aktivieren, müssen Sie die Option Weitere Teilnehmer zulassen im Menü Globale Einstellungen aktivieren:
Teilnahmestempel: Steuerelementtitel und Firmenanzeige
Es wurden Steuerelemente hinzugefügt, um den Titel und das Unternehmen (stammen aus dem Benutzerprofil) des Empfängers auf dem Stempelfeld des Teilnehmers zu erlauben oder zu unterdrücken.
Weitere Details finden Sie auf der Seite Feldtypen >
Verbesserte Suchoptionen: Präfix- und Ausdrucksübereinstimmungen
Es wurden erweiterte Suchoptionen eingeführt, um spezifischere Suchmuster zu ermöglichen, die dazu beitragen, die zurückgegebene Vereinbarungsliste zu reduzieren.
Weitere Informationen zur Suchfunktion in Adobe Sign finden Sie hier >
OAuth 2.0 ist der neue Standard
Eine neue (verbesserte) Version des OAuth-Endpunkts wurde hinzugefügt, um Nutzungsfehler zu vermeiden. Mit dieser Version:
- api_access_point / web_access_point gibt nur in der Zugriffstokenanfrage (im Textkörper) zurück
- Adobe Sign akzeptiert die Geheimfrage nicht als Abfrageparameter
- Client Secret-Rotation wird unterstützt
Der OAuth v1-Endpunkt wird in den nächsten Monaten weiterhin für bestehende Verbindungen funktionieren, um die weitere Nutzung zu gewährleisten.
Die Einstellung von OAuth v1 wird auf der Seite für technische Benachrichtigungen angekündigt, sobald sie geplant ist.
Rotation von geheimen Clientschlüsseln
Geheime Anwendungs-Clientschlüssel können von jedem Administrator mit Zugriff auf die Anwendungs-ID in der Adobe Sign-Benutzeroberfläche rotiert werden:
Änderungen der Experience
Gruppenadministratoren können nur die API-Anwendungen sehen, die unter ihre Administratorberechtigung fallen
Die Sichtbarkeit von Anwendungen, die mit dem Konto verbunden sind, ist jetzt eingeschränkt, um die Anwendungen anzuzeigen, die unter den administrativen Bereich des Benutzers fallen. Nur Gruppenadministratoren sehen die Verhaltensänderung:
- Benutzer sehen die Anwendungen, die ihnen gehören
- Gruppenadministratoren sehen die Anwendungen unter der Gruppe/unter den Gruppen, für die sie Administratorrechte haben
- Kontoadministratoren sehen alle Anwendungen im Konto
E-Mail an den Absender senden, wenn eine Vereinbarung abgeschlossen ist und aktualisiert wurde
Die letzte E-Mail-Benachrichtigung für eine Vereinbarung, die an den Absender gesendet wurde , wurde aktualisiert und enthält eine umfassende Liste aller Beteiligten, die über die abgeschlossene Vereinbarung informiert wurden.
Nur der ursprüngliche Absender erhält diese E-Mail-Vorlage.
v6 REST API-Ergebnis für GET /agreements/{agreementId}/signingUrls aktualisiert
Wenn GET /agreements/{agreementId}/signingUrls vor dem Juni-Release aufgerufen wurde, hat das API sofort einen 404 zurückgegeben, nachdem die Vereinbarung erstellt wurde.
Nach dem Löschen des Fehlers 404 hat die Antwort für kurze Zeit eine Nicht-404-Antwort zurückgeben, die jedoch nur die SigningURLs des Absenders enthalten hat. (Während die Teilnahme des Unterzeichners noch festgelegt wurde.)
Nach der Veröffentlichung des Juni-Release 2021 wird ein Code zu 404: AGREEMENT_NOT_EXPOSED zurückgegeben, bis die komplette Liste der Signatur-URLs vervollständigt wurde. Ist dies der Fall wird ein Code mit dem Wert 200 geliefert.
Kunden, die den API-Call nicht testen wollen bis die Antwort mit dem Wert 200 zurückgegeben wird, können Webhooks nutzen und auf das AGREEMENT_CREATED-Event antworten.
Behobene Probleme
Adobe Sign: August 2021
Änderung der Experience
- Aadhaar International Support – Kunden aller Adobe Sign-Instanzen können den optionalen Aadhaar-Dienst jetzt als Anbieter digitaler Signaturen verwenden. Bisher war der Dienst nur für Konten in der Instanz IN1 verfügbar. Das Aadhaar-Add-on kann gegen eine zusätzliche Gebühr pro Signaturtransaktion erworben werden.
- REST v6 Aktualisierung: POST /users - Der REST v6 POST /users API-Aufruf wurde aktualisiert, um den Benutzer in der Standardgruppe des Accounts zu erstellen, wenn der optionale Parameter Haupt-Gruppen-ID nicht definiert ist. Nur v6 der REST API ist von dieser Änderung betroffen.
Behobene Probleme
|
|
Beschreibung |
|---|---|
|
4299495 |
Ein Problem im Workflow Designer wurde behoben, das verhinderte, dass eine kundendefinierte URL in den Anweisungen funktioniert. |
|
4308294 |
Ein Problem in der Bericht-CSV-Datei wurde korrigiert, bei dem die Felder An und Empfängername leer bleiben konnten, wenn dieselbe Empfänger-E-Mail mehr als einmal in der Vereinbarung verwendet wurde. |
|
4310569 |
Die Adobe Sign-Vorlagen wurden aus den Sandbox-Optionen herausgefiltert. |
|
4311098 |
Ein Problem wurde korrigiert, bei dem Gruppenadministratoren Benutzer in einer Gruppe nicht per CSV-Upload aktualisieren konnten. |
|
4311723 |
Ein Problem wurde behoben, bei dem der GET /groups/ID/users API-Aufruf fehlschlug, wenn sich der Benutzer auf einer anderen Adobe Sign-Instanz befand. |
|
4312103 |
Ein Problem wurde korrigiert, bei dem SAML-Benutzer, die per Massen-Upload angelegt wurden, sich im Status Angelegt (anstatt Primär) befanden. |
|
4312309 |
Ein Problem wurde korrigiert, bei dem Gruppenadministratoren die Eigentümerschaft von Webformularen nicht neu zuweisen konnten, wenn andere Benutzer in ihrer Gruppe sie erstellt hatten. |
|
4312840 |
Ein Problem wurde behoben bei der Aktivierung neuer Benutzer, wenn eine zweite Aktivierungs-E-Mail an den neuen Benutzer gesendet wurde und dieser zweite E-Mail-Link verwendet wurde. |
|
4314751 |
Ein Problem wurde korrigiert, bei dem die Option zur Ablehnung der Vereinbarung nicht sichtbar war, wenn im Namen eines anderen Benutzers unterzeichnet wurde. |
|
4315033 |
Ein Problem wurde behoben, bei dem Account-Administratoren keine Passwörter zurücksetzen konnten, wenn der SAML-Modus auf Obligatorisch eingestellt war. |
|
4315605 |
Ein Problem wurde korrigiert, bei dem Bilder von amtlichen Lichtbildausweisen nicht erfolgreich verarbeitet wurden. |
|
4316057 |
Ein Problem wurde behoben, bei dem der amtliche Lichtbildausweis einen Fehler erzeugt hat, der angezeigt hat, dass die vier Ecken des Dokuments nicht gefunden werden konnten. |
|
4316474 |
Ein Problem wurde korrigiert, bei dem „Im Namen von unterzeichnen" in Konten sichtbar war, in denen die Option nicht aktiviert war. |
|
4316659 |
Es wurde ein Problem behoben, bei dem die E-Mail-Adresse für ‚actingUserEmail‘ beim Aufruf „GET /agreements/id“ eine vom System generierte E-Mail zurückgab, nachdem der Vertrag vollständig unterzeichnet war. |
|
4317095 |
Ein Problem wurde korrigiert, bei dem ein Empfängername in das Label Teilnehmer 1 importiert wurde, wenn wissensbasierte Authentifizierung für den ersten Unterzeichner verwendet wurde. |
|
4317221 |
Ein Problem wurde korrigiert, bei dem automatische Benachrichtigungs-E-Mails für fehlgeschlagene Webhooks an den Webhook-Ersteller gesendet wurden, obwohl konfiguriert war, den Ersteller nicht zu benachrichtigen. |
|
4317347 |
Ein Problem wurde behoben, bei dem die Authentifizierung von OAuth in Power Automate den Benutzer zur Homepage umgeleitet hat. |
|
4317429 |
Ein Problem wurde behoben, bei dem Administratoren die Eigenschaft „Kann senden" für Benutzer beim Aktualisieren per CSV-Upload nicht aktualisieren konnten. |
|
4317548 |
Ein Problem wurde behoben, bei dem einige Kunden mit dem iPad die Web-Seite anstelle der für Mobilgeräte optimierten Seite sahen. |
|
4317629 |
Ein Anzeigeproblem mit Namen wurde behoben, die ein Apostroph enthalten und den HTML-Code für das Apostroph anzeigten. |
|
4318175 |
Es wurde ein Problem behoben, bei dem Benutzer einen Fehler erhielten, wenn sie ein Konto über den E-Mail-Link archivierten. |
|
4319012 |
Es wurde ein Problem behoben, bei dem über REST v5 und v6 POST /users erstellte Benutzer nicht in der Standardgruppe erstellt wurden. |
|
4320197 |
Ein Problem wurde behoben, bei dem der Signaturgeber-Identitätsbericht nicht von der Verwalten Seite heruntergeladen werden konnte, da der Button inaktiv war. |
Adobe Sign: September 2021
Verbesserte Funktionalität
- Sandbox Enterprise Tier-Kunden haben die Möglichkeit, Zugriff auf eine Sandbox-Umgebung zu erwerben, um Vorlagen, Kunden-Workflows, API-Anwendungen und mehr zu testen. Diese Objekte können für Aktualisierungen in einer sicheren Umgebung aus der Produktionsumgebung in die Sandbox und dann wieder in die Produktionsumgebung verschoben werden, sobald die Aktualisierungen überprüft wurden und bereit für das Deployment sind.
- ECDSA Digitale Signatur-Unterstützung - Adobe Sign unterstützt jetzt sicherere und effizientere digitale Signaturen basierend auf dem ECDSA-Format, das elliptische Kurvenkryptographie verwendet, wie im ANS X9.62-2005 Standard definiert.
NIST-Kurven mit SHA-2-Hash-Funktionen gemäß FIPS-Standards werden jetzt unterstützt, sodass unsere Partner der Trust Service Provider (TSP) des Cloud Signature Consortium die Möglichkeit haben, Unterzeichnern schnellere und sicherere elliptische Kurvendaten zu bieten. Einschließlich solcher, die die empfohlenen Verwendungsanforderungen der US-Bundesbehörden und der Regierung von Singapur erfüllen.
- Aktualisierter Liquid Mode – das Liquid Mode-Signiererlebnis wurde neben Verträgen auch auf Webformulare ausgeweitet. Liquid Mode-Formulare können die Erfahrung des Unterzeichners erheblich verbessern, da das Verkleinern und Vergrößern zur Anzeige des Formularinhalts nicht mehr erforderlich ist und der Unterzeichner sich voll und ganz auf die Felder konzentrieren kann, die ausgefüllt werden müssen.
Zusätzlich ist der Liquid Mode nicht mehr auf nordamerikanische Shards beschränkt. Alle Unternehmens- und Business-Konten haben jetzt unabhängig vom Standort Zugriff.
- Neue TSPs: Cleverbase (Niederlande), PrimeSign (Österreich), Sectigo (Global) und TrustPro (Irland) sind die neuen Vertrauensdienstleister des Cloud Signature Consortium, die Zertifikate zur Anwendung sicherer digitaler Signaturen bereitstellen, die die höchsten Standards und Compliance-Anforderungen erfüllen.
- Anpassung der An- und CC-Felder in E-Mail-Headern für Empfänger - Kunden, die sich Sorgen über das Preisgeben von E-Mail-Adressen über die E-Mail-Header an Empfänger machen, können wählen, die E-Mail-Adress-Werte in den An- und CC-Feldern auszublenden.
- Diese Option ist für Enterprise- und Business-Konten verfügbar und kann auf Konto- und Gruppenebene konfiguriert werden.
- Du kannst auf die Funktionssteuerungen zugreifen, indem du zu Kontoeinstellungen > E-Mail-Einstellungen > An- und CC-Felder anpassen navigierst.
Änderungen der Experience
- Zustimmung zu den Nutzungsbedingungen von Adobe auf der eSign-Seite: Um die gesetzlichen Anforderungen von Adobe zu erfüllen, aktualisiert Adobe Sign das Zustimmungsverhalten für die Nutzungsbedingungen auf der eSign-Seite. In der neuen Version müssen alle „unbekannten“ Empfänger die Nutzungsbedingungen und die Datenschutzrichtlinie von Adobe Sign akzeptieren (indem sie auf die Schaltfläche Weiter klicken), bevor sie mit der Vereinbarung interagieren. Diese Zustimmung unterscheidet sich von allen benutzerdefinierten Nutzungsbedingungen, die möglicherweise für das Kundenkonto konfiguriert wurden. Für diese gilt weiterhin die für Nutzungsbedingungen/Kundenhinweise konfigurierte Zustimmung für das Konto.
- Ein „unbekannter" Empfänger ist jede E-Mail-Adresse, die keine registrierte, aktive Benutzer-E-Mail in einem vertrauenswürdigen Konto ist.
- „Bekannte“ Benutzer haben die Nutzungsbedingungen von Adobe Sign als Teil des Registrierungsvorgangs akzeptiert, als sie ihr Benutzerkonto verifiziert haben. Daher werden sie nicht aufgefordert, sie erneut zu akzeptieren.
Nachstehend sehen Sie ein Beispiel für den impliziten Zustimmungsablauf für eine Vereinbarung mit vom Kunden definierten benutzerdefinierten Nutzungsbedingungen:
- Akzeptieren Sie die Nutzungsbedingungen von Adobe Sign, indem Sie auf die Schaltfläche Weiter klicken (nachdem Sie die Vereinbarung geöffnet haben).
- Füllen Sie die Vereinbarungsfelder nach Bedarf aus.
- Akzeptiere die Kundenoffenlegung und benutzerdefinierten Nutzungsbedingungen, indem du auf die Click to Sign-Schaltfläche klickst.
- Sperrung von Namenswerten wurde auf eingegebene Signaturen erweitert – Die März-Version hat eine Einstellung eingeführt, mit der die Möglichkeit eines Empfängers, seinen Namenswert beim Signieren zu bearbeiten, aktiviert oder deaktiviert werden kann. Voraussetzung dafür ist, dass der Name angegeben wurde oder bekannt ist (über API oder das Benutzerprofil). Eingegebene Signaturen waren von dieser Einstellung nicht betroffen, sodass einige Unterzeichner ihren Namenswert während des Signaturprozesses ändern konnten. Die September-Version aktualisiert diese Funktion, um die Sperrung von Namenswerten auf alle Signaturtypen – einschließlich eingegebener Signaturen – auszuweiten.
- Kunden, die Eingabe ihres Namens und ihrer Initialen aktiviert und Signaturgeber können ihren Namen oder ihre Initialen ändern deaktiviert haben, werden eine Verhaltensänderung sehen – der Namenswert ist während des Signaturprozesses für getippte Signaturen nicht mehr bearbeitbar.
- Kunden, die die Bearbeitung des Namenswerts während des Signaturprozesses zulassen möchten, sollten die Einstellung Unterzeichner können ihren Namen oder ihre Initialen ändern aktivieren (im Menü Signatureinstellungen ).
- Inaktive Benutzer können Vereinbarungen signieren – Adobe Sign behandelt inaktive Benutzer jetzt so, als ob sie dem System unbekannt sind (zum Signieren von eingehenden Vereinbarungen). Wenn ein inaktiver Benutzer aufgefordert wird, eine Vereinbarung zu signieren, wird dafür eine neue Benutzer-ID zur einmaligen Verwendung erstellt. Die einmalige Benutzer-ID ist unabhängig von der inaktiven Benutzer-ID und dem dazugehörigen Konto. Dies hat mehrere Konsequenzen:
- Vereinbarungen, die an einen inaktiven Benutzer gesendet werden, können signiert werden, da der Status „Inaktiv“ nicht für die für die Vereinbarung generierte einmalige Benutzer-ID gilt.
- Vereinbarungen, die von der einmaligen Benutzer-ID signiert wurden, sind keine Elemente der inaktiven Benutzer-ID und befinden sich nicht im Konto der inaktiven Benutzer-ID.
- Freigaben der inaktiven Benutzer-ID enthalten keine Vereinbarungen, die von einmaligen Benutzer-IDs signiert wurden.
- Berichte zur inaktiven Benutzer-ID enthalten keine Vereinbarungen, die von der einmaligen Benutzer-ID signiert wurden.
- Wenn die inaktive Benutzer-ID erneut aktiviert wird, werden die Berichte zu Vereinbarungen, die von einmaligen Benutzer-IDs unterzeichnet wurden, nicht auf der Seite „Verwalten“ angezeigt.
Es gibt zwei Ausnahmen von dem oben genannten Verhalten:
- Vereinbarungen, die an den Benutzer gesendet wurden, bevor sie als inaktiv markiert wurden, können nicht unterzeichnet werden (die Vereinbarung war bereits an die inaktive Benutzer-ID gebunden).
- Benutzer, die explizit so konfiguriert wurden, dass sie keine Berechtigung zum Signieren von Vereinbarungen haben, können weiterhin keine Signierungsaktionen durchführen.
Inaktive Benutzer können sich weiterhin auf keinerlei Weise beim Adobe Sign-System anmelden und keine Vereinbarungen unter ihrer Befugnis versenden.
- Verbesserte Sicherheit für den Zugriff auf Webformulare über ein Passwort: Webformulare haben nach einigen erfolglosen Versuchen, auf eine passwortgeschützte URL zuzugreifen, eine Verzögerung hinzugefügt.
- Aadhaar International Support: Kunden aller Adobe Sign-Instanzen können den optionalen Aadhaar-Dienst jetzt als Anbieter digitaler Signaturen verwenden. Bisher war der Dienst nur für Konten in der Instanz IN1 verfügbar. Das Aadhaar-Add-on kann gegen eine zusätzliche Gebühr pro Signaturtransaktion erworben werden.
- Begrenzte Freigabe von Vereinbarungen - Das Freigeben von Vereinbarungen wurde begrenzt, wenn die Vereinbarung an eine externe E-Mail-Adresse freigegeben wird.
- Konten mit mehreren Lizenzen können eine Vereinbarung bis zu zehn Mal freigeben.
- Kontakte können eine Vereinbarung bis zu 5 Mal freigeben.
- Die Freigabe einer Vereinbarung für interne Benutzer ist nicht eingeschränkt.
- Konten mit mehreren Lizenzen können eine Vereinbarung bis zu zehn Mal freigeben.
- Der benutzerdefinierte Firmenname in der Telefonauthentifizierung wurde aus dem Dienst entfernt: Der benutzerdefinierbare Firmenname, der zur Telefonauthentifizierungsmethode hinzugefügt werden konnte, wurde aus dem Dienst entfernt , wie in der technischen Mitteilung im Juni angekündigt.
- HIPAA-fähige Konten können nun auf der Seite Globale Einstellungen/Gruppeneinstellungen auf die Steuerelemente für Bilder und Links in Empfänger-E-Mails zugreifen.
Sehen Sie sich hier die HIPAA-bezogenen Konfigurationen an >
- Die Reihenfolge, in der Dateianhänge in das finale PDF einbezogen werden, wurde aktualisiert, um zuerst nach Seitenzahl und dann nach Feldposition zu sortieren (beim Lesen von links nach rechts; von oben nach unten)
- Die Funktion Empfänger ersetzen auf der neuen Seite Verwalten ermöglicht es dem Absender nun, eine optionale Nachricht für den neuen Empfänger einzufügen.
Weitere Informationen finden Sie unter der Funktion „Empfänger ersetzen“ >
- Externe Unterzeichner, die auf abgeschlossene Vereinbarungen zugreifen, müssen jetzt einen Authentifizierungsprozess durchlaufen, wenn die Multi-Faktor-Authentifizierung für die Vereinbarung konfiguriert wurde (sie werden nicht mehr aufgefordert, sich bei Adobe Sign anzumelden).
- Webformulare melden jetzt die Feldwerte von nicht verifizierten Webformularen beim Zugriff auf Felddaten mit der Funktion Formularfelddaten herunterladen auf der Seite Verwalten.
API-Aktualisierungen
- Option „Vereinbarung lesen“ für Webformulare: Zwei neue REST v6 API-Aufrufe sind verfügbar, um Zugriff auf Webformulare zu gewähren:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} gibt jetzt die Teilnehmerrolle in der Antwort zurück.
Behobene Probleme
| 4292343 | Klarere Unterschrift bei Verwendung der TYPE-Signaturoption auf mobilen Geräten. |
| 4295123 | Es wurde ein Problem behoben, das verhinderte, dass digitale Signaturen beim Öffnen in einem Browser sichtbar waren. |
| 4299289 | Das Benutzererlebnis für die Funktion „Empfänger ersetzen“ wurde verbessert; der Absender kann jetzt eine Nachricht an den neuen Empfänger senden. |
| 4299857 | Es wurde ein Problem behoben, das dazu führen konnte, dass eine unterzeichnete Vereinbarung das Zertifikatssiegel nicht anwendet. |
| 4304261 | Es wurde ein Problem behoben, das dazu führen konnte, dass die Option „Vereinbarung lesen“ nicht im Menü „Optionen“ angezeigt wird. |
| 4308516 | Es wurde ein Problem behoben, bei dem Benutzer bei der Verwendung von OneDrive ständig aufgefordert wurden, die Zustimmung des Administrators einzuholen. |
| 4310225 | Es wurde ein Problem behoben, bei dem Vereinbarungen mit mehreren Signaturen einen Serverfehler ausgelöst haben; Fehlermeldung: Die auf dieses Dokument angewendete Signatur ist ungültig. Löschen Sie die Signatur und unterschreiben Sie erneut. |
| 4310416 | Die v5 REST-API wurde aktualisiert, um Benutzer in einem aktiven Status zu erstellen, wenn sie mit POST /users erstellt wurden. |
| 4311287 | Es wurde ein Problem behoben, bei dem die Gruppennavigationsschaltfläche bei UMG-fähigen Konten nicht mehr angezeigt wurde, nachdem ein Benutzer aus einer Gruppe entfernt wurde. |
| 4311956 | Es wurde ein Problem behoben, bei dem die angegebene Schriftgröße für ein Feld nicht im Signiererlebnis widergespiegelt wurde. |
| 4312302 | Es wurde ein Problem behoben, bei dem die Option „Kennwort zurücksetzen“ entfernt wurde, wenn der SAML-Modus auf „Obligatorisch“ gesetzt war. |
| 4312735 | Es wurde ein Problem behoben, das dazu führen konnte, dass freigegebene Ereignisbenachrichtigungen zugestellt wurden, wenn freigegebene Benachrichtigungen deaktiviert wurden. |
| 4313025 | Es wurde ein Problem behoben, bei dem eine Formularausfüllerrolle nicht die nicht zugewiesenen Rollen ausfüllen konnte, wenn Hybrid-Routing aktiviert war. |
| 4313030 | Es wurde ein Problem behoben, bei dem Konten, für die UMG aktiviert ist, einen Fehler mit einem benutzerdefinierten Workflow ausgelöst haben, wenn die primäre Gruppe des Absenders nicht senden darf. |
| 4313264 | Aktualisierung der HIPAA-fähigen Einstellung, um den Zugriff auf die E-Mail-Link-/Bildeinstellungen auf der Seite „Globale Einstellungen“ zu ermöglichen. |
| 4315839 | Es wurde ein Problem mit benutzerdefinierten Workflows behoben, bei dem Felder nicht vorausgefüllt werden konnten, wenn der Absender auch der zweite Empfänger war. |
| 4316058 | Das Berichtsfeldverhalten wurde aktualisiert, sodass jetzt auch führende Nullen in Textfeldern zulässig sind. |
| 4317382 | Es wurde ein Problem mit Optionsfeldern behoben, die den HTML-Code für Apostrophe in der QuickInfo anzeigen. |
| 4317978 | Die Reihenfolge von Dateianhängen in der endgültigen PDF-Datei wurde aktualisiert; sie werden nun zuerst basierend auf der Seitennummer des Felds und dann in Bezug auf die die relative Position des Feldes gruppiert (beim Lesen von links nach rechts und von oben nach unten). |
| 4318598 | Der REST v6 API-Aufruf GET/workflows/{workflowId} gibt jetzt die Teilnehmerrolle in der Antwort zurück. |
| 4318606 | Die Funktion „Formularfelddaten herunterladen“ auf der Seite „Verwalten“ gibt jetzt Feldwerte für Webformulare zurück, die noch nicht verifiziert wurden. |
| 4318617 | Es wurde ein Problem behoben, bei dem ein Gruppenadministrator für Konten mit UMG-Aktivierung eine Einladung nicht erneut senden konnte. |
| 4318679 | Es wurde ein zeitweiliges Problem behoben, das dazu führen konnte, dass Dokumente mit handschriftlicher Signatur nicht hochgeladen wurden. |
| 4318926 | Es wurde ein Problem behoben, bei dem beim Generieren einer Vereinbarung von einem Mobilgerät aus ein Fehler ausgelöst wurde (die Cookie-Funktion ist im Browser deaktiviert). |
| 4318991 | Es wurde ein Problem behoben, das dazu führen konnte, dass die Einstellung für maximale Anmeldefehler ignoriert wurde, wenn SAML auf „Zulässig“ gesetzt war. |
| 4319068 | Externe Empfänger müssen jetzt einen zweistufigen Authentifizierungsprozess durchlaufen (anstatt sich bei Adobe Sign anzumelden), um Zugriff auf abgeschlossene Vereinbarungen zu erhalten, wenn die Multi-Faktor-Authentifizierung konfiguriert ist. |
| 4319422 | Es wurde ein Problem behoben, bei dem ein Empfänger ohne Bestätigung des Kennworts ersetzt werden konnte (für Vereinbarungen mit Kennwortauthentifizierung). |
| 4319455 | Es wurde ein Problem bei der erweiterten Freigabe behoben, bei der die Einstellungen nach dem Speichern möglicherweise nicht dauerhaft gespeichert wurden. |
| 4320123 | Es wurde ein Problem behoben, bei dem beim Versuch, eine Vereinbarung auf der Seite „Verwalten“ anzuzeigen und zu genehmigen, ein Fehler ausgelöst werden konnte. |
| 4320205 | Es wurde ein Problem behoben, das das Speichern des Fortschritts beim Vorausfüllen einer Vereinbarung mit erweiterter Freigabe verhindern konnte. |
| 4320542 | Es wurde ein Problem bei Konten mit UMG-Aktivierung behoben, bei dem bei Verwendung der Suchfunktion alle Gruppenzuordnungen eines Benutzers entfernt wurden, wenn eine Gruppe entfernt wurde. |
| 4321357 | Es wurde ein Problem behoben, bei dem ein Fehler auf der Seite „Senden“ ausgelöst wurde, wenn KBA für die Authentifizierung ausgewählt wurde und „Name beim Senden erforderlich“ aktiviert war. |
| 4322445 | Das Authoring wurde verbessert, um konsistente Hintergrundfarben zu ermöglichen. |
| 4322956 | Es wurde ein Problem mit benutzerdefinierten E-Mail-Vorlagen behoben, bei dem die Empfänger die tatsächliche E-Mail-Adresse des Unterzeichners nicht gesehen haben. |
| 4323609 | In Entwicklung – Es wurde ein Problem behoben, bei dem bei Vereinbarungen, die durch das Hochladen eines unterzeichneten Dokuments abgeschlossen wurden, nicht die Webhook-Benachrichtigung AGREEMENT_WORKFLOW_COMPLETED ausgelöst wurde. |
| 4323968 | Die Signatursperrfunktion wurde verbessert, sodass nun auch eingegebene Signaturen einbezogen werden, wenn der Namenswert über das Profil oder die API bereitgestellt wird. |
Adobe Sign: Oktober 2021
Verbesserte Funktionalität
- Links zum Melden von Missbrauch – Small Business- und Einzelbenutzer-Konten verfügen jetzt über einen Link, über den die Empfänger potenziell missbräuchliche Aktivitäten in Bezug auf eingehende Vertragsanfragen melden können.
- Integration von Notarize – Dank der Integration der Remote Online Notarization-Plattform (RON) von Notarize in Adobe Sign können Kunden ihren Adobe Sign-Transaktionen Remote-Online-Beglaubigungsservices hinzufügen. Aktivierung für US-Kunden der Enterprise- und Business-Ebene verfügbar, die direkt von Adobe über das ETLA-Programm verkauft werden. Notarize Transaktionen können nur von diesen Kunden als Add-on mit zusätzlichen Gebühren erworben werden.
- Aktualisierungen der Seite Senden – Kunden mit aktivierter Notarfunktion können die Option Beglaubigung erforderlich auf dem Empfängerdatensatz rechts neben der Authentifizierungsmethode auswählen:
- Aktualisierungen der Seite Senden – Kunden mit aktivierter Notarfunktion können die Option Beglaubigung erforderlich auf dem Empfängerdatensatz rechts neben der Authentifizierungsmethode auswählen:
Anmerkung
Kunden, die die eingebettete Seite Senden in ihren Anwendungen oder Integrationen verwenden, haben ebenfalls Zugriff auf die Notarfunktion.
Nachdem die Vereinbarung konfiguriert wurde und der Absender auf „Weiter“ klickt, werden dem Absender zusätzliche Konfigurationsoptionen für den Beglaubigungsprozess angezeigt:
- API-Updates: Es gibt wichtige Aktualisierungen der APIs, die die Notarize-Integration unterstützen:
POST /agreements
Die POST-/agreements-API wurde aktualisiert, um das Senden einer Vereinbarung zur Beglaubigung zu unterstützen.
- Eine neue Rolle, NOTARY_SIGNER, muss verwendet werden, um einen Teilnehmer einer Beglaubigungssitzung anzugeben.
- Der AgreementInfo-Definition wurde das neue Attribut NotaryInfo hinzugefügt, sodass alle Optionen enthalten sind, die mit der Erstellung einer neuen Vereinbarung verknüpft sind, die beglaubigt werden muss.
|
Parametername |
REST-Objekt |
Beschreibung |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Array von ParticipantInfo-Objekten mit teilnehmerspezifischen Daten (z. B. E-Mail). Alle Teilnehmer im Array gehören zu derselben Gruppe. |
||||||||||||||||
|
role |
|
Rolle, die von allen Teilnehmern der Gruppe übernommen wird (Unterzeichner, Genehmiger usw.) |
FileInfo-Erweiterung
Die FileInfo-Definition muss erweitert werden, um anzugeben, welche Dokumente beglaubigt werden sollen.
|
Parametername |
Typ |
Standard |
Erforderlich |
Beschreibung |
|---|---|---|---|---|
|
Dokument |
Dokument |
|
optional |
Ein Dokument, das mit der Vereinbarung verknüpft ist. |
|
label |
Zeichenfolge |
|
optional |
Der eindeutige Labelwert eines Dateiinfo-Elements. Im Fall eines benutzerdefinierten Workflows ordnet dies eine Datei dem entsprechenden Dateielement in der Workflow-Definition zu. |
|
libraryDocumentId |
Zeichenfolge |
|
optional |
ID für ein vorhandenes Bibliotheksdokument, das der Vereinbarung hinzugefügt wird |
|
transientDocumentId |
Zeichenfolge |
|
optional |
ID für ein transientes Dokument, das der Vereinbarung hinzugefügt wird |
|
notarize |
true |
false |
optional |
Gibt an, dass dieses Dokument notariell beglaubigt werden muss. |
ParticipantInfo-Erweiterung
Die ParticipantInfo-Definition wurde erweitert, damit die Notar-Authentifizierungsmethode angegeben werden kann.
|
Parametername |
Typ |
Standard |
Erforderlich |
Beschreibung |
|---|---|---|---|---|
|
|
Zeichenfolge |
Nicht zutreffend |
erforderlich |
E-Mail des Teilnehmers |
|
notaryAuthentication |
Aufzählung |
MULTI_FACTOR_AUTHENTICATION |
optional |
MULTI_FACTOR_AUTHENTICATION – Notar-Authentifizierung erfolgt mit einer Zwei-Faktor-Authentifizierungsmethode |
NotaryInfo
Ein neues optionales NotaryInfo-Feld wurde der AgreementInfo-Definition hinzugefügt, sodass nun das NotaryInfo-Objekt enthalten ist, das zusätzliche Optionen im Zusammenhang mit der Beglaubigung angibt.
|
Parametername |
Typ |
Standard |
Erforderlich |
Beschreibung |
|---|---|---|---|---|
|
notaryType |
Aufzählung |
Wenn für das Konto nur der Notary on Demand-Service von Notarize aktiviert ist, |
erforderlich |
NOTARIZE_NOTARY – Der Notarize-Service stellt den Notar bereit |
|
payment |
Aufzählung |
BY_SENDER |
optional |
Gilt nur, wenn type == NOTARIZE_NOTARY |
|
appointmentStart |
Zeichenfolge |
"" |
optional |
Nach ISO_DATE_TIME formatierte Zeichenfolge Siehe ISO_ZONED_DATE_TIME |
|
note |
Zeichenfolge |
Ohne |
optional |
Hinweise für Beglaubigungssitzung |
|
notaryEmail |
Zeichenfolge |
"" |
optional |
E-Mail des BYON-Notars |
Beispiel /agreement
PUT|GET /agreements/{aid}
Die API für PUT/agreements/{aid} unterstützt die Aktualisierung einer Vereinbarung mit Beglaubigungsoptionen. Die GET /agreements/{aid}-API gibt alle Optionen zurück, die für die Beglaubigung der Vereinbarung festgelegt wurden. Aktualisierte Attribute finden Sie im Abschnitt „POST /agreements“.
Fehlercodes
Bestehende Fehlercodes für POST /agreements bleiben unverändert. Wir haben einen neuen Fehlercode wie unten angegeben definiert:
|
REST-Fehlercode |
HTTP-Statuscode |
Nachricht |
Szenario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
Benutzereinstellung oder OAuth-Geltungsbereichstoken lassen das Senden einer Vereinbarung zur Beglaubigung nicht zu. |
Dieser Fehler wird ausgelöst, wenn die Rolle auf NOTARY_SIGNER gesetzt ist und für den API-Aufrufer (d. h. den voraussichtlichen Absender) keine Notarfunktion aktiviert ist und/oder wenn kein Anbieter für den Beglaubigungsservice festgelegt ist. |
Dokumentationsauswirkung
Im AgreementInfo-Objekt der Anforderung enthält das Element „Status“ den neuen Vereinbarungsstatus WAITING_FOR_NOTARIZATION.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
Die API kann von Kunden (Notarunterzeichnern) verwendet werden, um ein Signaturtoken zu erhalten, mit dem sie die elektronische Signierphase des Ablaufs abschließen können.
- Neue Signaturfunktion wurde hinzugefügt, um die neue Rolle ACCEPT_BEFORE_NOTARIZATION zu erfassen.
- Zum Abschließen der Beglaubigungsphase sollten keine Signaturtoken abgerufen werden.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
Die API kann von Kunden (notarielle Unterzeichner) verwendet werden, um die elektronische Signierphase des Signierablaufs abzuschließen. Um die neue Rolle aufzunehmen, wurde der neue Enumerationsstatuswert ACCEPTED_BEFORE_NOTARIZATION eingeführt.
|
Attribut |
Typ |
Beschreibung |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Status |
Enum<String>
|
|
||||||||||||||
Der notarielle Unterzeichner kann die folgende Abfolge von API-Aufrufen befolgen, um die elektronische Signierphase abzuschließen:
- GET /agreements/{agreementId}/member – zum Abrufen der Teilnehmer-ID und der Teilnehmer-Gruppen-ID des notariellen Unterzeichners
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens – zum Anfordern des Signaturtokens für den notariellen Unterzeichner mit der Funktion ACCEPT_BEFORE_NOTARIZATION
- POST /transientDocuments – zum Hochladen des überprüften Dokuments
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status – zum Senden des überprüften Dokuments und Abschließen der elektronischen Signierphase
Neues Webhook-Ereignis
Kunden können ein neues Webhook-Ereignis, AGREEMENT_READY_FOR_NOTARIZATION, abonnieren, wenn sie benachrichtigt werden möchten, sobald die Vereinbarung zur Beglaubigung bereit ist. Das Ereignis wird in der Webhooks-Benutzeroberfläche nicht angezeigt und kann über den POST /webhooks-API-Aufruf abonniert werden.
Dokumentationsauswirkung
Die folgenden APIs werden nicht geändert, aber ihre Dokumentation wurde dahingehend aktualisiert, dass nun der neue Vereinbarungsstatus WAITING_FOR_NOTARIZATION bzw. die neue Rolle NOTARY_SIGNER enthalten ist.
GET /agreements
Im UserAgreements/UserAgreement-Antwortobjekt enthält das Element „Status“ jetzt den entsprechenden Status WAITING_FOR_NOTARIZATION.
GET /agreements/{agreementId}
Im AgreementInfo-Antwortobjekt enthält das Element „Status“ jetzt den entsprechenden Status WAITING_FOR_NOTARIZATION.
GET /agreements/{agreementId}/events
API wurde aktualisiert, um neue READY_TO_NOTARIZE- und NOTARIZED-Ereignisse zu unterstützen.
Im Event-Antwortobjekt:
- Das Element „participantRole“ enthält jetzt die neue Rolle NOTARY_SIGNER.
- Das Element „type“ enthält die neuen Ereignisse READY_TO_NOTARIZE und NOTARIZED. Das Element „description“ lautet „Dokument zur Beglaubigung gesendet“ bzw. „;Beglaubigtes Dokument erhalten“.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
Im DetailedParticipantSetInfo-Antwortobjekt enthält das Element „Status“ jetzt den entsprechenden Status WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}
Das AgreementInfo-Anforderungsobjekt enthält jetzt den Status WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
Der Status WAITING_FOR_NOTARIZATION ist einer der Werte für das Element „Status“ im DetailedParticipantSetInfo-Objekt.
POST /agreements/{agreementId}/view
Der Status „AUF_BEGLAUBIGUNG_WARTEN“ wurde zu den zulässigen Ansichten hinzugefügt.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Wenn der im Anforderungspfad angegebene Teilnehmer über die Notarunterzeichnerrolle verfügt, gibt die API in Übereinstimmung mit allen anderen Signaturkonfigurationen für diese Vereinbarung/diesen Teilnehmer die Signaturkonfiguration ACCEPT_BEFORE_NOTARIZATION zurück.
Behobene Probleme
| Problem | Beschreibung |
| 4308901 | Es wurde ein Problem behoben, bei dem das Delegieren einer Vereinbarung mit Telefonauthentifizierung zu einem Fehler führte, wenn die delegierte Telefonnummer die gleiche Landesvorwahl hatte. |
| 4314113 | Es wurde ein Problem behoben, bei dem die standardmäßigen Ablaufdaten von den Benutzern nicht bearbeitet werden konnten, wenn eine neue Vereinbarung gesendet wurde. |
| 4318558 | Es wurde ein Problem behoben, bei dem das Ersetzen eines Empfängers durch die Telefonauthentifizierung zu der Fehlermeldung „Die angegebene Teilnehmer-Gruppen-ID ist ungültig“ führte. |
| 4319038 | Es wurde ein Problem behoben, bei dem der Absender die Option „Verifizierung der Identität externer Empfänger“ nicht angezeigt bekommen hat, wenn er den Workflow „Massenversand“ verwendete. |
| 4319798 | Es wurde ein Problem behoben, bei dem die Auswahl eines Optionsfeldes dazu führen konnte, dass der Cursor auf ein anderes Feld wechselte. |
| 4320154 | Es wurde ein Problem behoben, das das Speichern einer Bibliotheksvorlage in einer neuen Gruppenbeziehung verhinderte. |
| 4323013 | Es wurde ein Problem behoben, bei dem das Öffnen eines Webformulars auf der Verwaltungsseite eine Fehlermeldung auslöste: „Das Dokument ist noch nicht verfügbar oder enthält keine Seiten zum Anzeigen“. |
| 4323554 | Es wurde ein Problem behoben, bei dem die Zeit-/Datumsstempel des Ereignisses für die Aktualisierung von Administratorrechten zwei Datensätze mit denselben Zeitwerten erzeugten. |
| 4323609 | Es wurde ein Problem behoben, bei dem das Hochladen einer signierten Vereinbarung auf der Verwaltungsseite nicht den Webhook AGREEMENT_WORKFLOW_COMPLETED auslöste. |
| 4325142 | Es wurde ein Problem behoben, bei dem benutzerdefinierte E-Mail-Vorlagen nicht den korrekten Namenswert eines Teilnehmers wiedergaben, wenn dieser die Vereinbarung stornierte. |
| 4326747 | Es wurde ein Problem behoben, das dazu führen konnte, dass die Seite „Massenversand“ den Ladevorgang nicht abschloss und die Aktionen „Hochladen“ und „Senden“ nicht ausgeführt wurden. |
| 4326855 | Es wurde ein Problem behoben, das die Ablehnung der Genehmigung einer Vereinbarung durch die Empfänger verhinderte. |
| 4327000 | Es wurde ein Problem behoben, das dazu führen konnte, dass Smart-ID-Anmeldedaten nicht akzeptiert wurden und die Fehlermeldung auftrat, dass keine Algorithmen gefunden wurden. |
