Technická oznámení

Naposledy aktualizováno 29. 6. 2026

Projděte si uvedená technická oznámení a přidejte si do záložek ta, která jsou pro vás důležitá.

Tip

Stránka s technickými oznámeními je pravidelně aktualizována novými informacemi, což činí její obsah vysoce dynamickým. I když jsou k dispozici lokalizované verze, může proces překladu způsobit drobné odchylky od autoritativní verze v americké angličtině. Pro nejpřesnější a nejaktuálnější informace se vždy nejprve podívejte na stránku v americké angličtině.

[Příští vydání] Příští vydání aplikace Adobe Acrobat Sign je naplánováno na 8. září 2026 v17.2

Toto menší opravné vydání se zaměří na řešení chyb nahlášených zákazníky a aplikuje nezbytné optimalizace a bezpečnostní aktualizace.

Testovací prostředí obdrží tyto opravy čtyři týdny před plánovaným vydáním. Seznam vyřešených problémů bude zveřejněn v té době a aktualizován 14 dní před vydáním.

Vydání funkcí: Adobe Acrobat Sign – 21. července Vydání dokončeno

Vydání bylo dokončeno pro všechny shardy bez výpadku jakýchkoli služeb.

Aktuální oznámení:

Stav

Problém nebo událost

Datum provedení

Nový

Příští vydání

Od 8. září 2026

Nový

Příští vydání

Průběžné 
vydání

Od 16. června

Aktualizované

Důležité

Aktuální

5. května 2026

Aktualizované

Září 2026

Aktualizované

Průběžné 
vydání

Září 2026

Průběžné 
vydání

Příští hlavní vydání

Září 2026

Důležité

Počínaje březnem 2026

Aktualizované

2027

Aktuální

Září 2026

Trvalá informační oznámení

Aktuální

Informativní

Aktuální

Aktuální

Informativní

Aktuální


Postupné zavádění vylepšení vytváření polí formuláře

První hlášení: březen 2026

Aktuální

Adobe Acrobat Sign aktualizuje moderní prostředí pro vytváření polí formuláře jako součást vydání 17.2.Aktualizované prostředí se bude postupně zpřístupňovat podle segmentu zákazníků.

Co se mění

Aktualizace přináší vylepšení použitelnosti pro přípravu polí formuláře, včetně:

  • Vylepšené ovládání pro práci s navrhovanými poli.
  • Panel Pole pro kontrolu umístěných polí podle stránky nebo příjemce a přímou navigaci k poli.
  • Výstižnější názvy pro automaticky rozpoznaná pole.
  • Vylepšené rozpoznávání typu pole pro běžná pole.
  • Jasnější zprávy o ověření specifické pro pole.
  • Pokyn pro přiřazení příjemce u nahraných PDF, které obsahují stávající pole AcroForm.
  • Kontextové pokyny pro běžné autorské úkoly.

Změny se vztahují na moderní prostředí vytváření používané s šablonami Požádat o podpisy a Knihovna.

Webové formuláře a Hromadné odesílání nadále používají klasické prostředí vytváření a nejsou zahrnuty do tohoto zavádění.

Harmonogram zavádění

Adobe povolí aktualizované prostředí ve fázích:

Fáze zavádění Segment zákazníků
Počáteční zavádění VIP, SMB a Mid-Market.
Následné zavedení ETLA a Zkušební verze — datum bude oznámeno
   

Termíny pro následné fáze zavedení ETLA a Zkušební verze budou aktualizovány po jejich potvrzení.

Akce správce

Není vyžadována žádná akce správce.

Společnost Adobe zapíná aktualizované prostředí pro vytváření obsahu postupně pro jednotlivé segmenty zákazníků.Neexistuje žádné ovládání na úrovni účtu nebo skupiny pro zákazníka, které by umožňovalo povolit, zakázat nebo odložit změnu.

Správci, kteří udržují interní materiály pro školení, ověření nebo řízení změn, by měli zkontrolovat aktualizované prostředí pro vytváření a připravit uživatele na změny před povolením jejich segmentu zákazníka.

Dopad na stávající obsah

Stávající smlouvy nejsou tímto zavedením změněny.

Stávající šablony knihoven si zachovávají svou stávající konfiguraci polí.Automaticky generované názvy polí se použijí při vytváření polí pomocí aktualizovaného prostředí pro vytváření; stávající šablony nejsou migrovány na nové chování pojmenování.

Co mohou uživatelé očekávat

Uživatelé si mohou všimnout změn v ovládacích prvcích a pokynech dostupných při přípravě polí formuláře.Automaticky zjištěná pole mohou také získat popisnější názvy a vhodnější typy polí.

