Note sulla versione di Adobe Acrobat Sign: 2026
Adobe Acrobat Sign versione 17.0
Implementazione in produzione: 3 febbraio 2026
Implementazione in GovCloud: 10 febbraio 2026
Funzionalità migliorate
- Caselle di controllo raggruppate in authoring e modelli: i mittenti possono ora creare gruppi di caselle di controllo tramite i moderni ambienti di authoring Richiedi firma e Modelli libreria, con regole di convalida come le opzioni per selezionare esattamente, almeno, al massimo o un intervallo di X su Y. Invia in blocco, moduli web, e Flussi di lavoro personalizzati sono supportati tramite l'uso di Modelli libreria. Questo miglioramento garantisce una logica dei moduli coerente e migliora l'accuratezza dei dati in tutti i flussi di lavoro di firma.
- Intervalli IP consentiti – Controllo ampliato sull'accesso API e mobile - Gli amministratori ora possono controllare esplicitamente se le restrizioni IP si applicano ai client basati su API, incluse le applicazioni mobili Acrobat Sign e le integrazioni certificate.
- Supporto per l'autenticazione per la firma elettronica moderna – La firma elettronica moderna ora supporta tre metodi di autenticazione: autenticazione Acrobat Sign, password e 2FA basata su telefono.
- Aggiunta di Gruppi di Destinatari nel Routing Ibrido per la moderna Request Signature – I gruppi di destinatari possono ora essere inclusi nel routing ibrido, consentendo a più destinatari o gruppi di agire in parallelo all'interno dello stesso passaggio di routing. Le modalità di gruppo supportano il completamento dell'azione da parte di uno o tutti i membri, offrendo maggiore flessibilità per flussi di lavoro di approvazione e firma complessi.
- Copia accordi terminali inviati da Richiedi firma—I mittenti possono ora creare una nuova bozza di accordo copiando un accordo precedentemente completato, annullato o scaduto. Tutti i destinatari, le impostazioni, i file e i campi del modulo vengono precompilati automaticamente. L'accordo copiato si apre nella pagina Componi per modifiche rapide prima dell'invio, riducendo i tempi di configurazione, minimizzando gli errori e migliorando la produttività per flussi di lavoro ripetitivi come rinnovi o correzioni.
- Disabilita il collegamento Scarica accordo per accordi in corso – Gli amministratori ora possono rimuovere il collegamento "Scarica una copia" dalle pagine di conferma post-firma a livello di account o gruppo, impedendo ai destinatari di scaricare accordi dalla pagina post-firma.
- Scheda Risorse nella navigazione superiore – Una nuova pagina Risorse è disponibile nella navigazione superiore per amministratori e utenti, fornendo accesso diretto ai contenuti formativi di Acrobat Sign, webinar, blog e video sugli aggiornamenti del prodotto. La pagina organizza i tutorial per valore tonale utente—principiante, esperto e amministratore—e si collega direttamente alla documentazione di supporto aggiuntiva.
- Partecipazione dinamica per accordi in corso - Rimozione destinatari – I mittenti possono ora rimuovere i destinatari dagli accordi già in corso senza annullare o riavviare la Transazione. Quando un destinatario viene rimosso, Acrobat Sign revoca automaticamente il suo accesso, aggiorna i promemoria, le tracce di controllo, rimuove i campi assegnati e riporta l'accordo senza problemi al suo stato di firma primario. Questa flessibilità aiuta le organizzazioni a mantenere l'accuratezza nei flussi di lavoro di routing live—come quando un firmatario diventa non disponibile—preservando l'integrità legale, la conformità e una cronologia di audit completa.
- Richiedi firme digitali per singoli destinatari durante la configurazione dell'accordo -I mittenti possono ora richiedere firme digitali per destinatari selezionati, garantendo requisiti di firma più rigorosi dove necessario senza impattare altri destinatari. L'esperienza di firma si adatta automaticamente, applicando i campi di firma digitale richiesti ed esponendo i controlli di identità quando supportati, riducendo gli errori e migliorando la conformità per flussi di lavoro regolamentati.
- Provider di Identità Digitale come Metodi di Autenticazione Predefiniti – Gli amministratori possono ora selezionare un provider Digital Identity Gateway come metodo di autenticazione predefinito per i destinatari interni ed esterni nelle Impostazioni di invio. La configurazione si applica automaticamente ad accordi, moduli web, invii multipli e flussi di lavoro, garantendo una verifica coerente e conforme dei destinatari. Questo miglioramento semplifica la configurazione dell'autenticazione, applica le politiche di identità organizzative e migliora il supporto per clienti governativi ed enterprise che si affidano all'autenticazione basata su identità digitale.
- Campi modulo verificati utilizzando dati verificati dall'identità – Gli autori dei moduli possono ora creare campi modulo verificati che si popolano automaticamente con i dati restituiti da un provider di identità (come OneID) durante l'autenticazione del firmatario. Questi campi possono essere impostati come sola lettura o modificabili, garantendo che i dati di identità verificati vengano acquisiti con precisione e opzionalmente bloccati contro le modifiche (ad esempio, nome, indirizzo o numero di account). Questo rafforza la garanzia di identità, riduce gli errori di inserimento manuale e semplifica la conformità per flussi di lavoro che richiedono dati del firmatario validati.
- Gruppi di destinatari nel file CSV per Invia in blocco – I mittenti possono ora definire gruppi di destinatari direttamente all'interno del file CSV Invia in blocco, consentendo a più destinatari di agire nello stesso passaggio di routing. Ogni gruppo può essere configurato in modalità UNO o TUTTI, per richiedere che un membro o tutti i membri del gruppo debbano completare la propria azione prima che l’indirizzamento possa avanzare. Le definizioni dei gruppi, la convalida e il tracciamento delle verifiche vengono gestiti per ogni riga CSV, con errori segnalati tramite file di convalida scaricabili.
- Modello di libreria - Condivisione con più gruppi – La moderna esperienza Crea Modello di libreria ora supporta la condivisione dei modelli con più gruppi all'interno di un account, corrispondente alla funzionalità precedentemente disponibile nel flusso di lavoro classico. Gli utenti possono selezionare uno o più gruppi durante la creazione o la modifica di un modello, garantendo un comportamento coerente tra i gruppi. Questo miglioramento elimina il fallback all'esperienza classica, migliora la collaborazione e semplifica la gestione dei modelli per organizzazioni multi-gruppo.
- Allegati per tutti i destinatari che utilizzano firme digitali – Tutti i destinatari in un flusso di lavoro con firma digitale possono ora allegare file (non solo il primo firmatario). Un nuovo metodo di allegato che utilizza annotazioni Graffetta visualizza un’icona graffetta visibile nel documento e rimane compatibile con più firme digitali. Ogni allegato viene aggiunto prima che venga applicata la firma digitale del firmatario, preservando la validità della firma e fornendo un chiaro indicatore visivo dei file allegati. Questo miglioramento migliora l'integrità legale, la trasparenza e la coerenza tra i flussi di lavoro di firma elettronica e firma digitale.
Modifiche a livello di esperienza
- Notifiche di annullamento accordo del flusso di lavoro – Notifica di annullamento aggiornata per riflettere il comportamento del flusso di lavoro.
Quando annulli un accordo creato da flusso di lavoro, la casella di controllo “Notifica destinatari” non appare più. Le notifiche vengono sempre inviate in base alle Impostazioni del flusso di lavoro. Questo cambiamento adatta il messaggio per riflettere questo comportamento nella sfida di annullamento.
- Miglioramenti alla pagina di accesso - La pagina di accesso di Acrobat Sign ora offre un'esperienza più pulita e coerente. Non appena inserisci il tuo indirizzo e-mail, la pagina rileva automaticamente il tipo di account e ti indirizza al metodo di accesso corretto, rimuovendo passaggi non necessari e schermate legacy. Questo rende l’accesso più veloce, semplice e intuitivo per tutti.
- Nuovo formato e-mail per gli utenti Acrobat Sign Enterprise che accedono direttamente all’interfaccia web: Acrobat Sign ora applica un limite di 64 caratteri alla parte locale di un indirizzo e-mail (la porzione prima del simbolo “@”) quando si modifica un indirizzo e-mail esistente o si crea un nuovo utente.
Tutti gli utenti con una parte locale superiore a 64 caratteri sono stati valutati e determinati come inattivo o test ID Utente.
- Nuovo formato e-mail per gli utenti Acrobat Sign Enterprise che accedono direttamente all’interfaccia web: Acrobat Sign ora applica un limite di 64 caratteri alla parte locale di un indirizzo e-mail (la porzione prima del simbolo “@”) quando si modifica un indirizzo e-mail esistente o si crea un nuovo utente.
Nota che questa esperienza viene fornita attraverso un rilascio graduale basato sull'ambiente server Acrobat Sign. Il programma di rollout è pubblicato nella notifica tecnica Esperienza di accesso aggiornata.
- Abilita gestione dei dettagli utente per utenti inattivi – Gli amministratori possono ora modificare i dettagli degli utenti inattivi direttamente nell'interfaccia di amministrazione e attraverso caricamenti CSV senza riattivare gli account. Questo include l'aggiornamento delle assegnazioni di gruppo (sia per configurazioni a gruppo singolo che multiplo), la gestione dell'attributo "L'utente può firmare documenti" e l'esecuzione di modifiche in blocco per la conformità e la manutenzione dei record. Il cambiamento semplifica la gestione del ciclo di vita degli utenti enterprise, riduce il carico amministrativo e supporta un'organizzazione di gruppo più pulita e una gestione dei record allineata al GDPR.
Problemi risolti
| Problema | Descrizione |
|---|---|
| 4528600 | Riepilogo: le impostazioni di convalida dei campi non funzionano quando un livello di campo modulo è associato a un flusso di lavoro personalizzato. Le regole di convalida, come regex o limiti di intervallo numerico, vengono rimosse quando il flusso di lavoro viene avviato, causando l’accettazione di input non validi da parte dei campi. |
| Correzione: le regole di convalida ora vengono applicate correttamente quando i livelli per campi modulo sono inclusi nei flussi di lavoro personalizzati. I campi mantengono il proprio comportamento di convalida sia nell’esperienza di authoring classica che in quella nuova. Non è richiesta alcuna azione da parte degli utenti. | |
| 4528748 | Riepilogo: gli amministratori visualizzano occasionalmente un “Errore non gestito” quando aggiungono a un gruppo l’iscrizione di utenti appena sincronizzati (sincronizzazione Azure). Il groupID di alcuni nuovi utenti del gruppo è impostato come null |
| Correzione: se il gruppo di un utente è null dopo la creazione, viene inserito nel gruppo predefinito dell’account. | |
| 4529934 | Riepilogo: in Gestisci > Moduli web, “Scarica dati campo modulo” il caricamento continua senza mai terminare, specialmente sui moduli web con molti invii. La clientela Teams senza accesso API non può esportare i dati (ad esempio, 1-31 maggio) per il reporting |
| Correzione: è stata aggiunta l’esportazione CSV paginata e più veloce nell’interfaccia. I download dei dati di modulo vengono completati in modo affidabile per gli intervalli di date selezionati, senza bloccarsi. | |
| 4532186 | Riepilogo: nella nuova esperienza di authoring, l’evidenziazione del colore dei campi non corrisponde al comportamento dell’authoring classico. Quando sono coinvolti più destinatari, tutti i campi rimangono completamente colorati invece di attenuare i campi dei destinatari non selezionati. Questo rende difficile verificare le assegnazioni dei campi. |
| Correzione: è stata ripristinata la chiarezza visiva attenuando (opacità 20%) i campi che appartengono ai destinatari non selezionati. Questo replica la chiarezza dell’authoring classico, preservando al contempo il sistema di progettazione moderno. L’evidenziazione ora consente agli utenti di identificare facilmente i campi del destinatario attualmente selezionato e riduce il rischio di assegnazione errata. | |
| 4534061 | Riepilogo: il collegamento “Scarica una copia” appare nella pagina di conferma successiva alla firma anche quando l’impostazione dell’account o del gruppo sono configurate per disabilitarlo. |
| Correzione: è stata aggiunta una nuova impostazione per sopprimere esplicitamente l’opzione di download in tutte le pagine successive all’invio. La pagina post-firma ora rispetta correttamente l’impostazione di controllo del download, nascondendo il collegamento “Scarica una copia” quando l’impostazione è disabilitata. | |
| 4536347 | Riepilogo: nell’esperienza classica, i mittenti non potevano aggiungere un secondo file (o tentare nuovamente l’aggiunta di un file) quando avviavano determinati flussi di lavoro, impedendo gli invii dei flussi contenenti più documenti; ciò avveniva a causa di un errore nel modo in cui il selettore di file gestiva i modelli condivisi tra più gruppi. |
| Correzione: è stata corretta la gestione del selettore di file dei modelli condivisi tra più gruppi, in consentendo agli utenti di aggiungere ulteriori file o riprovarne la selezione nell’esperienza classica senza errori. | |
| 4537504 | Riepilogo: il documento firmato presentava un valore condizionale a discesa mancante anche se durante la firma era stato selezionato correttamente, a causa della logica di visibilità che valutava un campo dipendente nascosto e non manteneva il valore renderizzato nel PDF finale firmato. |
| Correzione: è stato aggiornato il rendering dei campi condizionali per risolvere correttamente le dipendenze di visibilità al momento della firma e per mantenere il valore del menu a discesa selezionato nel documento firmato quando le condizioni sono soddisfatte. | |
| 4537995 | Riepilogo: nei gruppi di destinatari, la modifica del metodo di autenticazione per utenti esterni veniva riportata a Telefono dopo il salvataggio, impedendo l’applicazione dell’e-mail con OTP, a causa di un errore nella gestione dello stato del front-end che sovrascriveva la selezione dell’utente. |
| Correzione: è stata corretta la logica dell’interfaccia utente dei gruppi di destinatari per mantenere e riapplicare correttamente il metodo di autenticazione selezionato tra le azioni di salvataggio, assicurando che il valore scelto venga mantenuto anziché essere reimpostato su quello predefinito. | |
| 4539214 | Riepilogo: nei flussi di lavoro personalizzati, un’etichetta di messaggio lunga causa la sovrapposizione del testo del messaggio e oscura il collegamento ipertestuale del modello di messaggio nella pagina di invio; ciò avviene a causa di una gestione impropria del layout del contenuto eccessivo dell’etichetta. |
| Correzione: è stata aggiornata la logica di layout della pagina di invio per limitare e mandare correttamente a capo le etichette lunghe dei messaggi, in modo che il collegamento ipertestuale del modello di messaggio rimanga visibile e accessibile. | |
| 4539854 | Riepilogo: alcuni firmatari vengono reindirizzati fuori dall’esperienza di firma quando aprono determinati accordi, a causa di un campo collegamento con struttura errata nel documento sottostante che non dispone di un attributo nome obbligatorio. |
| Correzione: il flusso di firma ora gestisce correttamente i campi collegamento senza nome assegnando un nome valido al momento dell’elaborazione, prevenendo errori e consentendo ai firmatari di completare gli accordi senza reindirizzamento. | |
| 4539858 | Riepilogo: sui dispositivi iOS, gli approvatori che utilizzano la tastiera cinese per scrittura manuale non riescono a completare l’approvazione perché il pulsante Approva rimane disabilitato dopo aver inserito il proprio nome; ciò avviene poiché la pagina di firma non rileva gli eventi di input della scrittura manuale come inserimento di testo valido. |
| Correzione: è stata aggiornata la logica di gestione dell’input per riconoscere l’input di testo basato sulla scrittura manuale su iOS, garantendo che il pulsante Approva si abiliti correttamente una volta inseriti caratteri validi. | |
| 4540392 | Riepilogo: gli amministratori visualizzano occasionalmente errori HTTP 400 e i gruppi di destinatari non vengono visualizzati nei flussi di lavoro, anche se i gruppi esistono e l’accesso è configurato correttamente; ciò avviene a causa delle intestazioni delle richieste che superano il limite di dimensione della piattaforma quando gli utenti appartengono a un numero elevato di gruppi. |
| Correzione: è stato aumentato il limite di dimensione delle intestazioni delle richieste lato server, affinché le ricerche nei gruppi di destinatari non causino più errori quando gli utenti sono iscritti a più gruppi. | |
| 4541258 | Riepilogo: nell’interfaccia utente di sincronizzazione di Produzione o Sandbox, gli amministratori potevano visualizzare solo i primi 100 modelli, mentre quelli aggiuntivi non erano presenti negli elenchi Locale e Remoto, a causa del caricamento di un set di dati limitato nella pagina di sincronizzazione e della funzione di ricerca che filtrava solo i modelli già caricati nel browser. |
| Correzione: è stata aggiornata l’interfaccia utente di sincronizzazione, in modo che l’inserimento del testo nel campo di ricerca carichi tutti i modelli dell’ambiente selezionato (fino a 5.000), garantendo che anche i modelli successivi ai primi 100 siano disponibili per la ricerca e la selezione. | |
| 4541739 | Riepilogo: i destinatari sostituiti non potevano eseguire la firma digitale e visualizzavano “L’accordo non può essere firmato digitalmente poiché non è nella fase di firma digitale”, a causa del flusso di lavoro che non trasferiva i firmatari sostituiti futuri alla fase di firma digitale quando erano presenti i relativi campi di firma. |
| Correzione: il flusso di lavoro di firma è stato aggiornato per far passare correttamente i destinatari sostituiti o delegati alla fase di firma digitale quando sono presenti campi di firma digitale, consentendo loro di firmare e completare l’accordo. | |
| 4541849 | Riepilogo: i campi di testo a riga singola con ridimensionamento automatico del font e precompilati con caratteri multibyte, venivano troncati nei PDF firmati, provocando il taglio di parte del testo a causa di un ridimensionamento errato durante il rendering del PDF. |
| Correzione: è stata corretta la misurazione del testo e il comportamento di ridimensionamento automatico del font per i caratteri multibyte, in modo che l’intero valore venga adattato al campo senza troncamenti. | |
| 4542574 | Riepilogo: la modifica di un modello di libreria consentiva ai campi a discesa obbligatori di includere valori non abbinati, causando l’indisponibilità del pulsante Fai clic per firmare durante la firma, quando tali valori venivano selezionati; ciò avveniva a causa della mancanza di una convalida che assicurasse il corretto abbinamento tra valori visualizzati a discesa e i valori di esportazione. |
| Correzione: la modifica del modello ora applica la convalida sui campi a discesa in modo che solo i valori correttamente abbinati possano essere salvati, evitando l’inserimento di voci non abbinate e garantendo che le selezioni obbligatorie del menu a discesa non blocchino la firma. | |
| 4542942 | Riepilogo: nei moduli web, i campi obbligatori disabilitati dalla logica condizionale continuavano a mostrare l’asterisco obbligatorio, inducendo i firmatari a ritenere che l’input fosse ancora richiesto, a causa dell’interfaccia utente che non aggiornava gli indicatori obbligatori quando i campi erano disabilitati. È stato identificato un problema separato di allineamento della firma su dispositivi mobili ma affrontato sotto un ambito diverso. |
| Correzione: l’interfaccia utente dei moduli web ora nasconde l’asterisco obbligatorio quando un campo è disabilitato dalla logica condizionale, garantendo che gli indicatori obbligatori riflettano accuratamente se è previsto l’input da parte del firmatario. | |
| 4543157 | Riepilogo: nella vista In corso della pagina Gestisci, la colonna Destinatari continuava a mostrare il nome del delegante dopo che un ruolo di firma era stato delegato, anche se un altro firmatario stava firmando attivamente; ciò avveniva a causa dell’interfaccia utente che non aggiornava il destinatario visualizzato per riflettere il delegato corrente. |
| Correzione: è stata aggiornata la logica della pagina Gestisci affinché la colonna Destinatari visualizzi ora il nome del delegato attivo quando un ruolo di firma viene delegato, garantendo che la vista In corso rifletta accuratamente chi sta attualmente firmando. | |
| 4543253 | Riepilogo: nell’esperienza classica del flusso di lavoro, i campi assegnati al testimone (firma, nome, data) non venivano più visualizzati dopo il salvataggio di un accordo nello stato Bozza, anche se erano presenti nel back-end; ciò era dovuto a un errore della logica di rendering della bozza che impediva il ripristino dei campi del testimone quando veniva salvato il processo di avanzamento. |
| Correzione: è stata corretta la logica di rendering della bozza per preservare e visualizzare tutti i campi assegnati ai testimoni dopo il salvataggio dell’avanzamento, garantendo che gli accordi aperti nello stato Bozza mantengano la stessa visibilità dei campi presente durante l’authoring e la firma. | |
| 4543513 | Riepilogo: gli utenti non riuscivano ad inviare accordi nell’interfaccia utente web di Sign a causa dell’errore “Impostazioni locali non valide o mancanti”, dovuto a una convalida delle impostazioni locali che applicava erroneamente le regole a livello API nell’interfaccia web quando tali impostazioni relative al gruppo di invio differivano da quelle ereditate dal gruppo principale dall’utente. |
| Correzione: la convalida delle impostazioni locali è stata corretta in modo che l’interfaccia web di Sign risolva e accetti correttamente le combinazioni valide di impostazioni locali di gruppo e utente, impedendo che le restrizioni delle impostazioni locali solo API blocchino l’invio degli accordi nell’esperienza web. | |
| 4543592 | Riepilogo: alcuni rapporti di audit visualizzavano “Destinatario autenticato con Adobe Acrobat Sign” dopo “Documento firmato elettronicamente” e “Accordo completato”, a causa della memorizzazione degli eventi con marche temporali a livello di secondi che faceva apparire le azioni di autenticazione e firma che si verificavano nello stesso secondo con un ordine errato. |
| Correzione: è stata aggiornata la registrazione degli eventi di audit per memorizzare e visualizzare le marche temporali con una precisione al millisecondo, garantendo che gli eventi di autenticazione, firma e completamento siano sequenziati correttamente nel rapporto di audit. | |
| 4543617 | Riepilogo: la creazione di un modello da un accordo avvia l’esperienza classica anziché quella nuova, nonostante questa sia quella predefinita, a causa del fatto che l’azione viene ancora instradata verso il flusso di authoring legacy. |
| Correzione: è stata aggiornata l’azione “Crea modello da accordo” affinché venga aperta nella nuova esperienza, allineando il comportamento della CTA con l’UX predefinita ed evitando cambi di contesto imprevisti per gli utenti. | |
| 4544564 | Riepilogo: i campi nascosti aggiunti o aggiornati tramite API (visible:false) venivano renderizzati come visibili nell’esperienza moderna di firma elettronica. L’interfaccia utente di firma ignorava il flag di visibilità dei campi, pertanto i destinatari potevano visualizzare campi che dovevano rimanere nascosti. |
| Correzione: è stata aggiornata l’interfaccia utente moderna di firma elettronica per filtrare i campi di tipo visible:false nella logica di rendering e navigazione, in modo che i campi nascosti non vengano mai visualizzati e non influenzino il comportamento della pagina. | |
| 4544571 | Riepilogo: l’opzione di consegna WhatsApp non era presente nelle impostazioni di invio anche quando WhatsApp era abilitato per l’account e disponibile durante l’invio degli accordi, causando comportamenti incoerenti e confusione per gli amministratori. |
| Correzione: l’opzione di consegna WhatsApp è stata ripristinata nelle impostazioni di invio ovunque la funzione sia disponibile, garantendo visibilità e configurazione coerenti tra le impostazioni di amministrazione e l’esperienza di invio degli accordi. | |
| 4545381 | Riepilogo: il font Roboto non era presente nella nuova esperienza Richiedi firma, pur essendo disponibile in quella classica, in quanto la nuova esperienza di authoring non includeva tutti i font legacy supportati. |
| Correzione: Roboto è stato aggiunto all’elenco dei font nella nuova esperienza Richiedi firma, ripristinando la parità dei font con l’esperienza classica e consentendo una formattazione coerente durante la creazione degli accordi. | |
| 4545484 | Riepilogo: alcuni amministratori non riuscivano ad accedere a gruppi di destinatari o a crearli da Amministrazione > Rubrica a causa di un errore nelle richieste di back-end, generando un errore 400 durante il caricamento dei dati dei gruppi di destinatari. Il problema bloccava la configurazione iniziale dei gruppi destinatari per gli amministratori interessati. |
| Correzione: la gestione delle richieste di back-end è stata corretta in modo che la ricerca e la creazione di gruppi di destinatari non generi più errori 400. Gli amministratori ora possono accedere e gestire in modo affidabile i gruppi destinatari, indipendentemente dalla rete o dalla posizione. | |
| 4545547 | Riepilogo: gli accordi creati da PDF di AutoCAD non venivano inviati quando veniva aggiunto un campo di firma digitale, mostrando un errore generico di invio; ciò era dovuto al sistema che non gestiva correttamente la rotazione delle pagine durante la convalida del posizionamento del campo della firma digitale. |
| Correzione: le coordinate del campo di firma digitale sono ora regolate per tenere conto delle pagine ruotate, garantendo che i campi vengano convalidati in base ai bordi corretti della pagina, in modo che i PDF generati da AutoCAD possano essere inviati correttamente con le firme digitali. | |
| 4545894 | Riepilogo: quando viene utilizzato un gruppo di destinatari e nessun campo firma viene posizionato manualmente, il blocco firma generato automaticamente visualizza il testo dell’indirizzo e-mail con dimensioni molto piccole. Il testo diventa progressivamente più piccolo, man mano che vengono aggiunti più destinatari al gruppo. |
| Correzione: il blocco firma generato automaticamente ora esegue correttamente il rendering dell’indirizzo e-mail con dimensioni normali e leggibili, indipendentemente dal numero di destinatari inclusi nel gruppo destinatari. | |
| 4546085 | Riepilogo: utilizzando Aggiungi me stesso nella nuova esperienza Richiedi firma, gli indirizzi e-mail contenenti un apostrofo vengono visualizzati in modo errato. L’indirizzo con struttura errata impedisce l’invio dell’accordo, a meno che l’indirizzo e-mail non venga reinserito manualmente o non venga utilizzata la funzione di invio classica. |
| Correzione: gli indirizzi e-mail con apostrofi ora vengono decodificati e visualizzati correttamente quando viene selezionato Aggiungi me stesso nella nuova esperienza Richiedi firma, consentendo l’invio degli accordi senza correzioni manuali. | |
| 4546110 | Riepilogo: nella nuova esperienza di authoring dei modelli, l’aggiunta di un campo di collegamento ipertestuale assegnato a un partecipante specifico comporta l’impossibilità di salvare il modello. Lo stesso campo funziona quando è assegnato a tutti i partecipanti o quando viene utilizzata l’esperienza classica. |
| Correzione: i campi di collegamento ipertestuale ora supportano le assegnazioni dei partecipanti segnaposto nella nuova esperienza Modello, consentendo il corretto salvataggio dei modelli quando il campo è assegnato a un partecipante specifico. | |
| 4546257 | Riepilogo: nell’ambiente Sandbox, gli accordi inviati tramite un’API di applicazione personalizzata mostrano erroneamente il pulsante Indietro nella pagina di authoring, poiché la Sandbox carica le impostazioni da un’applicazione gestita da Adobe con authoring fluido abilitato, a differenza degli ambienti Swagger o Produzione. |
| Correzione: il comportamento della Sandbox è stato allineato a quello di Produzione e Swagger, garantendo che la pagina di authoring rispetti le impostazioni dell’applicazione previste ed evitando che venga visualizzato il pulsante Indietro negli accordi inviati tramite API di applicazioni personalizzate. | |
| 4546547 | Riepilogo: i moduli web non riuscivano ad aggiornare il controfirmatario e restituivano un errore generico a causa della mancanza di un flag interno obbligatorio nei record utente meno recenti, causando l’elaborazione di un valore null durante la sostituzione del controfirmatario. |
| Correzione: la logica di aggiornamento del controfirmatario è stata rafforzata con una gestione a prova di null, consentendo ai moduli web di sostituire correttamente i controfirmatari anche quando i record utente meno recenti non contengono il flag interno previsto. | |
| 4546553 | Riepilogo: se la nuova esperienza Crea modello era abilitata, gli utenti assegnati a più gruppi potevano comunque creare modelli in un gruppo per cui tale funzione di creazione era disabilitata. Questo permetteva di aggirare le restrizioni a livello di gruppo. |
| Correzione: la creazione di modelli ora applica le autorizzazioni a livello di gruppo in modo coerente tra la nuova esperienza e la classica. Gli utenti non possono più creare modelli in gruppi in cui la creazione è disabilitata, anche se appartengono ad altri gruppi in cui tale autorizzazione è abilitata. | |
| 4547744 | Riepilogo: gli amministratori di gruppo potevano assegnare diritti di amministratore account agli utenti tramite la nuova pagina Gestione utenti. Questo superava il loro ambito di autorizzazione e creava un rischio di conformità, poiché consentiva l’elevazione dei privilegi oltre il ruolo di amministratore di gruppo. |
| Correzione: il controllo di selezione del ruolo non è più disponibile per gli amministratori di gruppo. Solo gli amministratori account esistenti possono assegnare o revocare i diritti di amministratore account, garantendo che le modifiche ai ruoli siano in linea con i limiti delle autorizzazioni. | |
| 4547796 | Riepilogo: alcuni mittenti che utilizzano l’interfaccia utente in polacco ricevono occasionalmente un’e-mail di conferma con testo errato “Impossibile fornire una firma digitale”, anche se l’accordo viene inviato e firmato normalmente. |
| Correzione: le traduzioni in polacco delle e-mail di conferma del mittente sono state corrette, in modo che il messaggio visualizzi “Inviato per la firma” anziché il testo errato “Impossibile fornire una firma digitale”. | |
| 4548315 | Riepilogo: nel nuovo flusso di lavoro di invio, quando il mittente è incluso come destinatario in CC non viene mostrato alcun errore di convalida e le notifiche e-mail CC non vengono inviate a nessun destinatario elencato dopo il mittente nell’elenco CC. Questo comportamento differisce dal flusso di lavoro classico e può far sì che i destinatari in CC non ricevano le notifiche. |
| Correzione: è stata aggiornata la logica del nuovo flusso di lavoro di invio affinché tutti i destinatari in CC, ad eccezione del mittente, ricevano le notifiche e-mail CC indipendentemente dalla rispettiva posizione nell’elenco CC, allineando il comportamento ai risultati previsti. | |
| 4548583 | Riepilogo: non era possibile abilitare PDF/A per un gruppo se il gruppo predefinito dell’utente aveva la funzione di firma manuale abilitata, anche se in fase di modifica questa era disabilitata per il gruppo. Questo bloccava la configurazione valida dei PDF/A per i gruppi non predefiniti. |
| Correzione: è stata aggiornata la convalida affinché vengano verificate le impostazioni delle firme manuali sul gruppo in fase di modifica, anziché sul gruppo predefinito dell’utente, permettendo di abilitare correttamente i PDF/A dove consentito. | |
| 4549337 | Riepilogo: le notifiche SMS per gli accordi annullati venivano soppresse quando l’impostazione E-mail accordo annullato era disabilitata. Questo impediva alla clientela con le notifiche e-mail disabilitate di inviare gli avvisi SMS di annullamento richiesti. |
| Correzione: le notifiche di annullamento via SMS e WhatsApp sono state scollegate dall’impostazione e-mail introducendo un controllo di notifica dedicato, consentendo la consegna tramite SMS degli accordi annullati anche quando le notifiche e-mail sono disabilitate. | |
| 4549472 | Riepilogo: in Acrobat Sign per la Pubblica Amministrazione, gli utenti non potevano creare modelli riutilizzabili utilizzando la nuova esperienza Crea modello. Dopo il caricamento di un documento, il flusso di lavoro si bloccava su una schermata vuota, impedendo la creazione del modello. |
| Correzione: è stata ripristinata la dipendenza di authoring mancante necessaria per la nuova esperienza Crea modello in ambienti Gov, per permettere il corretto caricamento della schermata di authoring e la corretta creazione dei modelli. | |
| 4549862 | Riepilogo: quando la pagina di destinazione è impostata sulla nuova esperienza di richiesta firme, il messaggio di avviso configurato per accedere non viene visualizzato dopo l’accesso. Questo impedisce alle organizzazioni di mostrare avvisi critici di manutenzione o interruzione quando gli utenti arrivano direttamente sulla pagina Invia. |
| Correzione: ripristinato il supporto per la visualizzazione del messaggio di avvertenza di login nell’esperienza Nuova richiesta di firma. Quando gli utenti arrivano alla pagina Invia dopo l’accesso, il messaggio di avvertenza configurato ora appare come notifica, corrispondendo al comportamento precedente e alle aspettative della clientela. | |
| 4550175 | Riepilogo: premendo Invio dopo aver inserito un numero di telefono per l’autenticazione telefonica in un flusso di lavoro, il modulo viene inviato troppo presto e genera un errore di sistema. Ciò interrompe il normale flusso di lavoro perché il modulo viene inviato invece di attendere la conferma esplicita. |
| Correzione: aggiornata la finestra di dialogo del destinatario per impedire l’invio del modulo premendo Invio per i campi di autenticazione telefonica, assicurando che gli utenti rimangano nella finestra di dialogo e debbano fare clic su Continua, eliminando l’interruzione involontaria del flusso di lavoro. | |
| 4550302 | Riepilogo: le e-mail tedesche di richiesta firma e promemoria utilizzavano forme di cortesia incoerenti, alternando tra il “Du” informale e il “Sie” formale all’interno dello stesso messaggio, causando formulazioni confuse e poco professionali. |
| Correzione: aggiornate le traduzioni delle e-mail tedesche per utilizzare una forma di cortesia unica e coerente in tutto il modello, garantendo un linguaggio uniforme e prevedibile in tutte le e-mail di richiesta firma e promemoria. | |
| 4550556 | Riepilogo: gli accordi contenenti PDF di grandi dimensioni non riuscivano ad essere inviati quando venivano aggiunti campi di firma digitale, restituendo un errore durante l’authoring a causa della rotazione delle pagine e della gestione delle dimensioni nel posizionamento della firma digitale. |
| Correzione: aggiornata l’elaborazione dei campi di firma digitale per gestire correttamente le pagine ruotate di grande formato, consentendo agli accordi di grandi dimensioni di essere inviati correttamente con firme digitali applicate. | |
| 4550579 | Riepilogo: quando un accordo veniva completato rimuovendo gli ultimi destinatari rimanenti durante uno stato di revisione, il sistema non generava l’evento AGREEMENT_WORKFLOW_COMPLETED, quindi non veniva inviata alcuna notifica webhook, interrompendo i flussi di lavoro che si basano su questo evento per rilevare il completamento. |
| Correzione: aggiornata la gestione degli eventi in modo che gli accordi completati tramite rimozione del destinatario in revisione ora generino gli eventi di completamento appropriati, garantendo che i webhook AGREEMENT_WORKFLOW_COMPLETED vengano attivati come previsto. | |
| 4550998 | Riepilogo: le caselle di controllo precompilate apparivano selezionate nell’authoring ma non erano selezionate per i firmatari perché i valori delle caselle di controllo erano memorizzati come stringhe di testo non vuote invece di stati espliciti SÌ/NO, facendo sì che l’esperienza di firma le interpretasse come non selezionate. |
| Correzione: aggiornata la gestione dei valori delle caselle di controllo in modo che qualsiasi valore precompilato non vuoto venga interpretato come selezionato e i valori vuoti o mancanti come non selezionati, garantendo che gli stati delle caselle di controllo rimangano coerenti per i firmatari. |
Versione Adobe Acrobat Sign v17.0.1
Implementazione in produzione: 17 marzo 2026
Implementazione GovCloud: 19 marzo 2026
Funzionalità migliorate
- Crea una copia – Punti di accesso ampliati, riutilizzo più rapido degli accordi.
La funzione Crea una copia è ora disponibile direttamente dai filtri In corso e In attesa del tuo intervento nella pagina Gestisci, oltre che dalla pagina di conferma post-invio. Questi punti di accesso aggiuntivi semplificano il riutilizzo degli accordi in più fasi del ciclo di vita dell’invio, riducendo la necessità di ricominciare da capo.
Nota: con questa versione, i controlli amministrativi per disabilitare questa funzione verranno rimossi dal menu di amministrazione per rendere Crea una copia una funzionalità standard disponibile per tutti gli utenti idonei.
Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: account e gruppo; abilitata per impostazione predefinita.
Modifiche a livello di esperienza
- Visibilità scadenza chiave di integrazione: le date di scadenza sono ora mostrate nella scheda Token di accesso
La scheda Token di accesso, nel menu Preferenze personali e viene indicata per ciascuna chiave di integrazione. Questo offre utenti e amministratori una visibilità più chiara sulla durata delle chiavi e sulle tempistiche di sostituzione, rendendo più semplice il monitoraggio quelle già esistenti ed evitando interruzioni impreviste quando una chiave raggiunge la fine del suo periodo di validità di 10 anni.
Ambienti disponibili: Sandbox, Commercial, Government Livelli di servizio disponibili:Acrobat Sign Solutions Ambito di configurazione: API
Aggiornamenti API REST/Webhook
Gli aggiornamenti delle API e del webhook per questa versione sono disponibili nella Documentazione delle API di Acrobat Sign.
- Visualizzazione e-mail personalizzata OEM 2.0: identità di mittente e destinatario più chiara nelle esperienze integrate e consegna corretta delle email.
Per i partner OEM 2.0 che utilizzano flussi di lavoro integrati, Acrobat Sign può ora visualizzare l’indirizzo e-mail personalizzato di un utente invece dell’e-mail registrata dal partner nelle superfici dell’interfaccia e nelle notifiche principali. Gli accordi, le code come “In attesa di te” e le e-mail “Rivedi e firma” riflettono costantemente l’identità personalizzata, al contempo preservando internamente l’e-mail registrata per autenticazione e autorizzazioni. Questo consente una migliore chiarezza per mittenti e firmatari e impedisce l’invio di e-mail a indirizzi registrati non recapitabili.
Ambienti disponibili: Sandbox, Commercial | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API - partner OEM 2.0; solo su richiesta
- Notifica webhook per errori di consegna SMS – Visibilità in tempo reale degli invii SMS non riusciti, correzione automatica e parità con i mancati recapiti e-mail.
Acrobat Sign ora emette un nuovo evento webhook, AGREEMENT_PHONE_BOUNCED, quando un accordo inviato tramite SMS non può essere consegnato a causa di problemi come numeri di telefono non validi, rifiuto del gestore o linee bloccate. Questo consente alla clientela di rilevare gli errori di consegna SMS quasi in tempo reale e di attivare automaticamente azioni di follow-up come correggere i numeri di telefono, riprovare la consegna o aprire casi di supporto, eliminando i punti ciechi e riducendo i ritardi nei flussi di lavoro di firma mobile-first.
Ambienti disponibili: Sandbox, Commercial, Government Livelli di servizio disponibili: Acrobat Sign Solutions Ambito di configurazione: API
- Payload webhook: aggiunto campo condizionale extendedStatus del partecipante per aggiornamenti dinamici della partecipazione, migliorando la visibilità dello stato del partecipante.
Le notifiche webhook ora includono un campo extendedStatus in ogni oggetto partecipante (memberInfos[]) quando il mittente modifica un accordo in corso utilizzando la partecipazione dinamica. Questo campo fornisce dettagli aggiuntivi del ciclo di vita del partecipante lasciando invariato il campo stato esistente per la compatibilità con le versioni precedenti.
Valori status (invariati): ACTIVE, REPLACED.
Valori extendedStatus: ACTIVE, REPLACED, REMOVED, COMPLETED.
Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API
Problemi risolti
| Problema | Descrizione |
|---|---|
| 4543515 | Riepilogo: Un evento webhook di mancato recapito e-mail può essere generato erroneamente per un firmatario valido dopo che il firmatario ha firmato con successo e l’accordo avanza al passaggio successivo. Questo può verificarsi quando un delegato nello stesso gruppo di firma ha un indirizzo e-mail non valido e il mittente sostituisce il delegante originale. In questi casi, il sistema può attribuire erroneamente l’evento di mancato recapito “Firmato per conto di...” al firmatario valido anziché al partecipante la cui e-mail effettivamente non viene recapitata. |
| Correzione: la logica di attribuzione dell’evento è stata corretta in modo che gli eventi di mancato recapito e-mail siano associati solo al partecipante la cui e-mail effettivamente non viene recapitata. Un evento di mancato recapito non viene più generato per un firmatario valido che ha già completato la firma, e le notifiche webhook ora riflettono il partecipante e l’indirizzo e-mail corretti. | |
| 4544548 | Riepilogo: le chiavi di integrazione create tramite l’interfaccia utente web possono scadere dopo 10 anni, anche se la pagina di creazione indica che la chiave fornisce un “accesso permanente”. Quando una chiave raggiunge la durata di 10 anni, le chiamate API iniziano a restituire un errore di token scaduto, che può interrompere inaspettatamente le integrazioni esistenti. |
| Correzione: la messaggistica dell’interfaccia utente è stata aggiornata per rimuovere la dicitura “accesso permanente” e visualizzare chiaramente la data di scadenza per le chiavi di integrazione. Il testo aggiornato ora indica che la chiave mantiene l’accesso fino alla data di scadenza o fino alla revoca manuale, fornendo trasparenza sulla durata predefinita di 10 anni. | |
| 4546301 | Riepilogo: La consegna degli eventi webhook potrebbe subire ritardi fino a diverse ore per accordi con documenti molto grandi, anche quando la creazione dell’accordo viene completata e i passaggi di elaborazione iniziali sembrano terminare in pochi minuti. Durante la finestra di ritardo, il servizio di consegna webhook potrebbe ricevere ripetutamente risposte DOCUMENT_NOT_AVAILABLE quando tenta di recuperare i documenti dell’accordo, e l’evento webhook potrebbe non essere consegnato fino a quando il servizio non smette di riprovare o i documenti non diventano disponibili. |
| Correzione: La gestione della disponibilità dei documenti è stata corretta in modo che gli accordi di grandi dimensioni passino in modo affidabile a uno stato in cui i documenti sono recuperabili senza risposte DOCUMENT_NOT_AVAILABLE prolungate. Di conseguenza, gli eventi webhook vengono consegnati senza i ritardi di più ore, causati dai nuovi tentativi di recupero dei documenti non disponibili. | |
| 4547823 | Riepilogo: il messaggio privato di un destinatario potrebbe non essere visualizzato per alcuni firmatari quando un accordo viene creato in stato di Authoring tramite l’API e poi modificato tramite l’esperienza Gestisci. In questo scenario, l’interfaccia utente potrebbe mostrare il valore del messaggio privato come “Nessuno” o vuoto anche se i dati dell’accordo includono il valore corretto del messaggio privato. Questo comportamento si verifica in scenari di account condivisi dove un utente passa all’account di un altro utente per modificare la bozza e può interessare solo destinatari specifici, mentre altri vengono visualizzati correttamente. |
| Correzione: è stato aggiunto un controllo per recuperare il contesto di condivisione attivo e restituire il messaggio privato per gli utenti condivisi autorizzati. Di conseguenza, il valore del messaggio privato ora viene visualizzato correttamente quando si visualizza o si invia una bozza creata tramite API dal flusso Authoring. | |
| 4548274 | Riepilogo: la data di modifica per i modelli di libreria potrebbe non aggiornarsi dopo che un modello viene modificato e salvato nella nuova esperienza modello. Gli utenti potrebbero visualizzare campi appena aggiunti o aggiornati sul modello, ma la data di modifica rimane invariata nell’interfaccia Gestisci e nelle viste amministrative, facendo sembrare che il modello non sia stato modificato di recente. Questo accade perché la nuova esperienza aggiorna i campi del modulo attraverso un percorso che non aggiorna anche la marca temporale di modifica del modello. |
| Correzione: il comportamento di aggiornamento della data di modifica è stato allineato tra la nuova esperienza modello e le operazioni API correlate. Il percorso di codice che salva le modifiche ai campi del modello ora aggiorna anche la data di modifica del modello, in modo che rifletta l’ora effettiva della modifica più recente. | |
| 4548564 | Riepilogo: le firme e i campi del modulo potrebbero risultare invisibili nel PDF firmato quando vengono posizionati sopra annotazioni con timbro preesistenti nel documento di origine. Nei modelli interessati, le annotazioni con timbro si sovrappongono oppure oscurano i campi interattivi durante l’elaborazione, nascondendo le firme completate ed altri campi nel documento firmato finale. |
| Correzione: la gestione delle annotazioni con timbro è stata aggiornata per elaborare e appiattire quelle preesistenti in modo sicuro, così da non oscurare più i campi del modulo o le firme. I campi posizionati su aree con timbro ora rimangono visibili durante la firma e nel PDF completamente eseguito. | |
| 4549103 | Riepilogo: Un evento di mancato recapito e-mail potrebbe essere registrato nuovamente per un destinatario precedentemente errato dopo che il mittente sostituisce quel destinatario con un indirizzo e-mail valido. In alcuni casi, l’audit trail potrebbe mostrare un secondo evento di mancato recapito per la vecchia e-mail, e lo stato dell’accordo potrebbe riflettere “e-mail non recapitata” anche se il nuovo destinatario riceve, visualizza o firma correttamente l’accordo. Questo comportamento può far sembrare che l’accordo stia ancora puntando sia al vecchio che al nuovo indirizzo e-mail. |
| Correzione: il flusso di lavoro di sostituzione del firmatario è stato aggiornato per impedire l’invio di e-mail di notifica aggiuntive a un destinatario sostituito la cui e-mail ha già avuto un mancato recapito. Il sistema ora controlla la cronologia dei mancati recapiti precedenti prima di inviare notifiche relative alla sostituzione, assicurando che non vengano generati nuovi eventi di mancato recapito per il vecchio indirizzo e-mail dopo la sostituzione. | |
| 4549306 | Riepilogo: Gli utenti i cui indirizzi e-mail contengono determinati caratteri speciali (ad esempio, un apostrofo) potrebbero non riuscire ad accedere dalle pagine di accesso pubbliche generiche adobesign.com o echosign.com. Dopo aver immesso l’indirizzo e-mail e aver fatto clic nel campo password, la pagina potrebbe ricaricarsi e cancellare il campo e-mail invece di reindirizzare l’utente alla partizione corretta o alla pagina di accesso SSO. Questo impedisce agli utenti interessati di completare l’autenticazione e blocca le integrazioni che si basano sull’endpoint di accesso pubblico. |
| Correzione: la logica di risoluzione della partizione di accesso è stata corretta per gestire e decodificare correttamente gli indirizzi e-mail contenenti caratteri speciali prima di costruire l’URL di reindirizzamento tra partizioni. Gli utenti con formati e-mail interessati vengono ora reindirizzati correttamente alla partizione designata e alla pagina di accesso SSO senza che il campo e-mail venga cancellato. | |
| 4549331 | Riepilogo: Le firme e altri campi del modulo potrebbero apparire mancanti o invisibili nel PDF firmato quando determinate funzionalità di elaborazione del documento sono abilitate e il PDF di origine contiene coordinate della casella di pagina non valide (ad esempio, valori CropBox o MediaBox non corretti). In questo scenario, i campi che si basano sulle coordinate della pagina potrebbero essere visualizzati al di fuori dell’area della pagina visibile, facendo apparire le firme completate come mancanti anche se la firma viene eseguita correttamente. |
| Correzione: La gestione della casella di pagina PDF è stata corretta per normalizzare in modo sicuro i valori CropBox e MediaBox non validi durante l’elaborazione del documento. Di conseguenza, il posizionamento della firma e del campo del modulo ora si allinea all’area della pagina visibile e i PDF firmati visualizzano le firme come previsto. | |
| 4550367 | Riepilogo: la creazione di un modulo web potrebbe non riuscire presentando un “Errore del server” generico dopo aver selezionato Anteprima e Aggiungi campi quando l’autenticazione del firmatario predefinita del gruppo del mittente è impostata su Telefono e l’account non dispone di quota disponibile di autenticazione telefonica, anche se l’autenticazione del firmatario del modulo web è impostata su un metodo diverso da quello telefonico (ad esempio, Adobe Sign). Di conseguenza, a tutti gli utenti dell’account interessato potrebbe essere impedito di creare moduli web in tutti i documenti. |
| Correzione: la creazione del modulo web ora valuta la quota solo per il metodo di autenticazione effettivamente configurato per il firmatario del modulo web e non applica più i controlli della quota di autenticazione telefonica basati esclusivamente sull’impostazione di autenticazione predefinita del gruppo. Questo evita falsi errori di esaurimento della quota e consente la normale creazione dei moduli web. | |
| 4551011 | Riepilogo: Quando un mittente carica determinati PDF scansionati, aggiunge campi firma e invia l’accordo, il PDF firmato potrebbe non visualizzare firme visibili dopo il completamento della firma. Questo comportamento può verificarsi quando il PDF caricato contiene metadati dei confini di pagina non validi (le coordinate MediaBox e CropBox appaiono invertite), il che può causare la visualizzazione dei livelli di aspetto della firma e di altri campi al di fuori dell’area della pagina visibile. |
| Correzione: la gestione dei margini delle pagine PDF è stata aggiornata per elaborare correttamente quelle che presentano valori di coordinate MediaBox e CropBox non validi o invertiti, in modo che il contenuto relativo all’aspetto della firma e del campo del modulo sia visualizzabile all’interno dell’area della pagina visibile e che rimanga tale anche nel PDF firmato finale. | |
| 4551427 | Riepilogo: alcuni destinatari che dispongono già di account attivi e correttamente configurati ricevono gli accordi come destinatari “pseudo utente”, di conseguenza l’accordo non viene visualizzato nella normale vista Gestisci. Questo accade quando gli indirizzi e-mail dei destinatari includono spazi iniziali o finali, il che impedisce al sistema di abbinare l’e-mail all’utente esistente e causa la creazione di un record pseudo-utente. |
| Correzione: l’analisi delle e-mail e la ricerca degli utenti sono state aggiornate per normalizzare gli indirizzi e-mail dei destinatari (rimuovendo gli spazi iniziali e finali) prima che vengano associati agli utenti esistenti. Di conseguenza, gli accordi indirizzati agli utenti esistenti si risolvono nell’account registrato invece di creare un destinatario pseudo-utente, anche se l’e-mail è stata immessa con spazi (nei payload API e negli elenchi dei destinatari del flusso di lavoro). | |
| 4553198 | Riepilogo: Quando un accordo include almeno un destinatario configurato per la consegna SMS e almeno un destinatario configurato per la consegna solo e-mail, l’annullamento dell’accordo tramite l’API non invia una notifica di annullamento SMS al destinatario SMS. L’accordo viene annullato con successo e le notifiche e-mail vengono consegnate, ma i destinatari SMS non ricevono un messaggio di annullamento. |
| Correzione: Il flusso di lavoro di annullamento è stato corretto per garantire che le notifiche di annullamento SMS vengano inviate a tutti i destinatari configurati per la consegna SMS quando un accordo viene annullato, indipendentemente dai metodi di consegna degli altri destinatari. | |
| 4554463 | Riepilogo: quando gli accordi includono pulsanti di scelta clonati che condividono lo stesso nome di campo tra documenti combinati, nel PDF firmato finale rimane selezionata una sola istanza dell’opzione scelta. Sebbene i campi appaiano visivamente come caselle di controllo, sono implementati come pulsanti di scelta. Dopo la firma, il valore selezionato non si propaga in modo coerente in tutte le istanze clonate, causando una mappatura errata o incompleta della selezione prevista. |
| Correzione: La logica di gestione dei campi modulo è stata corretta in modo che i pulsanti di scelta clonati memorizzino e propaghino il valore di esportazione selezionato anziché un valore di indice interno. Questo garantisce che tutte le istanze clonate dello stesso campo pulsante di scelta riflettano la selezione corretta nel PDF firmato. | |
| 4554593 | Riepilogo: alcune integrazioni partner che utilizzano gli endpoint OAuth legacy per aggiornare i token di accesso potevano non riuscire presentando errori HTTP 401. Il servizio ha rifiutato le richieste di aggiornamento token con un errore che indica che l’app non è autorizzata a utilizzare gli endpoint OAuth tradizionali e deve utilizzare invece gli endpoint OAuth v2. Questo ha impedito ai clienti di autenticare Acrobat Sign tramite le app partner, anche per integrazioni che funzionavano in precedenza. |
| Correzione: Il servizio di autenticazione è stato corretto in modo che le app partner configurate per utilizzare il flusso OAuth tradizionale possano aggiornare nuovamente i token con successo, invece di essere forzate erroneamente sugli endpoint OAuth v2. | |
| 4554614 | Riepilogo: Quando un firmatario utilizza l’esperienza di firma elettronica moderna su un accordo che richiede l’autenticazione del firmatario ed è configurato per richiedere l’accettazione delle condizioni d’uso prima della firma, facendo clic su Fai clic per firmare si attiva un reindirizzamento di 5 secondi all’esperienza di firma classica. Il messaggio di reindirizzamento avverte che le firme e le iniziali inserite nella firma moderna verranno cancellate, costringendo il firmatario a reinserirle e a firmare di fatto due volte. |
| Correzione: Il flusso di aggiornamento del token di firma è stato corretto in modo che quando il firmatario accetta le condizioni d’uso prima della firma, il token di firma riemesso mantenga i dettagli di autenticazione del firmatario. Questo evita gli errori di autenticazione nell’ultima fase di firma ed elimina il fallback forzato dall’esperienza di firma moderna a quella classica. | |
| 4555656 | Riepilogo: In condizioni di tempistica specifiche, una transizione di stato dell’accordo può sembrare riuscire ma non cambia effettivamente lo stato dell’accordo. Quando una notifica webhook viene ricevuta prima del completamento dell’elaborazione backend, le chiamate API successive possono utilizzare dati di stato dell’accordo obsoleti. In questa finestra, alcuni metodi di transizione di stato restituiscono HTTP 200 OK anche se l’accordo non è in uno stato valido per la transizione richiesta. Di conseguenza, i flussi di lavoro di automazione possono considerare la transizione come completata, mentre l’accordo rimane nello stato originale. |
| Correzione: la logica di transizione di stato dell’accordo è stata aggiornata per eseguire una convalida rigorosa prima di applicare una transizione. Se l’accordo non è in uno stato valido, ora l’API restituisce una risposta di errore chiara, anziché restituirne la riuscita senza alcun avviso. Questo garantisce che le transizioni non valide vengano esplicitamente rifiutate, consente ai sistemi chiamanti di riprovare in modo appropriato e impedisce agli accordi di rimanere in uno stato non intenzionale senza visibilità. |
Rilascio di Adobe Acrobat Sign v17.1
Distribuzione produzione: 5 maggio 2026
Distribuzione GovCloud: 12 maggio 2026
Funzionalità migliorate
- Firma in persona – Abilita sessioni di firma ospitate nell'applicazione web
La Firma in persona consente a un mittente di designare un host interno che facilita una sessione di firma in persona utilizzando un browser web. L'host avvia una sessione di firma controllata dalla pagina Gestisci o da una notifica e-mail, consegna temporaneamente il dispositivo al firmatario per completare le azioni richieste e riprende il controllo al completamento. La creazione e il completamento della sessione vengono registrati nella traccia di controllo, e i firmatari possono facoltativamente fornire un indirizzo e-mail per ricevere una copia dell'accordo.
- Firma digitale in blocco dalla pagina Gestisci – Applica una firma digitale a più accordi con una singola autorizzazione
I firmatari possono selezionare più accordi nella vista In attesa di te e applicare firme digitali come azione in blocco utilizzando una singola autorizzazione di firma. Questo riduce i passaggi di firma ripetitivi per flussi di lavoro ad alto volume preservando i controlli di sicurezza, autenticazione e controllo della firma cloud esistenti. La firma in blocco richiede ai firmatari di rivedere o saltare tutti gli accordi prima di completare l'azione in blocco.
- Invia solo a destinatari interni – Limita l'invio degli accordi ai destinatari all'interno dello stesso account Acrobat Sign.
L'impostazione Invia solo a destinatari interni impedisce agli utenti di inviare accordi a destinatari esterni al loro account Acrobat Sign. Quando abilitato, gli accordi possono essere inviati solo ai destinatari i cui ID account corrispondono a quelli del mittente. Questo controllo supporta i requisiti di sicurezza interni e impedisce la condivisione esterna degli accordi.
- Reporting sull'utilizzo delle transazioni telefoniche – Reporting esteso con visibilità a livello di gruppo e accesso ai rapporti pianificati
Il reporting delle transazioni telefoniche ora offre visibilità sulle quantità acquistate, sulle date di inizio delle quote e sul consumo dettagliato delle transazioni SMS e WhatsApp. I clienti possono tracciare l'utilizzo a livello di gruppo e accedere ai report CSV pianificati attraverso un'esperienza di generazione rapporti unificata, consentendo una pianificazione del budget più accurata, un'allocazione interna e un monitoraggio proattivo per prevenire interruzioni del servizio quando vengono raggiunti i limiti delle transazioni.
La generazione rapporti è ora generata attraverso Report Pianificato nell'interfaccia di generazione rapporti, con accesso API disponibile per recuperare l'output del rapporto più recente.
Nuovo endpoint: POST /api/rest/v6/reportDownload
Questo endpoint accetta un scheduleId e restituisce l'URL di download per il rapporto CSV generato più di recente associato a quella pianificazione.
Modifiche a livello di esperienza
- Aspetto della firma nei rapporti di audit – Registra il metodo di inserimento della firma utilizzato da ciascun firmatario, aumentando la visibilità della conformità e riducendo la verifica manuale
I rapporti di audit ora registrano il metodo di aspetto della firma utilizzato quando un firmatario applica la propria firma. Per ogni evento ESIGNED, l'audit trail identifica se il firmatario ha utilizzato una firma digitata, una firma disegnata, un'immagine caricata o un disegno basato su mobile o acquisizione di immagini. Questo miglioramento consente ai team di conformità e operazioni di verificare i metodi di firma direttamente dal rapporto di audit, riducendo l'ambiguità e prevenendo rifiuti non necessari degli accordi.
Tipi di aspetto della firma:- Digitazione: il firmatario digita il proprio nome e seleziona uno stile di firma basato su font.
- Disegno: il firmatario disegna la propria firma utilizzando un mouse o trackpad su desktop.
- Immagine: il firmatario carica un file di immagine della firma dal desktop.
- Disegno mobile: il firmatario disegna la propria firma utilizzando il tocco su un dispositivo mobile.
- Mobile Image: il firmatario carica o cattura un'immagine della firma su un dispositivo mobile.
- Firme salvate per URL di firma API – Consente l'uso di firme del profilo salvate durante la firma basata su API
Consenti agli utenti registrati di applicare le firme del profilo salvate quando firmano accordi tramite URL di firma generati da API (GET /agreements/{agreementId}/signingUrls). Le firme salvate vengono visualizzate per i firmatari interni e per i firmatari esterni che si autenticano utilizzando OTP e-mail o Adobe ID. Questa funzionalità semplifica i flussi di lavoro di firma per le integrazioni backend mantenendo i controlli di sicurezza a livello di account.
Abilitato da Adobe per singolo Account dopo revisione di sicurezza.
- Gestione della rubrica personale nell'esperienza moderna – Gli utenti possono eliminare gli indirizzi e-mail salvati direttamente dalla loro rubrica personale nell'esperienza moderna Richiedi firma , rendendo più facile mantenere accurati e aggiornati gli elenchi dei destinatari personali.
- Finestra di scadenza dell'accordo – Periodo di scadenza predefinito esteso a 365 giorni
La scadenza massima per il completamento degli accordi è stata estesa da 180 giorni a 365 giorni. Quando la scadenza del documento è abilitata, agli accordi viene ora assegnata automaticamente una data di scadenza di 365 giorni che non può essere rimossa. Questa modifica garantisce che tutti gli accordi abbiano un ciclo di vita definito, migliora il tracciamento e la conformità a lungo termine, e riduce il rischio che gli accordi rimangano aperti indefinitamente pur consentendo agli utenti di impostare scadenze precedenti quando necessario.
- Pagina Home rinnovata – Migliora l'accesso al flusso di lavoro, evidenzia le azioni critiche
La pagina Home è stata riprogettata per facilitare l'avvio degli accordi, monitorare l'attività e accedere alle funzionalità chiave, inclusa la possibilità di copiare accordi inviati di recente, visualizzare i riquadri delle azioni in un ordine più intuitivo, identificare rapidamente gli elementi In corso e In attesa di te, e sperimentare un banner Novità semplificato che riduce il disordine visivo, aiutando gli utenti a muoversi più velocemente, ridurre gli accordi persi e navigare in un'esperienza Home più focalizzata.
La nuova pagina Home sarà distribuita nell'arco di 10 giorni dopo il rilascio. Consulta l'Avviso tecnico per la pianificazione.
- Miglioramenti della versione di prova - L'ultima esperienza di onboarding è stata aggiunta alla versione di prova di Sign.
La versione di prova di Sign ora include l'esperienza di onboarding migliorata e le funzionalità introdotte nelle recenti versioni a pagamento.
- Il nuovo Designer di flusso di lavoro personalizzato diventa predefinito – Promuove il designer moderno, rimuove i controlli di cambio Utente, mantiene la flessibilità amministrativa
La nuova esperienza Designer di flusso di lavoro personalizzato è ora predefinita per tutti gli Account. Gli utenti non visualizzano più i collegamenti per tornare al designer classico, mentre gli amministratori mantengono la possibilità di riabilitare l'accesso all'esperienza precedente se necessario. Questo aggiornamento fa avanzare la transizione all'interfaccia di progettazione del flusso di lavoro moderna preservando il controllo amministrativo durante il periodo di transizione.
Aggiornamenti API REST/Webhook
Gli aggiornamenti delle API e del webhook per questa versione sono disponibili nella Documentazione delle API di Acrobat Sign.
- Gestione delle chiavi mTLS per i webhook – Aggiunge l'opzione chiave generata da Acrobat Sign, abilita il flusso di lavoro di firma del certificato, migliora la conformità di sicurezza
Gli sviluppatori ora possono scegliere come gestire le chiavi private per l'autenticazione mTLS dei webhook in Acrobat Sign. Oltre al modello esistente in cui i clienti generano e caricano la propria chiave privata e il certificato, Acrobat Sign ora può generare la chiave privata e una CSR. I clienti possono utilizzare la CSR per ottenere un certificato dalla propria autorità di certificazione e caricarlo per completare la configurazione. Questa opzione migliora la sicurezza mantenendo le chiavi private all'interno di Acrobat Sign pur mantenendo la compatibilità con il comportamento webhook mTLS esistente.
- Inizializzazione dell'identità digitale tramite parametro login_hint – Consente ai mittenti API di inizializzare l'autenticazione dell'identità digitale con un identificatore di accesso specifico del destinatario.
Diversi endpoint v6 REST API /agreements ora supportano un parametro loginHint che consente ai mittenti API di inizializzare l'autenticazione Digital Identity Gateway utilizzando un identificatore di accesso noto, come un indirizzo e-mail o numero ID Utente. Il provider di identità controlla l'esperienza di utilizzo, ma l'identificatore in genere precompila la schermata di accesso per rafforzare i flussi di lavoro di autenticazione ad alta affidabilità e ridurre il rischio di impersonificazione. L'identificatore appare in formato mascherato nella pagina di destinazione Digital Identity Gateway e nel rapporto di audit per preservare la tracciabilità proteggendo i dati sensibili.
I seguenti endpoint sono stati aggiornati per includere il parametro 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
- Miglioramenti OEM 2.0 Identity and Trust Boundary – La funzionalità "Mostra indirizzo e-mail personalizzato/OEM ovunque" ora dà priorità agli utenti forniti dallo stesso partner e crea automaticamente un destinatario quando non viene trovata corrispondenza
Quando la funzionalità Mostra indirizzo e-mail personalizzato/OEM ovunque è abilitata, la risoluzione dei partecipanti all'accordo dà priorità agli utenti forniti dallo stesso partner e crea automaticamente un record destinatario quando non esiste un Utente corrispondente, garantendo una gestione coerente dell'identità tra gli Account.
Inoltre, con Mostra e-mail personalizzata/OEM ovunque abilitata, i rapporti di controllo indicano se un mittente è fornito dal partner o è un Account personale, e i flussi del firmatario guidano gli utenti a cambiare Account quando esistono indirizzi e-mail identici tra diversi tipi di Account, riducendo la confusione e prevenendo l'accesso non intenzionale.
Problemi risolti
| Problema | Descrizione |
|---|---|
| 4520028 | Riepilogo: La colonna Gruppo nella pagina Gestisci mostrava valori errati o incoerenti quando gli utenti appartenevano a più gruppi. La modifica del gruppo primario dell'utente causava la visualizzazione del gruppo sbagliato negli accordi, incluso l'ultimo gruppo primario selezionato o più gruppi, invece del gruppo da cui l'accordo era stato originariamente inviato. |
| Correzione: Aggiornata la logica della pagina Gestisci per utilizzare il gruppo di invio dell'accordo (agreement_group_id) invece del gruppo primario corrente dell'utente durante il rendering della colonna Gruppo. | |
| 4532690 | Riepilogo: Gli utenti non potevano modificare le bozze di accordi create da flussi di lavoro personalizzati quando erano abilitati sia "Abilita accordi da inviare solo utilizzando un flusso di lavoro" che "Abilita nuova esperienza di invio del flusso di lavoro personalizzato". Il sistema bloccava erroneamente l'accesso alla pagina di composizione durante la modifica di una bozza esistente, trattandola come una nuova azione di invio invece di una modifica di bozza. |
| Correzione: Aggiornata la logica della pagina Componi per rilevare gli scenari di modifica delle bozze e bypassare il controllo delle restrizioni del flusso di lavoro, consentendo agli utenti di modificare le bozze di accordi esistenti create da flussi di lavoro personalizzati. | |
| 4536764 | Riepilogo: L'invio di accordi attraverso un flusso di lavoro personalizzato ha causato un errore del server a causa di un errore nell'elaborazione di modelli PDF specifici. L'errore è stato causato da dati di aspetto delle annotazioni non validi o mancanti in uno o più documenti di origine, che hanno attivato un'eccezione di rendering durante la precompilazione. Il problema non era riproducibile in modo coerente e non poteva essere replicato al di fuori dei flussi di lavoro interessati. |
| Correzione: Migliorata la gestione delle eccezioni di rendering nel livello di elaborazione PDF. | |
| 4537197 | Riepilogo: Quando si utilizzava la nuova esperienza Invia in blocco con nomi di destinatari inseriti manualmente, il secondo campo nome veniva rimosso durante la firma a causa di una gestione errata dei dati del nome del destinatario richiesti tra i documenti. |
| Correzione: Aggiornata la logica di elaborazione dei documenti per mantenere correttamente tutti i campi nome del destinatario durante l'invio di accordi in blocco. | |
| 4538172 | Riepilogo: La copia di flussi di lavoro che includono gruppi di destinatari non riusciva durante la sincronizzazione Sandbox con un messaggio "Errore durante l'esecuzione della richiesta" a causa di riferimenti non validi ai gruppi di destinatari. Il flusso di lavoro utilizzava ID di gruppi di destinatari specifici dell'ambiente, che non sono trasferibili tra ambienti, causando l'esito negativo della convalida durante la sincronizzazione. |
| Correzione: Aggiornata la gestione di Sandbox Sync per convalidare ed elaborare i riferimenti ai gruppi di destinatari durante le operazioni di copia del flusso di lavoro, evitando errori quando i gruppi di destinatari esistono in entrambi gli ambienti. | |
| 4538251 | Riepilogo: Nella nuova esperienza Invia in blocco, i campi delle informazioni del firmatario per nome completo ed e-mail non venivano visualizzati durante la firma o nel documento finale quando il file di origine conteneva campi AcroForm esistenti. Il problema era causato dalla gestione errata dei dati dei campi di unione durante la combinazione dei campi delle informazioni del firmatario con i campi modulo preesistenti, impedendo il rendering dei campi negli accordi figlio |
| Correzione: Aggiornata la logica di elaborazione dei campi di unione e modulo per applicare correttamente i campi delle informazioni del firmatario nei documenti che includono campi AcroForm esistenti. | |
| 4545485 | Riepilogo: La creazione dell'accordo falliva a intermittenza quando la generazione delle miniature incontrava campi modulo pdf malformati. L'errore è stato causato da documenti di origine contenenti campi modulo senza nomi validi e strutture di campi nidificati non valide, che hanno attivato errori di elaborazione durante la generazione del PDF. |
| Correzione: Aggiunte convalida e verifiche null durante l'elaborazione del pdf per gestire i campi modulo malformati ed evitare errori durante la generazione delle miniature e la creazione dell'accordo. | |
| 4545814 | Riepilogo: I campi sono disallineati e i tag di testo rimangono visibili durante l'elaborazione di documenti con orientamento orizzontale generati da flussi di lavoro basati su XDP. Calcoli di coordinate errati nei layout orizzontali causano un posizionamento improprio dei campi e impediscono l'analisi e la rimozione corrette dei tag di testo. |
| Correzione: Aggiornata la logica di rendering dei campi per calcolare e posizionare correttamente i campi modulo nei documenti con orientamento orizzontale, garantendo il corretto allineamento e la rimozione dei tag di testo durante l'elaborazione. | |
| 4545978 | Riepilogo: I caratteri accentati nei nomi dei firmatari vengono visualizzati in modo errato nel blocco firma visibile quando si utilizza la firma digitale locale. Il problema si verifica perché il font predefinito incorporato nel documento non dispone della codifica corretta per i caratteri dell'Europa occidentale, causando una sostituzione errata dei caratteri durante il rendering dell'aspetto della firma. |
| Correzione: Aggiornata la configurazione del font incorporato per includere la codifica corretta per i caratteri accentati, garantendo il rendering corretto dei nomi dei firmatari nell'aspetto della firma | |
| 4547100 | Riepilogo: I campi di testo multilinea clonati vengono visualizzati in modo incoerente nel pdf firmato. Ai campi clone multilinea manca il dizionario dell'aspetto predefinito, il che fa sì che i campi clonati visualizzino meno righe rispetto al campo di origine anche quando entrambi i campi utilizzano le stesse dimensioni e impostazioni. |
| Correzione: Aggiunto il dizionario dell'aspetto predefinito ai campi clonati multilinea in modo che i campi clonati e di origine vengano visualizzati in modo coerente nei documenti firmati. | |
| 4548305 | Riepilogo: L'elenco di controllo dell'onboarding mostra "Richiedi BAA per conformità HIPAA" come In sospeso anche quando HIPAA è abilitato. La logica di valutazione dell'elenco di controllo tratta erroneamente le impostazioni ereditate relative a HIPAA come incomplete, causando il mantenimento dello stato In sospeso dell'attività nonostante la funzionalità sia abilitata. |
| Correzione: Aggiornata la logica di valutazione dell'elenco di controllo per interpretare correttamente le impostazioni relative a HIPAA, inclusi i valori ereditati, in modo che l'attività di onboarding rifletta lo stato completato quando HIPAA è abilitato. | |
| 4550731 | Riepilogo: Appare uno spazio vuoto ampio tra il sottolineato della firma e la marca temporale quando si firmano documenti utilizzando Fill & Sign. Il problema si verifica quando il campo firma non è abbastanza ampio per contenere il contenuto della firma visualizzato, causando una spaziatura errata nell'aspetto della firma |
| Correzione: Aggiornato il rendering della firma per rispettare le dimensioni definite del campo e regolare la spaziatura in modo appropriato, riducendo lo spazio tra il sottolineato e la marca temporale. | |
| 4550906 | Riepilogo: Il collegamento Cambia password punta a un URL non valido per alcuni utenti, causando un errore del browser. Il problema si verifica quando l'app legge un endpoint obsoleto dalla configurazione invece dell'URL corretto, causando un comportamento incoerente tra gli ambienti. |
| Correzione: Aggiornato l'endpoint configurato per il cambio password per utilizzare l'URL corretto negli ambienti interessati. | |
| 4550992 | Riepilogo: La modifica di alcuni modelli nella nuova esperienza reindirizza alla pagina Crea modello invece di aprire il modello in modalità modifica. Il problema si verifica perché il sistema determina l'esperienza in base alle impostazioni del proprietario del modello anziché alle impostazioni dell'utente corrente, causando un instradamento errato durante la modifica di modelli condivisi. |
| Correzione: Aggiornata la logica di modifica dei modelli per utilizzare le impostazioni dell'esperienza dell'utente corrente invece di quelle del proprietario del modello, garantendo che i modelli si aprano nella modalità di modifica corretta. | |
| 4551756 | Riepilogo: Le e-mail di richiesta di approvazione mostrano variabili di modello non risolte nel campo del destinatario, causando una formattazione dell'e-mail errata. Il problema si verifica a causa di un errore nella logica di rendering del modello e-mail durante la generazione delle notifiche di conflitto di autorizzazione. |
| Correzione: Aggiornato il rendering del modello e-mail per risolvere e popolare correttamente i campi destinatario, garantendo che gli indirizzi e-mail validi vengano visualizzati nelle e-mail di richiesta di approvazione. | |
| 4551768 | Riepilogo: I firmatari riscontrano un errore non gestito quando accedono agli accordi o li completano a causa di un errore nell'elaborazione dell'aspetto dei campi modulo. Un oggetto appearance malformato causa una ClassCastException durante la generazione del documento, causando un errore del rendering dell'accordo. |
| Correzione: Aggiornata la logica di elaborazione dei campi modulo per convalidare i tipi di oggetto aspetto prima del casting, prevenendo eccezioni e garantendo che gli accordi vengano renderizzati correttamente per la firma. | |
| 4552272 | Riepilogo: Gli accordi annullati o abbandonati appaiono sotto In attesa di te nella pagina Gestisci. Il problema si verifica quando un evento di riavvio del flusso di lavoro non esegue correttamente la pulizia dei dati dello stato del partecipante, lasciando dati di visibilità e indicizzazione obsoleti che fanno apparire l'accordo in viste errate |
| Correzione: Aggiornata la gestione del riavvio del flusso di lavoro e la logica di indicizzazione per cancellare correttamente i dati precedenti dello stato del partecipante e garantire che gli accordi appaiano solo nel loro stato corretto. | |
| 4553158 | Riepilogo: Negli ambienti linguistici RTL su iOS, il pannello firma non risponde correttamente quando si disegna una firma. Il pannello scorre invece di catturare l'input, richiedendo agli utenti di scorrere manualmente per disegnare e applicare la firma, il che impedisce il normale comportamento di firma quando è abilitata la nuova esperienza di firma del destinatario. |
| Correzione: Aggiornata la gestione dell'interazione del pannello firma per i layout RTL su iOS per acquisire correttamente l'input di disegno senza scorrimento involontario, consentendo la normale creazione e applicazione della firma. | |
| 4553583 | Riepilogo: I flussi di lavoro consentono indirizzi e-mail con spazi iniziali o finali, il che causa errori negli accordi durante l'invio nella nuova esperienza senza segnalare il problema. Il sistema non convalida o normalizza l'input e non viene visualizzato alcun messaggio di errore per indicare il problema. |
| Correzione: Aggiornata la gestione dell'input per rimuovere automaticamente gli spazi vuoti dagli indirizzi e-mail e impedire il salvataggio di valori non validi; aggiunta inoltre la gestione per i flussi di lavoro esistenti affinché gli accordi possano essere inviati correttamente. | |
| 4553676 | Riepilogo: I collegamenti ipertestuali vengono visualizzati in modo errato nella vista Gestisci, dove il titolo dell'accordo viene aggiunto all'URL, con il risultato che i collegamenti risultano interrotti. Il problema si verifica a causa di un'analisi dell'URL errata durante il rendering dei collegamenti ipertestuali nell'interfaccia Gestisci. |
| Correzione: Aggiornato il rendering dei collegamenti ipertestuali per utilizzare un'analisi corretta dell'URL, garantendo che i collegamenti rimangano invariati e funzionino correttamente in tutte le viste. | |
| 4555021 | Riepilogo: La convalida OTP fallisce con un errore 'scaduto' anche quando il simbolo viene inserito immediatamente. Il problema si verifica a causa di una condizione di competizione nel flusso di autenticazione, dove eventi di invio multipli causano l'invalidazione prematura dell'OTP. |
| Correzione: Aggiornato il flusso di convalida OTP per gestire correttamente eventi di invio duplicati o rapidi, prevenendo la scadenza prematura e consentendo l'elaborazione corretta di OTP validi. | |
| 4555028 | Riepilogo: La rimozione del prossimo destinatario da firmare può fallire con un errore di sistema e lasciare l'accordo bloccato in uno stato di revisione in sospeso. Il problema si verifica quando il destinatario ha un promemoria attivo, che impedisce il completamento dell'aggiornamento dell'accordo. |
| Correzione: Aggiornata la logica di rimozione del destinatario per gestire i casi in cui il firmatario successivo ha promemoria attivi, consentendo il completamento dell'aggiornamento dell'accordo senza errori. | |
| 4555319 | Riepilogo: I creatori di moduli web vedono solo le opzioni di firma Digita e Disegna durante l'anteprima del modulo, mentre i firmatari vedono tutte le opzioni disponibili (Digita, Disegna, Immagine, Mobile). Il problema si verifica perché la modalità anteprima non applica correttamente le impostazioni di input della firma abilitate quando il creatore non agisce come firmatario. |
| Correzione: Aggiornato il comportamento dell'anteprima del modulo web per applicare l'intero set di tipi di input della firma abilitati, assicurando che i creatori vedano le stesse opzioni di firma dei firmatari. | |
| 4555345 | Riepilogo: Gli accordi con più destinatari firmatario e testimone non riescono ad aprirsi in Anteprima dalla Bozza con l'errore «ParticipantSetsInfo non può essere modificato». Il problema si verifica a causa della logica di ordinamento errata di partecipanti e testimoni nei flussi di lavoro personalizzati, che impedisce all'accordo di tornare allo stato di creazione. |
| Correzione: Aggiornata la logica di ordinamento di partecipanti e testimoni nei flussi di lavoro personalizzati per calcolare correttamente l'ordine di esecuzione, consentendo agli accordi di tornare allo stato di authoring e procedere normalmente. | |
| 4555615 | Riepilogo: I payload degli eventi webhook per destinatari delegati e sostituiti non includono il campo privateMessage. Il problema si verifica perché il messaggio privato non viene propagato allo stato del destinatario utilizzato per generare i payload webhook, causando dati mancanti per gli eventi interessati. |
| Correzione: Aggiornata la gestione dei dati dei partecipanti per assicurare che i messaggi privati siano inclusi nei payload webhook per destinatari delegati e sostituiti. | |
| 4555687 | Riepilogo: Gli accordi possono essere annullati automaticamente e spostati in uno stato nascosto dopo la firma a causa di un errore di convalida della visibilità del documento. Quando un partecipante viene delegato o sostituito, la mappatura della Visibilità del documento non viene trasferita correttamente, causando una discrepanza tra i campi assegnati e i documenti visibili, che può attivare un annullamento automatico. |
| Correzione: La logica di delega e sostituzione ora clona correttamente le mappature di visibilità del documento per i nuovi partecipanti, prevenendo errori di convalida e annullamento involontario dell'accordo. | |
| 4556516 | Riepilogo: I campi modulo possono ignorare le dimensioni del font configurate e il rendering risulta incoerente negli accordi generati. Il problema si verifica nei campi multilinea quando il motore di elaborazione del documento regola la dimensione del font per evitare il ritaglio del testo, sostituendo le impostazioni di dimensione del font fisse. |
| Correzione: Aggiornato il comportamento del rendering dei font in modo che i campi multilinea rispettino le impostazioni della dimensione fissa del font, allineando il comportamento con l'output previsto e prevenendo regolazioni indesiderate delle dimensioni del font. | |
| 4556967 | Riepilogo: Le caselle di controllo selezionate possono apparire non selezionate nel PDF firmato finale per i moduli web. Il problema si verifica quando vengono utilizzati determinati valori nascosti (ad esempio, «no», «falso», «0», «off», «deselezionato»), che possono causare un'errata interpretazione degli stati delle caselle di controllo durante l'elaborazione dei documenti quando Gibson è abilitato. |
| Correzione: Aggiornamento dell'elaborazione delle caselle di controllo per interpretare correttamente i valori nascosti e preservare gli stati selezionati nel documento finalizzato, garantendo coerenza tra la firma e il PDF firmato. | |
| 4557222 | Riepilogo: I campi collegamento dai modelli di campo possono scomparire nella pagina di authoring quando utilizzati all'interno di un flusso di lavoro. Il problema si verifica perché i campi collegamento non sono inclusi nei dati del campo modulo dell'accordo restituiti durante l'authoring basato su flusso di lavoro, causando la mancanza di campi. |
| Correzione: Aggiornamento della gestione dei campi modulo per includere i campi collegamento dai modelli di campo durante l'elaborazione del flusso di lavoro, garantendo che vengano uniti e visualizzati correttamente nella pagina di authoring. | |
| 4557272 | Riepilogo: Il campo Data di firma può non apparire nel PDF firmato finalizzato. Il problema si verifica quando il rendering del campo di testo non riesce durante l'elaborazione del documento, impedendo la visualizzazione del campo data nel documento di output. |
| Correzione: Aggiornamento del rendering del campo di testo per gestire correttamente i valori nulli o vuoti, garantendo che il campo Data di firma sia visualizzato in modo coerente nei documenti firmati. | |
| 4557282 | Riepilogo: I campi pulsante di scelta nei moduli web possono visualizzare un valore di descrizione imprevisto ("object Object") quando vengono creati utilizzando la nuova esperienza modello. Il problema si verifica a causa della gestione non corretta dei valori di descrizione vuoti, causando il rendering dei dati segnaposto invece della loro eliminazione. |
| Correzione: Aggiornata la logica di gestione delle descrizioni comando per ignorare correttamente i valori vuoti, impedendo la visualizzazione di testo placeholder non previsto nei moduli web. | |
| 4557589 | Riepilogo: I campi casella di controllo precompilati possono apparire deselezionati quando l'accordo viene inviato per la firma. Il problema si verifica quando si definiscono valori nascosti duplicati o in conflitto per gli input casella di controllo o pulsante di scelta, il che può causare un'interpretazione non corretta dello stato selezionato durante l'elaborazione del documento. |
| Correzione: Aggiornata la gestione dei valori dei campi per elaborare correttamente i valori nascosti e mantenere le selezioni precompilate, garantendo che gli stati delle caselle di controllo rimangano coerenti quando gli accordi vengono generati e inviati. | |
| 4557672 | Riepilogo: La nuova esperienza di richiesta firma può visualizzare un errore generico ("La richiesta fornita non è valida") durante l'invio di un accordo, senza identificare il campo specifico che causa l'errore. Questo può verificarsi quando i dettagli del destinatario (come il formato del numero di telefono) non superano la convalida, ma l'errore non viene chiaramente comunicato all'utente. |
| Correzione: Aggiornata la gestione della convalida per fornire messaggi di errore specifici a livello di campo, aiutando gli utenti a identificare e correggere gli input non validi prima di inviare l'accordo. | |
| 4557680 | Riepilogo: Le mappature delle caselle di controllo o dei pulsanti di scelta possono non funzionare in alcuni accordi quando si combinano più documenti, causando la mancata applicazione dei valori previsti. Il problema si verifica quando i valori predefiniti non corrispondono esattamente ai valori di esportazione definiti, il che può causare il trattamento dei campi come gruppi separati e interrompere il comportamento di mappatura. |
| Correzione: Aggiornata la logica di mappatura dei campi per ignorare i valori predefiniti non corrispondenti e associare correttamente i campi tra i documenti, migliorando la coerenza del comportamento di caselle di controllo e pulsanti di scelta. | |
| 4557902 | Riepilogo: Può apparire uno spazio aggiuntivo tra la firma e la marca temporale di data e ora negli accordi Fill and Sign. Il problema si verifica a causa di un calcolo non corretto della spaziatura nelle firme ben formattate, causando un layout incoerente rispetto ad altri flussi di firma. |
| Correzione: Aggiornato il calcolo del layout della firma per posizionare correttamente la firma e la marca temporale, rimuovendo la spaziatura non intenzionale e garantendo una formattazione coerente. | |
| 4557947 | Riepilogo: I campi casella di controllo possono apparire deselezionati nel PDF firmato finalizzato quando si utilizzano modelli di libreria, anche se il firmatario li ha selezionati. Il problema può verificarsi quando i campi casella di controllo sono configurati in modo errato o utilizzano determinati valori nascosti, il che porta a un'interpretazione non corretta dello stato selezionato durante l'elaborazione del documento. |
| Correzione: Aggiornata l'elaborazione delle caselle di controllo per interpretare correttamente i valori nascosti e preservare gli stati selezionati, garantendo che le selezioni delle caselle di controllo vengano mantenute nel documento firmato. | |
| 4558295 | Riepilogo: I valori dei pulsanti di scelta obbligatori possono essere mancanti nel PDF firmato finalizzato. Il problema può verificarsi quando i valori dei campi contengono caratteri speciali (ad esempio, virgolette o simboli) che non vengono elaborati correttamente, causando la mancata visualizzazione del valore selezionato nell'output del documento. |
| Correzione: Aggiornata l'elaborazione dei valori dei campi per gestire correttamente i caratteri speciali, garantendo che i valori selezionati vengano preservati e visualizzati nel PDF firmato. | |
| 4558307 | Riepilogo: I campi del modulo possono ignorare le dimensioni del font configurate e vengono visualizzati in modo incoerente negli accordi generati. Il problema può verificarsi nei campi multilinea quando il motore di elaborazione del documento regola la dimensione del font per prevenire il taglio del testo, sostituendo le impostazioni di dimensione del font fisse. |
| Correzione: Aggiornato il comportamento di rendering del font in modo che i campi multilinea rispettino le impostazioni di dimensione del font fisse, prevenendo il ridimensionamento non intenzionale e garantendo un output coerente. | |
| 4558554 | Riepilogo: I firmatari possono completare gli accordi senza interagire con il blocco firma. Il problema può verificarsi negli account abilitati per Gibson quando il blocco firma non viene visualizzato o applicato correttamente durante la firma, consentendo il completamento con solo il campo firma. |
| Correzione: Aggiornata la logica di rendering e convalida della firma per garantire che i blocchi firma vengano visualizzati correttamente e richiesti prima del completamento dell'accordo. | |
| 4558725 | Riepilogo: I tag di testo possono non riuscire a eseguire il rendering o a convertirsi in campi modulo durante l'anteprima. Il problema può verificarsi quando il PDF caricato contiene elementi non supportati o non validi (ad esempio, annotazioni nulle o campi compilabili esistenti), che impediscono il completamento dell'elaborazione dei tag di testo. |
| Correzione: Aggiornata l'elaborazione dei tag di testo per gestire in modo più affidabile i PDF con annotazioni non valide o non supportate, consentendo la generazione dei campi come previsto durante l'anteprima. | |
| 4559285 | Riepilogo: L'autenticazione telefonica può non riuscire per alcune aree geografiche quando si seleziona un prefisso internazionale nella nuova esperienza di richiesta firma. Il problema si verifica quando l'interfaccia visualizza un prefisso internazionale incompleto o errato (ad esempio, "+1" invece di "+1246" per le Barbados), che può causare errori di convalida durante l'invio dell'accordo. |
| Correzione: Aggiornata la gestione dei codici paese per utilizzare i codici di composizione completi corretti, garantendo che i numeri di telefono vengano convalidati ed elaborati correttamente nella nuova esperienza. | |
| 4560119 | Riepilogo: Il testo nei campi modulo può apparire disallineato o sovrapporsi negli accordi generati. Il problema può verificarsi nei campi di testo su più righe quando vengono introdotte differenze di rendering dal motore di elaborazione dei documenti, causando spostamenti del layout rispetto alla vista di authoring. |
| Correzione: Aggiornati il rendering del testo e la gestione del layout per i campi su più righe per migliorare l'allineamento e prevenire sovrapposizioni, garantendo una visualizzazione più coerente tra authoring e documenti finali | |
| 4562058 | Riepilogo: Il nome del destinatario può rimanere invariato quando si seleziona un'e-mail diversa dalla rubrica nella pagina Invia. Il problema si verifica perché il campo nome non si aggiorna quando viene selezionato un nuovo contatto, causando una mancata corrispondenza tra il nome visualizzato e l'e-mail selezionata. |
| Correzione: Aggiornato il comportamento di selezione del destinatario in modo che il campo nome si aggiorni sempre quando viene selezionato un nuovo contatto, garantendo che nome ed e-mail rimangano sincronizzati. | |
| 4566339 | Riepilogo: Stati delle caselle di controllo errati possono apparire durante l'elaborazione di pdf XFA statici con valori di campo non validi. Il problema può verificarsi quando i dati XFA non supportati o non validi (ad esempio, valori stringa in campi numerici) vengono gestiti in modo incoerente, in particolare negli ambienti abilitati per Gibson dove le impostazioni predefinite delle caselle di controllo possono essere interpretate erroneamente. |
| Correzione: Aggiornata la gestione XFA nella pipeline di elaborazione dei documenti per normalizzare o ignorare i valori non validi in modo più coerente, prevenendo stati errati delle caselle di controllo e allineando il comportamento tra gli ambienti. | |
| 4567278 | Riepilogo: I campi di testo di sola lettura possono non apparire nella pagina di firma quando i partecipanti dinamici sono abilitati. Il problema si verifica a causa di incoerenze nel rendering dei campi durante la risoluzione dei partecipanti, che possono causare l'omissione dei campi non modificabili dalla vista del firmatario. |
| Correzione: Aggiornata la logica di rendering dei campi per i partecipanti dinamici per garantire che i campi di sola lettura vengano inclusi e visualizzati in modo coerente durante la firma. | |
| 4568023 | Riepilogo: Le opzioni di firma Immagine e mobile possono non apparire nei moduli web durante la firma. Il problema può verificarsi a causa del caricamento incoerente delle opzioni di firma nel flusso di immissione dei moduli web, dove alcuni metodi di firma non vengono visualizzati finché la sessione non viene ricaricata o non si accede tramite un percorso alternativo. |
| Correzione: Aggiornata l'inizializzazione della firma dei moduli web per caricare in modo coerente tutte le opzioni di firma abilitate, garantendo che i metodi Immagine e mobile siano disponibili in tutti i punti di accesso. |
Versione 17.1.1 di Adobe Acrobat Sign
Implementazione in produzione: 16 giugno 2026
Implementazione GovCloud: 18 giugno 2026
Funzionalità migliorate
- Filtro destinatario nel reporting: aggiunge il filtraggio basato sul destinatario a rapporti ed esportazioni dati.
Aggiunta di un filtro Destinatario al Reporting moderno per i report Accordo e Transazione e per le Esportazioni dati. Gli amministratori possono filtrare per e-mail del destinatario per ottenere tutti gli accordi che includono il destinatario specificato, indipendentemente da mansione o ordine di firma. Il filtro supporta il completamento automatico e il comportamento multi-selezione coerente con il filtro Mittente esistente e si applica sia ai rapporti visivi che alle esportazioni CSV.
Modifiche a livello di esperienza
- Supporto Bio-Pharma (CFR) nella firma elettronica moderna: aggiunge l’acquisizione del motivo di firma e la riautenticazione obbligatoria al momento della firma
Le impostazioni di firma Bio-Pharma, inclusa l’acquisizione del motivo di firma e la riautenticazione al momento della firma, sono ora supportate dall’esperienza di firma elettronica moderna. Gli accordi che usano queste impostazioni non tornano più all'esperienza di firma classica. Non è richiesta alcuna azione da parte del cliente né alcuna modifica delle impostazioni dell’amministratore.
Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: Il supporto per le impostazioni Bio Pharma nella firma elettronica moderna è abilitato per impostazione predefinita.
Aggiornamenti API REST/Webhook
Gli aggiornamenti delle API e del webhook per questa versione sono disponibili nella Documentazione delle API di Acrobat Sign.
- Disattiva le notifiche degli accordi tramite API: aggiungi un controllo granulare sui messaggi dei destinatari
Utilizzando l’API REST v6 POST /agreements, controlla quali notifiche vengono inviate durante la creazione degli accordi disattivando tipi di e-mail specifici per partecipanti, destinatari in CC o mittente. Questo riduce le e-mail non necessarie e supporta esperienze di firma più pulite e controllate nei flussi di lavoro integrati.
Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API REST v6
Problemi risolti
| Problema | Descrizione |
|---|---|
| 4545881 | Riepilogo: I firmatari che usano Scarica e firma in Acrobat potrebbero ricevere un errore «Adobe Acrobat Sign non riesce a riconoscere» dopo aver caricato un PDF firmato digitalmente quando il certificato dell'ID digitale non includeva un valore del nome del firmatario previsto, come commonName, givenName o pseudonym. Impossibile completare l'accordo nonostante sia stato caricato il PDF firmato. |
| Correzione: Acrobat Sign ora gestisce i certificati dell'ID digitale con valori del nome del firmatario mancanti senza generare un errore durante il processo di convalida del caricamento. La firma può essere completata con successo, anche se il nome del firmatario potrebbe non essere visualizzato se il certificato non ne include uno. | |
| 4547132 | Riepilogo: Quando gli accordi venivano creati tramite la richiesta API POST /agreements e securityOption era impostato su null, ai destinatari esterni poteva essere assegnato Nessuno come metodo di autenticazione anche quando le impostazioni dell'account richiedevano OTP email come metodo di autenticazione predefinito. L'autenticazione del destinatario interno veniva applicata correttamente, ma quella del destinatario esterno no. |
| Correzione: Acrobat Sign ora applica correttamente il metodo di autenticazione predefinito configurato nell’account quando gli accordi creati tramite API includono destinatari con un valore securityOption nullo. I destinatari esterni ora ricevono il metodo di autenticazione predefinito richiesto invece di Nessuno. | |
| 4553171 | Riepilogo: Negli account sviluppatore che usano la nuova esperienza Crea modello, i modelli riutilizzabili potevano mostrare il prefisso [DEMO USE ONLY] nella pagina Gestisci, ma il prefisso non era disponibile durante la modifica del nome del modello. Gli utenti non potevano rimuovere il prefisso dal nome del modello esistente a meno che non sostituissero il nome completo o passassero all'esperienza del modello classico. |
| Correzione: La nuova esperienza Crea modello ora mantiene allineati il nome del modello riutilizzabile e il nome dell'accordo per il comportamento della filigrana dell'account sviluppatore. Gli utenti possono modificare il nome completo del modello, incluso il prefisso [DEMO USE ONLY], senza passare all'esperienza classica | |
| 4556731 | Riepilogo: Dopo che un mittente ha sostituito un destinatario con se stesso e poi ha delegato l'accordo a un altro destinatario, l'accordo è tornato a In corso, ma l'opzione Carica documento firmato è rimasta non disponibile. Questo impediva al mittente di caricare una copia firmata per gli accordi in corso idonei dopo quella sequenza di delega. |
| Correzione: Acrobat Sign ora ripristina correttamente l'opzione Carica documento firmato dopo che un destinatario viene sostituito con il mittente e poi delegato a un altro destinatario, quando l'accordo è idoneo per il caricamento del documento firmato. | |
| 4557576 | Riepilogo: Quando un blocco di firme veniva assegnato a un gruppo di destinatari con più membri, il valore e-mail nel blocco firma poteva essere troncato invece di essere visualizzato correttamente. Questo poteva rendere difficile la lettura delle informazioni del gruppo di destinatari prima che un iscritto del gruppo completasse la firma. |
| Correzione: Acrobat Sign ora visualizza le informazioni sull’e-mail del gruppo di destinatari nei blocchi firme senza troncare bruscamente il testo visibile. I valori e-mail lunghi dei gruppi di destinatari vengono gestiti in modo che le informazioni visualizzate rimangano leggibili all'interno del blocco di firme. | |
| 4561898 | Riepilogo: Alcuni destinatari potrebbero riscontrare un errore del server dopo l'autenticazione o quando finalizzano la firma per accordi che utilizzavano specifici documenti PDF. L’errore era causato da un problema nella gestione dei dati della struttura PDF durante la generazione del documento firmato, che impediva al firmatario di completare l’accordo. |
| Correzione: Acrobat Sign ora gestisce i dati della struttura PDF in modo più difensivo durante la firma e la generazione dei documenti. La correzione impedisce che i conflitti della struttura ad albero blocchino il completamento, consentendo ai destinatari di autenticarsi, firmare e completare con successo gli accordi interessati. | |
| 4562041 | Riepilogo: Alcune notifiche webhook potrebbero subire ritardi o non essere pubblicate quando Acrobat Sign riceve un errore interno del server durante la creazione del payload webhook. Per l’account interessato, il problema ha interessato diversi eventi del 19 marzo 2026, tra cui AGREEMENT_WORKFLOW_COMPLETED e altri eventi relativi all’accordo, causando un rallentamento dei flussi di lavoro a valle dei clienti |
| Correzione: Acrobat Sign ora gestisce gli errori di generazione del payload del webhook in modo più affidabile, evitando che le risposte interne non riuscite vengono memorizzate nella cache in modo da bloccare o ritardare la consegna degli eventi. La correzione è stata validata tramite test di regressione ed è progettata per evitare che gli eventi webhook interessati subiscano ritardi dovuti al medesimo errore nella generazione del payload. | |
| 4562458 | Riepilogo: I destinatari potevano ricevere l’errore ID accordo specificato non valido quando aprivano un URL di firma per accordi inviati a utenti inattivi su domini di account rivendicati, se veniva utilizzato un metodo di autenticazione del destinatario, ad esempio tramite e-mail con OTP o autenticazione con password. Il flusso di firma creava un utente in sospeso monouso per continuare il processo di firma, ma la richiesta di informazioni sulla firma poteva leggere dati di accordo obsoleti che non includevano la nuova partecipazione creata, bloccando l'accesso fino alla rigenerazione del collegamento di firma o all'aggiornamento dei dati. |
| Correzione: Acrobat Sign ora recupera i dati di partecipazione all'accordo correnti quando apre URL di firma autenticati in questo flusso di lavoro. Questo impedisce che i dati di accordo obsoleti memorizzati in cache causino errori di ID accordo non validi e consente ai destinatari di completare l'autenticazione e accedere alla pagina di firma elettronica con successo. | |
| 4566894 | Riepilogo: Alcuni accordi scaduti creati da più modelli non potevano essere copiati dalla pagina Gestione. Quando gli utenti selezionavano Crea una copia, l'operazione di copia non riusciva con Impossibile copiare l'accordo. Riprova più tardi perché la convalida dell’accesso al modello non è riuscita durante la copia di accordi che utilizzano più di un modello. |
| Correzione: Acrobat Sign ora convalida correttamente le informazioni del modello quando copia accordi che sono stati creati da più modelli. Gli accordi interessati ora possono essere copiati senza causare l’errore di sessione del backend. | |
| 4568666 | Riepilogo: Le notifiche webhook potevano occasionalmente non essere non essere recapitate per gli accordi che includevano partecipanti testimoni privi di un ID utente assegnato. L'evento principale dell'accordo è stato creato, ma la generazione del payload webhook poteva non riuscire quando i dati dei partecipanti venivano elaborati in ordine imprevedibile, causando la mancata consegna di alcuni eventi webhook previsti dopo AGREEMENT_CREATED. |
| Correzione: Acrobat Sign ora gestisce in modo sicuro i dati dei partecipanti webhook con ID utente mancanti durante la generazione del payload. Questo impedisce che i partecipanti testimoni segnaposto causino errori nella generazione del payload del webhook e consente la corretta consegna degli eventi webhook previsti per gli accordi. | |
| 4571682 | Riepilogo: In alcuni accordi in cui Power Automate modificava i gruppi di destinatari prima del turno del compilatore moduli successivo, i campi di sola lettura potevano non essere visualizzati per il compilatore moduli successivo. Dopo che il compilatore del modulo aveva completato i campi modificabili, tali campi potevano scomparire dall'accordo, anche se erano ancora assegnati correttamente e contrassegnati come visibili tramite le API. |
| Correzione: Acrobat Sign ora mantiene la visibilità dei campi per i gruppi di destinatari successivi dopo le modifiche all’iscrizione al gruppo di destinatari. I campi di sola lettura, i blocchi firma, le selezioni a discesa e altri valori dei campi completati rimangono disponibili per i destinatari successivi e nel PDF scaricato per gli scenari corretti. | |
| 4571845 | Riepilogo: La firma di persona può non riuscire a causa di un errore del server quando l’e-mail del firmatario di persona corrisponde a un account utente esistente in un’altra partizione, impedendo il completamento dell’accordo. |
| Correzione: Aggiornata l'elaborazione del firmatario in persona per creare e utilizzare correttamente un record temporaneo del firmatario, evitando conflitti tra utenti di diversi frammenti e consentendo il completamento della sessione di firma. | |
| 4573019 | Riepilogo: L'ordine del gruppo di destinatari può essere calcolato in modo errato dopo gli aggiornamenti dinamici dei partecipanti che rimuovono un mix di destinatari e gruppi di destinatari, causando la visualizzazione dell'ordine di instradamento errato per il gruppo rimanente. |
| Correzione: Aggiornato il ricalcolo dell'ordine dei partecipanti in modo che i gruppi di destinatari mantengano l'ordine corretto dopo rimozioni complesse di partecipanti dinamici, inclusi i casi in cui un gruppo viene ridotto a un singolo membro rimanente. | |
| 4572455 | Riepilogo: Alcuni firmatari potevano visualizzare il messaggio di Errore non gestito o Si è verificato un errore dopo aver completato la firma, anche se quest’ultima era stata applicata e l’accordo era passato al destinatario successivo. Il problema si è verificato quando i partecipanti dinamici erano attivati e il flusso di firma ha tentato di preparare il documento per il firmatario successivo ma non è riuscito a trovare la versione del documento firmato prevista. |
| Correzione: Acrobat Sign ora verifica la versione corretta del documento firmato durante la preparazione di un accordo per il firmatario successivo. Questo impedisce al flusso di firma di mostrare un errore dopo una firma riuscita quando i partecipanti dinamici sono attivati. |