Naposledy aktualizováno
10. 2. 2026
Poznámky k vydání aplikace Adobe Acrobat Sign: 2026
Adobe Acrobat Sign verze 17.0
Nasazení do provozu: 3. února 2026
Nasazení pro prostředí GovCloud: 10. února 2026
Vylepšená funkčnost
- Seskupená zaškrtávací políčka v prostředí pro vytváření a v šablonách – Odesílatelé si nyní mohou vytvořit skupiny zaškrtávacích políček prostřednictvím moderního prostředí pro tvorbu Požádat o podpis a Šablony knihovny pomocí ověřovacích pravidel, jako jsou možnosti vybrat přesně, alespoň, nejvýše nebo rozsah X z Y. Hromadné odeslání, webové formuláře a vlastní pracovní postupy jsou podporovány prostřednictvím používání šablon knihoven. Toto vylepšení zajišťuje konzistentní logiku formulářů a zlepšuje přesnost dat napříč pracovními postupy podepisování.
- Povolené rozsahy IP adres – rozšířená kontrola nad přístupem k rozhraní API a mobilním aplikacím – správci nyní mohou explicitně řídit, zda se omezení IP adres vztahují na klienty založené na rozhraní API, včetně mobilních aplikací Acrobat Sign a certifikovaných integrací.
- Podpora ověřování pro moderní elektronické podepisování – moderní elektronické podepisování nyní podporuje tři metody ověřování: ověřování aplikace Acrobat Sign, heslo a dvoufaktorové ověřování založené na telefonu.
- "Přidání skupin příjemců v hybridním směrování pro moderní Request Signature – Skupiny příjemců lze nyní zahrnout do hybridního směrování, což umožňuje více příjemcům nebo skupinám pracovat paralelně v rámci stejného kroku směrování. Režimy skupin podporují dokončení akce buď jedním, nebo všemi členy, což poskytuje větší flexibilitu pro složité pracovní postupy schvalování a podepisování.
- Kopírování ukončených dohod odeslaných z části Požádat o podpis—Odesílatelé si nyní mohou vytvořit nový koncept dohody zkopírováním dříve dokončené, zrušené nebo vypršené dohody. Všichni příjemci, nastavení, soubory a pole formulářů se automaticky předvyplní. Zkopírovaná smlouva se otevře na stránce Compose pro rychlé úpravy před odesláním, což zkracuje čas potřebný k nastavení, minimalizuje chyby a zvyšuje produktivitu u opakujících se pracovních postupů, jako jsou obnovení nebo opravy.
- Zakázání odkazu Stáhnout smlouvu pro probíhající smlouvy – Správci nyní mohou odstranit odkaz „Stáhnout kopii" ze stránek s potvrzením po podpisu na úrovni účtu nebo skupiny, čímž zabrání příjemcům ve stahování smluv ze stránky po podpisu.
- Karta Zdroje v horní navigaci – V horní navigaci je správcům a uživatelům k dispozici nová stránka Zdroje, která nabízí přímý přístup ke vzdělávacímu obsahu aplikace Acrobat Sign, webinářům, blogům a videím o aktualizacích produktu. Stránka organizuje výukové materiály podle úrovně uživatele – začátečník, pokročilý a správce – a odkazuje přímo na další podpůrnou dokumentaci.
- Dynamická účast v probíhajících dohodách – Odebrání příjemců – Odesílatelé nyní mohou odebrat příjemce z již probíhajících dohod, aniž by museli transakci zrušit nebo restartovat. Když je příjemce odebrán, aplikace Acrobat Sign automaticky zruší jeho přístup, aktualizuje připomínky, auditní záznamy, odstraní přiřazená pole a plynule převede dohodu zpět do aktivního stavu podepisování. Tato flexibilita pomáhá organizacím udržovat přesnost v pracovních postupech živého směrování – například když se podepisující stane nedostupným – při zachování právní integrity, souladu s předpisy a úplné historie auditu.
- Vyžadování digitálních podpisů pro jednotlivé příjemce během konfigurace dohody – Odesílatelé nyní mohou vyžadovat digitální podpisy pro vybrané příjemce a zajistit tak přísnější požadavky na podepisování tam, kde je to potřeba, aniž by to ovlivnilo ostatní příjemce. Prostředí pro podepisování se automaticky přizpůsobuje, vynucuje povinná pole digitálního podpisu a odhaluje kontroly identity, pokud jsou podporovány, čímž snižuje chyby a zlepšuje soulad s předpisy pro regulované pracovní postupy.
- Poskytovatelé digitální identity jako výchozí metody ověřování – Správci nyní mohou v části Nastavení odeslání vybrat poskytovatele brány k ověření digitální identity jako výchozí metodu ověřování podepisujícího pro interní a externí příjemce. Konfigurace se automaticky aplikuje na dohody, webové formuláře, hromadné odesílání a pracovní postupy, což zajišťuje konzistentní a požadavky předpisů splňující ověření příjemců. Toto vylepšení zjednodušuje nastavení ověřování, vynucuje zásady organizační identity a zlepšuje podporu pro vládní a podnikové zákazníky, kteří se spoléhají na ověřování založené na digitální identitě.
- Ověřená pole formuláře používají data ověřená identitou – Autoři formulářů nyní mohou vytvořit ověřená pole formulářů, která se automaticky vyplní daty vrácenými poskytovatelem identity (například OneID) během ověřování podepisujícího. Tato pole lze nastavit do stavu pouze pro čtení nebo upravitelná a zajistit tak přesné zachycení ověřených dat identity a jejich případné uzamknutí před úpravami (např. jméno, adresa nebo číslo účtu). Tím se posiluje ověření identity, snižují se chyby při ručním zadávání a zjednodušuje se dodržování předpisů pro pracovní postupy, které vyžadují ověřená data podepisujících.
- Skupiny příjemců v souboru CSV pro hromadné odesílání – Odesílatelé nyní mohou definovat skupiny příjemců přímo v souboru CSV Hromadné odeslání, což umožňuje více příjemcům jednat ve stejném kroku směrování. Každou skupinu lze nakonfigurovat v režimu JEDEN nebo VŠICHNI – vyžaduje k dokončení akce před pokračováním směrování jednoho člena, nebo všechny členy. Definice skupin, ověřování a sledování auditu se zpracovávají podle jednotlivých řádků CSV, přičemž chyby jsou hlášeny prostřednictvím souborů ověření, které lze stáhnout.
- Šablona knihovny – Sdílení s více skupinami – Moderní prostředí Vytvoření šablony knihovny nyní podporuje sdílení šablon s více skupinami v rámci účtu, což odpovídá funkcionalitě dříve dostupné v klasickém pracovním postupu. Uživatelé mohou při vytváření nebo úpravě šablony vybrat jednu nebo více skupin, což zajišťuje konzistentní chování napříč skupinami. Toto vylepšení eliminuje návrat ke klasickému prostředí, zlepšuje spolupráci a zjednodušuje správu šablon pro organizace s více skupinami.
- Přílohy souborů pro všechny příjemce používající digitální podpisy – Všichni příjemci v pracovním postupu s digitálním podpisem nyní mohou připojovat soubory (nejen první podepisující). Nová metoda připojování pomocí anotací sponkou zobrazuje v dokumentu viditelnou ikonu sponky a je i nadále kompatibilní s více digitálními podpisy. Každá příloha je přidána před aplikováním digitálního podpisu podepisujícího, čímž se zachová platnost podpisu a vznikne jasný vizuální indikátor připojených souborů. Toto vylepšení zlepšuje právní integritu, transparentnost a konzistenci napříč pracovními postupy e-podpisu a digitálního podpisu.
Změny v prostředí
- Oznámení o zrušení smlouvy o pracovních postupech – Oznámení o zrušení bylo aktualizováno tak, aby odráželo chování pracovních postupů.
Při rušení smlouvy vytvořené prostřednictvím pracovních postupů se již nezobrazuje zaškrtávací políčko „Upozornit příjemce".Oznámení se vždy odesílají na základě Nastavení pracovních postupů.Tato změna upravuje zprávu tak, aby odrážela toto chování ve výzvě ke zrušení.
- Vylepšení přihlašovací stránky – Přihlašovací stránka Acrobat Sign nyní nabízí přehlednější a jednotnější prostředí. Jakmile zadáte svou e-mailovou adresu, stránka automaticky rozpozná typ vašeho účtu a přesměruje vás na správnou metodu přihlášení, čímž se odstraní zbytečné kroky a zobrazování zastaralých obrazovek. Díky tomu je přihlašování pro všechny rychlejší, jednodušší a intuitivnější.
- Nový formát e-mailu pro podnikové uživatele aplikace Acrobat Sign, kteří se přihlašují přímo do webového rozhraní – Aplikace Acrobat Sign nyní při úpravě existujícího e-mailu nebo vytváření nového uživatele vynucuje 64znakový limit pro místní část e-mailové adresy (část před symbolem „@“).
Všichni uživatelé s místní částí delší než 64 znaků byli vyhodnoceni a nastaveni jako neaktivní nebo testovací uživatelská jména.
- Nový formát e-mailu pro podnikové uživatele aplikace Acrobat Sign, kteří se přihlašují přímo do webového rozhraní – Aplikace Acrobat Sign nyní při úpravě existujícího e-mailu nebo vytváření nového uživatele vynucuje 64znakový limit pro místní část e-mailové adresy (část před symbolem „@“).
Upozorňujeme, že tato funkce je poskytována prostřednictvím postupného vydání založeného na serverovém prostředí aplikace Acrobat Sign.Harmonogram vydání je publikován v technickém oznámení Aktualizované přihlašovací prostředí.
- Povolení správy podrobností uživatele pro neaktivní uživatele – Správci nyní mohou upravovat podrobnosti neaktivních uživatelů přímo v uživatelském rozhraní správce a prostřednictvím nahrávání souborů CSV bez nutnosti opětovné aktivace účtů. Patří sem aktualizace přiřazení skupin (pro konfigurace s jednou i více skupinami), správa atributu „Uživatel může podepisovat dokumenty“ a provádění hromadných úprav pro dodržování předpisů a údržbu záznamů. Tato změna zjednodušuje správu životního cyklu podnikových uživatelů, snižuje administrativní zátěž a podporuje čistší organizaci skupin a zpracování záznamů v souladu s GDPR.
Vyřešené problémy
| Problém | Popis |
|---|---|
| 4528600 | Shrnutí: Nastavení ověřování polí nefungují, když je vrstva polí formuláře připojena k vlastnímu pracovnímu postupu. Pravidla ověřování, jako jsou regulární výrazy nebo omezení číselných rozsahů, se při spuštění pracovního postupu odeberou, což způsobí, že pole přijímají neplatné vstupy. |
| Oprava: Pravidla ověřování se nyní používají správně, když jsou vrstvy formulářových polí součástí vlastních pracovních postupů. Pole mají stejné chování při ověřování v klasickém i novém prostředí pro tvorbu. Od uživatelů není vyžadována žádná akce. | |
| 4528748 | Shrnutí: Při přidávání členství ve skupině nově synchronizovaným uživatelům (synchronizace Azure) správci občas vidí „Neošetřenou chybu“. Někteří noví uživatelé ve skupině mají groupID nastavené jako null |
| Oprava: Pokud má skupina uživatele po vytvoření hodnotu null, dojde k jeho umístění do výchozí skupiny účtu. | |
| 4529934 | Shrnutí: V části Správa > Webové formuláře se neustále načítá funkce „Stáhnout data polí formuláře“ a toto načítání nikdy neskončí – zejména u webových formulářů s mnoha příspěvky. Zákazníci aplikace Teams bez přístupu k rozhraní API nemohou exportovat data (např. 1.–31. května) pro účely vytváření sestav |
| Oprava: Do uživatelského rozhraní byl přidán stránkovaný, rychlejší export CSV. Stahování dat formuláře se dokončuje spolehlivě pro vybrané rozsahy dat bez zasekávání. | |
| 4532186 | Shrnutí: V novém prostředí pro vytváření se zvýrazňování barev polí neshoduje s chováním klasického prostředí pro vytváření. Když je zapojeno více příjemců, zůstávají všechna pole plně vybarvená namísto ztmavení polí nevybraných příjemců. Ztěžuje to ověření přiřazení polí. |
| Oprava: Obnovena vizuální jasnost ztmavením (20% neprůhlednost) polí, která patří nevybraným příjemcům. Tím se replikuje zřetelnost klasického prostředí pro vytváření při zachování moderního systému návrhu. Zvýraznění nyní pomáhá uživatelům snadno identifikovat pole aktuálně vybraného příjemce a snižuje riziko nesprávného přiřazení. | |
| 4534061 | Shrnutí: Odkaz „Stáhnout kopii“ se zobrazuje na stránce s potvrzením po podpisu, i když je nastavení účtu nebo skupiny nakonfigurováno tak, aby jej zakázalo. |
| Oprava: Bylo přidáno nové nastavení pro explicitní potlačení možnosti Stáhnout na všech stránkách po odeslání. Stránka po podpisu nyní správně respektuje nastavení ovládání stahování a skrývá odkaz „Stáhnout kopii“, když je toto nastavení zakázáno. | |
| 4536347 | Shrnutí: V klasickém prostředí nemohli odesílatelé kvůli chybě ve způsobu, jakým výběr souborů zpracovával šablony sdílené napříč více skupinami, přidat druhý soubor (nebo opakovat přidání souboru) při spouštění určitých pracovních postupů, čímž docházelo k blokování pracovních postupů odesílání více dokumentů. |
| Oprava: Opraveno zpracování šablon sdílených napříč více skupinami při výběru souborů, takže uživatelé mohou v klasickém prostředí přidávat další soubory nebo opakovat výběr souborů bez chyb. | |
| 4537504 | Shrnutí: V podepsaném dokumentu chyběla hodnota podmíněného rozbalovacího seznamu, i když byla během podepisování správně vybrána. Důvodem byla logika viditelnosti, která vyhodnocovala skryté závislé pole a neuložila vykreslenou hodnotu do konečného podepsaného PDF. |
| Oprava: Vykreslování podmíněných polí bylo aktualizováno tak, aby správně vyřešilo závislosti viditelnosti v době podepisování a v případě splnění podmínek uložilo vybranou hodnotu rozbalovacího seznamu do podepsaného dokumentu. | |
| 4537995 | Shrnutí: Změna metody ověřování externích uživatelů ve skupinách příjemců se po uložení vrátila na Telefon, což zabránilo použití jednorázového hesla na e-mail. Důvodem byla chyba v obsluze stavu uživatelského rozhraní, která přepsala výběr uživatele. |
| Oprava: Opravena logika uživatelského rozhraní skupin příjemců tak, aby správně zachovala a znovu použila vybranou metodu ověřování napříč akcemi ukládání a zajistila tak, že zvolená hodnota bude zachována a nedojde k obnovení výchozí hodnoty. | |
| 4539214 | Shrnutí: Ve vlastních pracovních postupech způsobuje dlouhý popisek zprávy překrývání textu zprávy a zakrývání hypertextového odkazu šablony zprávy na stránce Odeslat kvůli nesprávnému zpracování rozvržení nadměrného obsahu popisku. |
| Oprava: Aktualizována logika rozvržení stránky Odeslat tak, aby správně omezila a zalomila dlouhé popisky zpráv tak, aby hypertextový odkaz šablony zprávy zůstal viditelný a přístupný. | |
| 4539854 | Shrnutí: Někteří podepisující jsou přesměrováni pryč z prostředí podepisováním při otevírání určitých dohod kvůli chybnému poli odkazu v podkladovém dokumentu, kterému chybí požadovaný atribut názvu. |
| Oprava: Tok podepisování nyní správně zpracovává nepojmenovaná pole odkazů tak, že jim v době zpracování přiřadí platný název, čímž předchází chybám a umožňuje podepisujícím dokončit dohody bez přesměrování. | |
| 4539858 | Shrnutí: Na zařízeních iOS nemohou schvalovatelé používající klávesnici pro čínský rukopis dokončit schválení, protože tlačítko Schválit zůstává po zadání jména zakázané, jelikož stránka pro podepisování nerozpoznává události vstupu rukopisu jako platné zadávání textu. |
| Oprava: Byla aktualizována logika zpracování vstupu tak, aby v systému iOS rozpoznávala textový vstup založený na rukopisu, čímž se zajistí správná aktivace tlačítka Schválit po zadání platných znaků. | |
| 4540392 | Shrnutí: Správcům se při pracovních postupech občas zobrazují chyby HTTP 400 a zdá se, že skupiny příjemců chybí, i když skupiny existují a přístup je správně nakonfigurován. Důvodem jsou hlavičky požadavků překračující limit velikosti hlaviček platformy, pokud uživatelé patří do velkého počtu skupin. |
| Oprava: Byl zvýšen limit velikosti hlaviček požadavků na straně serveru, takže vyhledávání skupin příjemců již neselže, když jsou uživatelé členy mnoha skupin. | |
| 4541258 | Shrnutí: Správci viděli v produkčním uživatelském rozhraní nebo v uživatelském rozhraní Sandbox Sync pouze prvních 100 šablon, přičemž další šablony chyběly v seznamech Místní a Vzdálené. Důvodem bylo načítání omezeného souboru dat na stránce synchronizace a funkce vyhledávání filtrovala pouze šablony již načtené v prohlížeči. |
| Oprava: Uživatelské rozhraní synchronizace bylo aktualizováno tak, aby se při zadání textu do vyhledávacího pole načetly všechny šablony pro vybrané prostředí (až 5 000), což zajistí, že pro vyhledávání a výběr budou k dispozici šablony nad rámec počátečních 100 | |
| 4541739 | Shrnutí: Nahrazeným příjemcům bylo zabráněno v digitálním podepsání a zobrazila se jim zpráva „Dohodu nelze digitálně podepsat, protože není ve fázi digitálního podpisu“. Bylo to způsobeno tím, že pracovní postup nedokázal převést budoucí nahrazené podepisující do fáze digitálního podepisování, když byla přítomna pole pro digitální podpis. |
| Oprava: Pracovní postup podepisování byl aktualizován tak, aby správně převedl nahrazené nebo delegované příjemce do fáze digitálního podepisování, existují-li pole pro digitální podpis, a umožnil jim tak podepsat a dokončit dohodu. | |
| 4541849 | Shrnutí: Jednořádková textová pole s automatickou velikostí písma předvyplněná vícebajtovými znaky byla v podepsaných souborech PDF zkrácena, což během vykreslování PDF způsobilo oříznutí části textu kvůli nesprávné velikosti textu. |
| Oprava: Opraveno měření textu a chování automatické velikosti písma u vícebajtových znaků, aby se celá hodnota vešla do pole bez zkrácení. | |
| 4542574 | Shrnutí: Při úpravě šablony knihovny mohlo dojít k zahrnutí nespárovaných hodnot do povinných rozbalovacích polí, což způsobilo, že tlačítko Kliknutím podepište zůstalo během podepisování nedostupné, když byly tyto hodnoty vybrány, kvůli chybějící validaci, která zajišťovala správné spárování zobrazovaných hodnot rozbalovacích nabídek a hodnot exportu. |
| Oprava: Při úpravách šablon je nyní vynucováno ověření rozbalovacích polí, takže lze uložit pouze správně spárované hodnoty, což zabraňuje vzniku nespárovaných záznamů a zajišťuje, že požadované výběry z rozbalovacích nabídek neblokují podepisování. | |
| 4542942 | Shrnutí: Ve webových formulářích zobrazovala povinná pole zakázaná podmíněnou logikou i nadále hvězdičky označující povinnost, což vedlo podepisující k mylnému přesvědčení, že je stále vyžadován vstup. Bylo to způsobeno tím, že uživatelské rozhraní při zakázání polí neaktualizovalo indikátory povinnosti. Byl identifikován samostatný problém se zarovnáním podpisu na mobilních zařízeních, který byl ale vyřešen v rámci jiného rozsahu. |
| Oprava: Uživatelské rozhraní webového formuláře nyní skrývá hvězdičku povinnosti, když je pole zakázáno podmíněnou logikou, což zajišťuje, že indikátory povinnosti přesně odrážejí, zda je očekáván vstup od podepisujícího. | |
| 4543157 | Shrnutí: V zobrazení Probíhá na stránce Správa sloupec Příjemci i nadále zobrazoval jméno delegující osoby poté, co byla role podepisování delegována, přestože aktivně podepisoval jiný podepisující. Bylo to způsobeno tím, že uživatelské rozhraní neaktualizovalo zobrazeného příjemce tak, aby odrážel aktuálně delegovanou osobu. |
| Oprava: Logika stránky Správa byla aktualizována tak, aby sloupec Příjemci nyní zobrazoval jméno primární delegované osoby, když je role podepisování delegována, což zajišťuje, že zobrazení Probíhá přesně odráží, kdo aktuálně podepisuje. | |
| 4543253 | Shrnutí: V klasickém prostředí pracovního postupu zmizela po uložení dohody ve stavu Koncept pole přiřazená svědkovi (podpis, jméno, datum), i když tato pole existovala v backendu, protože logika vykreslování konceptu nedokázala při uložení průběhu obnovit pole svědka. |
| Oprava: Logika vykreslování konceptů byla opravena tak, aby po uložení průběhu zachovala a zobrazovala všechna pole přiřazená svědky, čímž je zajištěno, že dohody otevřené ve stavu Koncept si zachovají stejnou viditelnost polí jako během vytváření a podepisování. | |
| 4543513 | Shrnutí: Uživatelé nemohli odesílat dohody v uživatelském rozhraní webové aplikace Sign s chybou „Národní prostředí je neplatné nebo chybí“. Důvodem bylo ověřování národního prostředí, které nesprávně vynucovalo pravidla národního prostředí na úrovni API ve webovém rozhraní, když se národní prostředí odesílající skupiny lišilo od národního prostředí primární skupiny zděděného uživatelem. |
| Oprava: Ověřování národního prostředí bylo opraveno, takže uživatelské rozhraní webové aplikace Sign nyní správně rozpoznává a přijímá platné kombinace národního prostředí skupin a uživatelů, čímž předchází omezením národního prostředí vztahujícím se pouze na rozhraní API v blokování odesílání dohod ve webovém prostředí. | |
| 4543592 | Shrnutí: Některé zprávy o auditu po zobrazení zprávy „Dokument elektronicky podepsán“ a „Dohoda dokončena“ zobrazovaly zprávu „Příjemce ověřen pomocí Adobe Acrobat Sign“. Důvodem bylo ukládání událostí s časovými razítky na úrovni sekund, což způsobovalo, že akce ověření a podpisu probíhající ve stejné sekundě se zobrazovaly v nesprávném pořadí. |
| Oprava: Protokolování událostí auditu bylo aktualizováno tak, aby ukládalo a zobrazovalo časová razítka s přesností na milisekundy, čímž je zajištěno správné seřazení událostí ověření, podepsání a dokončení ve zprávě o auditu. | |
| 4543617 | Shrnutí: Vytvoření šablony z dohody spustí klasické prostředí namísto nového prostředí, přestože je nové prostředí výchozí, protože akce je stále směrována do starší verze toku pro vytváření obsahu. |
| Oprava: Akce „vytvořit šablonu z dohody“ byla aktualizována tak, aby se otevírala v novém prostředí, čímž se chování CTA sladí s výchozím prostředím UX a zabrání se neočekávaným přepnutím kontextu pro uživatele. | |
| 4544564 | Shrnutí: Skrytá pole přidaná nebo aktualizovaná prostřednictvím rozhraní API (visible:false) se v moderním prostředí eSign zobrazovala jako viditelná. Uživatelské rozhraní pro podepisování ignorovalo příznak viditelnosti pole, takže příjemci viděli pole, která měla zůstat skrytá. |
| Oprava: Aktualizováno moderní uživatelské rozhraní eSign tak, aby filtrovalo pole, kde je viditelnost nastavena na hodnotu false napříč logikou vykreslování a navigace, takže skrytá pole se nikdy nezobrazí a neovlivní chování stránky. | |
| 4544571 | Shrnutí: Možnost doručení přes WhatsApp chyběla v Nastavení odesílání, i když byla služba WhatsApp pro účet během odesílání dohody povolena a dostupná, což způsobovalo nekonzistentní chování a zmatky pro správce. |
| Oprava: Možnost doručení přes WhatsApp byla v Nastavení odesílání obnovena všude tam, kde je tato funkce dostupná, což zajišťuje konzistentní viditelnost a konfiguraci mezi nastavením správce a prostředím pro odesílání dohod. | |
| 4545381 | Shrnutí: Písmo Roboto chybělo v novém prostředí pro žádosti o podpisy, přestože bylo dostupné v klasickém prostředí, protože nové prostředí pro vytváření neobsahovalo všechna písma podporovaná ve starší verzi. |
| Oprava: Písmo Roboto bylo přidáno do seznamu písem v novém prostředí pro žádosti o podpisy, čímž byla obnovena parita písem s klasickým prostředím a umožněno konzistentní formátování při vytváření dohod. | |
| 4545484 | Shrnutí: Někteří správci nemohli přistupovat ke skupinám příjemců nebo je vytvořit z nabídky Správce > Adresář kvůli selhání požadavku na backend, což vedlo k chybě 400 při načítání dat skupin příjemců. Tento problém způsoboval zablokování počátečního nastavení skupin příjemců pro dotyčné správce. |
| Oprava: Opraveno zpracování požadavků na backend, takže vyhledávání a vytváření skupin příjemců již neselhává s chybou 400. Správci nyní mohou spolehlivě přistupovat ke skupinám příjemců a spravovat je bez ohledu na síť nebo umístění. | |
| 4545547 | Shrnutí: Dohody vytvořené z PDF souborů aplikace AutoCAD se nedařilo odesílat, když bylo přidáno pole digitálního podpisu, a zobrazila se obecná chyba odesílání, protože systém při ověřování umístění pole digitálního podpisu nesprávně zpracovával otočení stránky. |
| Oprava: Souřadnice pole digitálního podpisu byly upraveny tak, aby zohledňovaly otočené stránky, což zajišťuje, že se pole porovnávají se správnými ohraničeními stránky, takže PDF soubory vygenerované aplikací AutoCAD lze úspěšně odesílat s digitálními podpisy. | |
| 4545894 | Shrnutí: Když se používá skupina příjemců a nedojde k ručnímu umístění žádného pole podpisu, automaticky vygenerovaný blok podpisu zobrazuje text e-mailové adresy s velmi malou velikostí. S přidáváním dalších příjemců do skupiny se text postupně zmenšuje. |
| Oprava: Automaticky vygenerovaný blok podpisu nyní správně vykresluje e-mailovou adresu s normální, čitelnou velikostí, bez ohledu na to, kolik příjemců je zahrnuto ve skupině příjemců. | |
| 4546085 | Shrnutí: Při použití funkce Přidat sebe v novém prostředí pro žádosti o podpisy se e-mailové adresy obsahující apostrof nezobrazují správně. Poškozená adresa brání odeslání dohody, pokud se e-mail ručně nezadá znovu nebo se nepoužije klasické odesílání. |
| Oprava: E-mailové adresy s apostrofy se nyní správně dekódují a zobrazují, když je v novém prostředí pro žádosti o podpisy vybrána možnost Přidat sebe, což umožňuje odesílání dohod bez ruční opravy. | |
| 4546110 | Shrnutí: V prostředí pro vytváření nových šablon způsobuje přidání pole Hypertextový odkaz přiřazené konkrétnímu účastníkovi selhání uložení šablony. Stejné pole funguje, když je přiřazeno všem účastníkům nebo při použití klasického prostředí. |
| Oprava: Pole Hypertextový odkaz nyní v prostředí Nová šablona podporují přiřazení zástupných účastníků, což umožňuje správné uložení šablon, když je pole přiřazeno konkrétnímu účastníkovi. | |
| 4546257 | Shrnutí: Dohody odeslané v prostředí Sandbox prostřednictvím API vlastní aplikace nesprávně zobrazují tlačítko Zpět na stránce pro vytváření, protože Sandbox načítá nastavení z aplikace spravované společností Adobe s povoleným bezproblémovým vytvářením, na rozdíl od prostředí Swagger nebo produkčního prostředí. |
| Oprava: Chování prostředí Sandbox bylo sladěno s produkčním prostředím a prostředím Swagger tak, že stránka pro vytváření respektuje zamýšlená nastavení aplikace, což zabrání zobrazení tlačítka Zpět u dohod odeslaných prostřednictvím rozhraní API vlastních aplikací. | |
| 4546547 | Shrnutí: Webové formuláře nedokázaly aktualizovat druhé podepisující a vracely různé chyby kvůli starším záznamům uživatelů, kterým chyběl požadovaný interní příznak, což způsobovalo zpracování nulové hodnoty během nahrazování druhého podepisujícího. |
| Oprava: Logika aktualizace druhého podepisujícího byla vylepšena o bezpečné zpracování nulových hodnot, takže webové formuláře mohou úspěšně nahradit druhé podepisující i v případě, že u starších záznamů uživatelů chybí očekávaný interní příznak. | |
| 4546553 | Shrnutí: Uživatelé přiřazení do více skupin mohli vytvářet šablony ve skupině, kde je vytváření šablon zakázáno, když je povoleno nové prostředí vytváření šablon. To umožnilo obejít omezení na úrovni skupiny. |
| Oprava: Vytváření šablon nyní důsledně vynucuje oprávnění na úrovni skupiny napříč novým i klasickým prostředím. Uživatelé již nemohou vytvořit šablony ve skupinách, kde je vytváření šablon zakázáno, ani když patří do jiných skupin, kde je toto oprávnění povoleno. | |
| 4547744 | Shrnutí: Správci skupin mohli přiřazovat práva správce účtu uživatelům prostřednictvím nové stránky Správa uživatelů. Tím docházelo k překročení jejich oprávnění a vznikalo riziko týkající se dodržování předpisů tím, že bylo možné zvýšit oprávnění nad rámec role správce skupiny. |
| Oprava: Ovládací prvek pro výběr role již není správcům skupin k dispozici. Oprávnění správce účtu mohou přidělit nebo odebrat pouze stávající správci účtu, což zajišťuje, že změny rolí odpovídají hranicím oprávnění. | |
| 4547796 | Shrnutí: Někteří odesílatelé používající polské uživatelské rozhraní občas obdrží potvrzovací e-mail s nesprávným textem „nelze poskytnout digitální podpis“, i když se dohoda odešle a podepíše normálně. |
| Oprava: Opraveny polské překlady pro e-maily s potvrzením odesílatele, takže zpráva nyní zobrazuje zprávu „odesláno k podpisu“ namísto nesprávného textu „nelze poskytnout digitální podpis". | |
| 4548315 | Shrnutí: Když je odesílatel uveden jako příjemce v kopii v novém pracovním postupu Odeslat, nezobrazí se žádná chyba ověření a e-mailová oznámení v kopii nejsou odeslána žádným příjemcům uvedeným po odesílateli v seznamu příjemců v kopii. Toto chování se liší od chování klasického pracovního postupu a může způsobit, že si příjemci kopií oznámení nevšimnou. |
| Oprava: Aktualizována logika nového pracovního postupu Odeslat tak, aby všichni příjemci v kopii, kromě odesílatele, obdrželi e-mailová oznámení o kopii bez ohledu na jejich pozici v seznamu příjemců v kopii, čímž se chování sladí s očekávanými výsledky. | |
| 4548583 | Shrnutí: PDF/A nebylo možné povolit pro skupinu, pokud měla výchozí skupina uživatele povolené vlastnoruční podpisy, a to i když byly písemné podpisy pro upravovanou skupinu zakázané. Docházelo tak k blokování platné konfigurace PDF/A pro nevýchozí skupiny. |
| Oprava: Ověření bylo aktualizováno tak, aby kontrolovalo nastavení vlastnoručních podpisů ve skupině, která se upravuje, nikoli ve výchozí skupině uživatele, což umožňuje správné povolení PDF/A tam, kde je to povoleno. | |
| 4549337 | Shrnutí: SMS oznámení zrušených dohod byla potlačena, když bylo zakázáno nastavení E-mail o zrušení dohody. To zabránilo zákazníkům, kteří zakážou e-mailová oznámení, v odesílání požadovaných SMS upozornění o zrušení. |
| Oprava: Oddělena SMS a WhatsApp oznámení o zrušení od nastavení e-mailu zavedením vyhrazeného ovládání oznámení, což umožňuje doručování SMS o zrušených dohodách, i když jsou e-mailová oznámení zakázána. | |
| 4549472 | Shrnutí: V aplikaci Acrobat Sign pro státní správu nemohli uživatelé vytvořit opakovaně použitelné šablony pomocí nového prostředí vytváření šablon. Po nahrání dokumentu se pracovní postup zastavil na prázdné obrazovce, což blokovalo vytváření šablon. |
| Oprava: Obnovena chybějící závislost pro vytváření, kterou vyžaduje nové prostředí vytváření šablon v prostředích pro státní správu, což umožňuje správné načtení obrazovky pro vytváření a úspěšné vytváření šablon. | |
| 4549862 | Shrnutí: Když je na hlavní stránce nastaveno nové prostředí pro žádosti o podpisy, nakonfigurovaná zpráva s upozorněním na přihlášení se po přihlášení nezobrazí. Organizace tak nemohou zobrazovat kritická upozornění o údržbě nebo výpadcích, když uživatelé přejdou přímo na stránku Odeslat. |
| Oprava: Obnovena podpora zobrazování zprávy s upozorněním při přihlášení v novém prostředí pro žádosti o podpisy. Když uživatelé po přihlášení přejdou na stránku Odeslat, nakonfigurovaná zpráva s upozorněním se nyní zobrazí jako oznámení, což odpovídá předchozímu chování a očekáváním zákazníků. | |
| 4550175 | Shrnutí: Stisknutím klávesy Enter po zadání telefonního čísla pro ověření telefonu v pracovním postupu se formulář předčasně odešle a dojde k vyvolání systémové chyby, čímž se přeruší tok pracovního postupu z důvodu odeslání formuláře místo čekání na explicitní potvrzení. |
| Oprava: Aktualizováno dialogové okno příjemce, aby se zabránilo odeslání formuláře klávesou Enter u polí pro ověření telefonu, což zajišťuje, že uživatelé zůstanou v dialogovém okně a musí kliknout na možnost Pokračovat, čímž se eliminuje nechtěné přerušení pracovního postupu. | |
| 4550302 | Shrnutí: E-maily s žádostí o podpis a připomínkami v němčině používaly nekonzistentní formy oslovení, přepínaly mezi neformálním „Du“ a formálním „Sie“ ve stejné zprávě, čímž vznikaly matoucí a neprofesionální formulace. |
| Oprava: Aktualizovány německé překlady e-mailů tak, aby používaly jednu konzistentní formu oslovení v celé šabloně, což zajišťuje jednotný a předvídatelný jazyk ve všech e-mailech s žádostí o podpis a připomínkami. | |
| 4550556 | Shrnutí: Dohody obsahující PDF s velkými architektonickými plány se nedařilo odeslat, když byla přidána pole pro digitální podpis; během vytváření se vrátila chyba kvůli otočení stránky a zpracování velikosti při umístění digitálního podpisu. |
| Oprava: Aktualizováno zpracování polí digitálního podpisu pro správné zpracování otočených stránek velkého formátu, což umožňuje úspěšné odeslání dohod s architektonickými plány s aplikovanými digitálními podpisy. | |
| 4550579 | Shrnutí: Když byla dohoda dokončena odebráním posledních zbývajících příjemců během stavu revize, systém nevygeneroval událost AGREEMENT_WORKFLOW_COMPLETED, takže nebylo odesláno oznámení webhook, což narušilo pracovní postupy, které se spoléhají na tuto událost k detekci dokončení. |
| Oprava: Aktualizováno zpracování událostí, takže dohody dokončené prostřednictvím odebrání příjemce v revizi nyní generují příslušné události dokončení, což zajišťuje spuštění webhooků AGREEMENT_WORKFLOW_COMPLETED podle očekávání. | |
| 4550998 | Shrnutí: Předvyplněná zaškrtávací políčka se zobrazovala jako zaškrtnutá při vytváření, ale pro podepisující zaškrtnutá nebyla, protože hodnoty zaškrtávacích políček byly uloženy jako neprázdné textové řetězce místo explicitních stavů ANO/NE, což způsobilo, že je prostředí pro podepisování považovalo za nezaškrtnuté. |
| Oprava: Aktualizováno zpracování hodnot zaškrtávacích políček, takže jakákoli neprázdná předvyplněná hodnota je interpretována jako zaškrtnutá a prázdné nebo chybějící hodnoty jako nezaškrtnuté, což zajišťuje konzistentní stavy zaškrtávacích políček pro podepisující. |