Autoři by měli nadále kontrolovat všechna pole formuláře, přiřazení příjemců, nastavení ověření a obsah dokumentu před odesláním smlouvy.


Úpravy dokumentu v průběhu vytváření

První hlášení: březen 2026

Aktuální

Úpravy dokumentu v průběhu vytváření jsou nasazovány prostřednictvím postupného zavádění jako součást vydání 17.1.2 pro účty VIP.

Plán zavádění:

Zákaznické účty VIP a VIPMP získávají postupné produkční zavedení po vydání 17.1.2.

Úpravy dokumentu v průběhu vytváření budou zahrnuty v nasazení Sandbox 17.2.1.Zavedení pro zákazníky ETLA se předpokládá po vydání 17.2.1.

Funkce je ve výchozím nastavení povolena na úrovni účtu jak pro nové, tak pro stávající podporované účty.Správci účtů a skupin mohou funkci podle potřeby povolit nebo zakázat.

Funkce není podporována pro:

  • Účty Acrobat Sign for Government.
  • Organizace používající starší systém správy uživatelů Acrobat Sign.

Pokyny ke konfiguraci naleznete v části Povolení nebo zakázání přímých úprav dokumentu

Pokyny k pracovnímu postupu odesílatele naleznete v části Jak upravit text během vytváření polí

Poznámka

Harmonogramy zavádění se mohou změnit v závislosti na neočekávaných událostech.


Limit prahové hodnoty dotazování API

První hlášení: srpen 2025 - aktualizováno v únoru 2026

Aktuální

Společnost Adobe zavádí práh dotazování pro koncové body GET API aplikace Adobe Acrobat Sign, aby pomohla udržet stabilitu systému a zlepšit výkon.Tato zásada omezuje, jak často mohou klientské aplikace provádět identické volání API ke službě Acrobat Sign.

Vysokofrekvenční dotazování vytváří zbytečnou zátěž na backendové systémy, což může snížit výkon a zpomalit dobu odezvy.Vývojářům API doporučujeme používat webhooky pro aktualizace téměř v reálném čase namísto opakovaného dotazování.

Co se změní

Zásada dotazování se vztahuje na všechny koncové body GET API pro identická volání.

Je použit limit na to, jak často může stejný efektivní uživatel provést stejné volání API do Acrobat Sign.Když stejný efektivní uživatel provádí identická volání častěji, než povoluje příslušný práh dotazování, je vrácena chyba.

Například opakovaný požadavek na stejný koncový bod pro stejnou smlouvu nebo dokument knihovny je považován za identické volání.Požadavky na různé smlouvy nebo dokumenty knihovny jsou považovány za odlišná volání, protože každý objekt představuje jiný cíl požadavku.

Příklady ovlivněných koncových bodů

Načítání stavu

  • GET /agreements/{agreementId} — Načítá aktuální stav smlouvy.
  • GET /agreements/{agreementId}/documents/{documentId} — Načítá datový proud souboru dokumentu v rámci smlouvy.

Výpisy, události a dokumenty knihovny

  • GET /agreements — Načítá smlouvy pro uživatele.
  • GET /agreements/{agreementId}/events — Načítá informace o událostech pro smlouvu.
  • GET /libraryDocuments — Načítá dokumenty knihovny pro uživatele.
  • GET /libraryDocuments/{libraryDocumentId} — Načítá informace pro konkrétní dokument knihovny.

Podrobnosti zásad dotazování

Minimální interval dotazování objektu (MOPI) definuje, jak často může stejný efektivní uživatel provést stejný požadavek GET API na službu Acrobat Sign.

Výchozí MOPI se liší podle úrovně služby:

  • Úrovně GLOBAL, ENTERPRISE a DEVELOPER: Tři identická volání za jednominutový interval.
  • Všechny ostatní úrovně: Tři identická volání za tříminutový interval.

Pokud stejný efektivní uživatel provádí identické požadavky GET častěji, než úroveň povoluje, Acrobat Sign vrátí odpověď 429 Too Many Requests s hlavičkou Retry-After.

Požadavek je považován za identický, když stejný efektivní uživatel provede stejný požadavek GET se stejnou cestou požadavku a hlavičkami v rámci příslušného intervalu dotazování.

Zpracování ETag

Aplikace mohou nadále používat ETags a hlavičku If-None-Match pro koncové body, které podporují podmíněné požadavky GET.

Pro podmíněné požadavky GET, které jsou povoleny pod prahem dotazování, může Acrobat Sign vrátit 304 Not Modified, když se prostředek nezměnil.

Když je překročen práh dotazování, Acrobat Sign vrátí 429 Too Many Requests s hlavičkou Retry-After, i když požadavek obsahuje hlavičku If-None-Match.

Požadovaná akce

Pokud vaše aplikace vyžaduje aktualizace téměř v reálném čase, použijte webhooks namísto dotazování.Webhooky poskytují efektivnější a škálovatelnější způsob, jak získávat včasné aktualizace.

Pokud webhooks nelze implementovat, aplikace by měly používat ukládání do mezipaměti na straně klienta pro uložení a opětovné použití odpovědí API.

  • Když obdržíte odpověď 304 Not Modified, použijte data z mezipaměti namísto dalšího volání API.
  • Když obdržíte odpověď 429 Too Many Requests, opakujte volání API až po uplynutí počtu sekund uvedeném v hlavičce Retry-After.

Zdroje

Časová osa

Aktualizované prahové hodnoty MOPI jsou již v produkci.

  • Aktualizované chování omezování ETag je zahrnuto ve verzi 17.1.1.Po této změně Acrobat Sign vrátí 429 Too Many Requests pro omezené požadavky, včetně podmíněných požadavků GET, které obsahují hlavičku If-None-Match.
  • Zásady dotazování jsou nastaveny na ENFORCED pro nové účty v prostředí Sandbox dne 11. února 2026.
  • Zásady dotazování jsou nastaveny na ENFORCED pro nové účty v produkčním prostředí dne 5. dubna 2026.

Pokud potřebujete pomoc nebo máte nějaké dotazy, kontaktujte prosím svého CSM.


Aktualizace rotace SSL/TLS certifikátů: probíhá přechod na kratší období platnosti certifikátů

První hlášení: březen 2026

Aktuální

Aktualizace rotace SSL/TLS certifikátů – přechod na kratší období platnosti

Odvětví SSL/TLS přechází na výrazně kratší období platnosti certifikátů.Tato změna je způsobena aktualizacemi od CA/Browser Forum (řídicího orgánu pro veřejně důvěryhodné certifikáty) a je přijímána napříč hlavními certifikačními autoritami (CA), včetně DigiCert. 

V důsledku toho se doba platnosti certifikátů postupně sníží ze současných ~398 dnů na pouhých 47 dnů během následujících několika let. 

Co se mění? 

Maximální doba platnosti veřejně důvěryhodných TLS certifikátů bude snížena na 47 dnů.Tento požadavek je definován CA/Browser Forum a platí v celém odvětví. 

Proč k této změně dochází? 

Kratší doba platnosti certifikátů zlepšuje bezpečnost tím, že:

  • Snížení doby vystavení riziku v případě kompromitace certifikátu nebo soukromého klíče
  • Omezuje závislost na mechanismech odvolání certifikátů
  • Podporuje automatizované řízení životního cyklu certifikátů
  • Zlepšuje celkový stav bezpečnosti internetu

Hlavní výrobci prohlížečů (Google, Apple, Mozilla, Microsoft) podporují tento přechod. 

Pro další kontext z odvětví viz oznámení DigiCert:
Doba platnosti TLS certifikátů se oficiálně sníží na 47 dnů

Jak se vás to týká

  • Zvýšená frekvence rotace certifikátů
    • Certifikáty se budou rotovat častěji, protože se snižují maximální období platnosti.  
  • Automatizace je vyžadována
    • Vzhledem ke kratším obdobím platnosti se očekává, že prodloužení certifikátů bude plně automatizované.Manuální procesy prodloužení nejsou při této frekvenci udržitelné. 

Pokud vaše prostředí závisí na připnutí certifikátů, manuálních úložištích důvěry nebo statických odkazech na certifikáty, zkontrolujte svou konfiguraci, aby byla zajištěna kompatibilita s častými prodlouženími. 

Oznámení zákazníkům

Dříve byla oznámení odesílána při každoroční rotaci certifikátů. 

S účinností od konce června 2026 budou rutinní oznámení o standardních rotacích certifikátů ukončena. 

S kratší dobou platnosti a automatickým prodloužením:

  • Rutinní rotace certifikátů nebudou generovat oznámení zákazníkům. 
  • Oznámení budou odesílána pouze v případě:
  • Selhání prodloužení
  • Dopad na službu
  • Požadovaná akce zákazníka

Tento přístup je v souladu s osvědčenými postupy v odvětví pro automatizovanou správu životního cyklu certifikátů. 

Není vyžadována žádná akce (pokud je povolena automatizace)

Pokud se vaše integrace spoléhá na standardní ověření platnosti TLS a nezávisí na připnutí certifikátu, není vyžadována žádná akce. 

Certifikáty se budou nadále automaticky prodlužovat před vypršením platnosti. 

Kdy může být vyžadována akce

Možná budete muset podniknout kroky, pokud:

  • Používáte připnutí certifikátu (SPKI nebo úplné připnutí certifikátu)
  • Spravujete manuální úložiště certifikátů
  • Máte pravidla firewallu vázaná na konkrétní otisky certifikátů
  • Provozujete systémy, které nepodporují automatické aktualizace certifikátů

Pokud si nejste jisti, poraďte se s týmem zabezpečení nebo infrastruktury. 

Časté dotazy 

  • Jedná se o změnu specifickou pro Adobe? 
    • Ne. Jedná se o změnu v celém odvětví nařízenou CA/Browser Forum a implementovanou všemi hlavními certifikačními autoritami. 
  • Bude ovlivněna dostupnost služby? 
    • Ne. Certifikáty se automaticky prodlouží před vypršením platnosti. V rámci normální rotace se neočekává žádný výpadek. 
  • Kdy se oznámení o rotaci certifikátů zastaví? 
    • Rutinní oznámení o rotaci certifikátů se zastaví na konci června 2026.Zákazníci budou nadále upozorněni pouze v případě, že je třeba jednat nebo pokud problém ovlivňuje službu. 
  • Kde se mohu dozvědět více? 

Potřebujete pomoc? 

Pokud máte dotazy týkající se rotace certifikátů nebo potřebujete pomoc s ověřením integrace, kontaktujte podporu Adobe nebo svého zástupce účtu Adobe.


Harmonogram zavádění moderního prostředí Request Signature

První hlášení: únor 2025 - aktualizováno červen 2026

Aktuální 

Ve verzi 17.2 (září 2026) budou všechny komerční a vládní účty aktualizovány, aby používaly moderní prostředí Request Signature.

  • Odkazy pro přepnutí budou vypnuty
  • Ovládací prvky správce v nabídce Správce zůstanou pro zákazníky, kteří se potřebují vrátit ke klasickému uživatelskému rozhraní.

Co se mění

Ve vydání ze září 2026 (17.2):

  • Všechny komerční a Govcloud účty budou automaticky přepnuty na moderní prostředí Request Signature.
  • Odkazy pro přepínání budou zakázány pro komerční i Govcloud účty
  • Ovládací prvky pro vrácení do klasického rozhraní zůstanou dostupné.

Ve verzi z ledna 2027 (18.0):

  • Všechny účty budou automaticky přepnuty na moderní prostředí Request Signature.
  • Odkazy pro přepínání budou odstraněny.
  • Ovládací prvky pro vrácení prostředí do klasického prostředí budou odstraněny z uživatelského rozhraní.

Doporučujeme seznámit vaše uživatele s moderním prostředím před vydáním, aby byl zajištěn hladký přechod.


Harmonogram zavádění moderního prostředí Create Template

První hlášení: únor 2025 - aktualizováno červen 2026

Aktuální 

Ve verzi 17.2 (září 2026) budou všechny komerční a vládní účty aktualizovány, aby používaly moderní prostředí Create Template.

  • Odkazy pro přepnutí budou zakázány
  • Ovládací prvky správce v nabídce Správce zůstanou pro zákazníky, kteří se potřebují vrátit ke klasickému uživatelskému rozhraní.

Co se mění

Ve vydání ze září 2026 (17.2):

  • Všechny komerční účty a účty Govcloud budou automaticky přepnuty na moderní prostředí Create Template.
  • Odkazy pro přepínání budou deaktivovány pro komerční účty i účty Govcloud
  • Ovládací prvky pro návrat k klasickému prostředí zůstanou k dispozici.

Ve vydání z ledna 2027 (18.0):

  • Všechny účty budou automaticky přepnuty na moderní prostředí Create Template.
  • Odkazy pro přepínání budou odstraněny.
  • Ovládací prvky pro návrat k klasickému prostředí budou odstraněny z uživatelského rozhraní.

Doporučujeme seznámit vaše uživatele s moderním prostředím před vydáním, aby byl zajištěn plynulý přechod.


Plán nasazení moderního návrháře vlastních pracovních postupů

První hlášení: duben 2025 – aktualizováno červen 2026

Aktuální 

Nové prostředí Workflow Designer je aktivováno pro všechny existující účty a postupně nahrazuje klasickou verzi. Během přechodného období mají správci a uživatelé určitou flexibilitu vrátit se k předchozímu rozhraní až do jeho úplného vyřazení.

Časový plán zavedení

září 2026 (v17.2)

  • Všechny účty jsou po vydání povýšeny na nové prostředí (pokud již nebyly).
  • Správci si zachovávají možnost návratu ke klasickému prostředí.
  • Uživatelé již nevidí přepínací odkazy; správci je mohou v případě potřeby povolit.

leden 2027 (v18.0)

  • Všechny účty jsou trvale převedeny na nové prostředí.
  • Ovládací prvky správce pro návrat ke klasické verzi jsou odstraněny.
  • Klasický Custom Workflow Designer je zcela vyřazen a již není přístupný.

Doporučujeme co nejdříve připravit uživatele, aby byl zajištěn hladký přechod.

Poznámka

Nové účty vytvořené po vydání aplikace acrobat sign v červenci 2025 budou mít ve výchozím nastavení povoleno nové prostředí a nebudou k dispozici žádné ovládací prvky pro návrat k předchozí verzi.


V lednu 2026 bude moderní prostředí pro příjemce pro elektronické podepisování povýšeno na výchozí prostředí pro všechny komerční účty a účty GovCloud (v17.0).

Poprvé nahlášeno: srpen 2025 – aktualizováno říjen 2025

Aktuální

Všechny účty přepnuty na moderní prostředí

Ve verzi 17.0 (leden 2026) budou všechny účty aktualizovány tak, aby používaly moderní prostředí pro elektronické podepisování

Poznámka

Ovládací prvky pro klasické prostředí zůstanou k dispozici jako záložní opatření pro případy použití, kdy nelze moderní prostředí použít.


Klasické reportování bude v roce 2027 odstraněno ze služby

První hlášení: září 2022 – aktualizováno červen 2026

Aktuální

Klasické reportování bude v roce 2027 zcela odstraněno z rozhraní Adobe Acrobat Sign.To zahrnuje i odkaz pro přepínání, který umožňuje přecházet mezi prostředími. Po odstranění se zákazníci nebudou moci vrátit do klasického prostředí a prohlížet si klasické přehledy a naplánované přehledy se přestanou generovat.

Moderní prostředí pro tvorbu přehledů zůstane jediným řešením pro tvorbu přehledů.

Všem zákazníkům důrazně doporučujeme, aby co nejdříve znovu vytvořili všechny své stávající přehledy v novém prostředí.

Trvalá informativní oznámení


Doručování SMS je blokováno v Thajsku

První hlášení: únor 2026

Aktuální

Shrnutí
Z důvodu aktualizovaných regulačních požadavků v Thajsku není doručování smluv prostřednictvím SMS v současné době podporováno pro příjemce s thajskými telefonními čísly.

Co se mění
Thajsko zavedlo aktualizované předpisy, které omezují SMS zprávy obsahující adresy URL směřující příjemce na toky vyžadující interakci uživatele. Protože podepsání smlouvy vyžaduje interakci příjemce, je doručování SMS pro tento případ použití omezeno.

Koho se to týká

  • Smlouvy odeslané pomocí doručování smluv prostřednictvím SMS.
  • Příjemci s thajskými telefonními čísly (+66).

Dopad
Příjemci s thajskými telefonními čísly nemusí obdržet SMS zprávy obsahující odkazy na smlouvy. V důsledku toho nemusí být příjemci schopni získat přístup k procesu podepisování a dokončit jej, pokud se používá doručování prostřednictvím SMS.

Toto omezení má regulační povahu a není způsobeno výpadkem služby nebo vadou produktu.

Časový rámec
V současné době neexistuje potvrzený časový plán, kdy by toto omezení mohlo být zrušeno nebo kdy bude použito technické řešení. Toto oznámení bude aktualizováno při změně podmínek.

Požadované akce

Další podrobnosti
Toto omezení se vztahuje pouze na doručování prostřednictvím SMS. Ostatní způsoby doručování a ověřování smluv nejsou ovlivněny.


Externí zdrojové jednotky budou odebrány z podpory v novém prostředí Požádat o podpis

První hlášení: květen 2024

Aktuální 

Možnost použít k odesílání souborů externí disk bude v novém prostředí pro žádosti o podpisy omezena pouze na OneDrive.

Doporučujeme zákazníkům, kteří používají jiné možnosti pro nahrávání souborů, aby použili aplikaci specifickou pro dodavatele k poskytnutí síťového disku, ke kterému lze přistupovat prostřednictvím nativního výběru souborů v lokálním systému uživatele.


Další zdroje

Archivovaná oznámení

Seřazeno podle data, kdy bylo oznámení odebráno ze seznamu aktuálních oznámení, od nejnovějšího po nejstarší.