1. Notes de distribution 5.3.1
Date de publication : 03/07/2019
1.1 Nouvelles fonctionnalités dans eSignatures 5.3.1
eSignatures 5.3.1 est une version hotfix (correctif logiciel) et ne contient pas de nouvelles fonctionnalités.
1.2 Problèmes résolus
Code Jira |
Code du problème |
Description |
CEP-6380 |
/ |
Les paires de clés DSS pour les types de signature sont désormais correctement chargées dans l'Index de configuration après la mise à niveau vers la version 5.2.x. |
CEP-6391 |
30582 |
Les mentions légales avec les balises s'affichent désormais correctement lors de l'utilisation de la signature BeID. |
CEP-6354 |
/ |
Les groupes de configuration dans les paramètres Themes de l'Index de configuration ont été réorganisés selon un ordre logique. |
CEP-6352 |
/ |
Les problèmes d'aperçu dans les paramètres Themes ont été résolus. |
CEP-6373 |
/ |
Lorsque des données iDIN incorrectes ont été entrées pour un contact, le signataire reçoit désormais un message indiquant qu'il n'est pas mandaté pour signer. |
CEP-6376 |
/ |
Le problème de statut des brouillons a été résolu. |
CEP-4177 |
/ |
Le problème de téléchargement dans le Portail Web a été résolu. |
CEP-6361 |
/ |
Le message d'erreur incorrect dans le navigateur iOS lors de l'utilisation d'une méthode de signature par carte à puce a été résolu. |
CEP-6395 |
/ |
Le problème lié à l'affichage de la marque/zoom sur iOS a été résolu. |
1.3 Problèmes connus
eSignatures 5.3.1
Code Jira |
Code du problème |
Description |
CEP-6396 |
/ |
Actuellement, les mentions légales ne sont pas affichées dans la signature lors de l'utilisation de la méthode de signature avec iDIN. |
CEP-6394 |
/ |
La signature rapide (QuickSign) avec BeID et une mention légale ainsi qu'un lecteur de carte avec clavier de saisie donne des résultats inattendus. |
eSignatures 5.3.0
Code Jira |
Code du problème |
Description |
CEP-5944 |
/ |
Le défilement itsme n'est pas aussi fluide que prévu dans Safari sur un iPhone. |
eSignatures 5.2.7
Code Jira |
Code du problème |
Description |
CEP-5982 |
30119 |
Problèmes de défilement/zoom de la page WYSIWYS sur les terminaux mobiles |
eSignatures 5.2.5
Code Jira |
Code du problème |
Description |
CEP-5676 |
/ |
Un package révoqué avec le statut « En cours » ne peut pas être supprimé. |
eSignatures 5.2.4
Code Jira |
Code du problème |
Description |
CEP-5564 |
/ |
Lorsqu'un package contient à la fois une méthode de signature synchrone et asynchrone, et que la signature asynchrone échoue, il est impossible de restaurer la session de signature. |
CEP-5605 |
/ |
Lors de la signature « en personne » avec iDIN et plusieurs signataires, seul le premier signataire est en mesure de signer. Lorsqu'il ne signe pas « en personne », un signataire peut uniquement signer le premier champ. |
eSignatures 5.2.0
Code Jira |
Code du problème |
Description |
CEP-5370 |
/ |
Lorsque vous attribuez au paramètre MandatedSigningType la valeur matchid pour la signature eID dans l'Index de configuration, il n'est pas possible pour le moment de charger les templates (modèles). |
CEP-4396 |
/ |
Personnalisation à la marque de votre société (« rebranding ») améliorée |
CEP-4817 |
/ |
Bogues d'affichage lors de l'utilisation de la signature complexe sur Safari et Chrome |
eSignatures 5.1.1
Code Jira |
Code du problème |
Description |
CEP-4719 |
/ |
Le délai d'expiration de la session est actuellement absolu. Les utilisateurs sont déconnectés même s'ils sont restés actifs. |
Problèmes connus plus anciens
Code Jira |
Code du problème |
Description |
CEP-3467 |
/ |
Le champ eID avec validation du nom+date de naissance et le champ BeLawyer (indépendamment de la validation) sont incompatibles. |
RFC-520 |
/ |
Lorsqu'un package contient plusieurs documents qui doivent chacun être signés par un utilisateur différent et que l'utilisateur A refuse les documents qui lui ont été attribués alors que l'utilisateur B accepte les siens, les détails du refus ne sont pas visibles au niveau du package, ni au niveau du document pour l'utilisateur qui a accepté les documents. Les détails du refus sont uniquement visibles au niveau du document pour l'utilisateur qui les a refusés. Ces détails seront fournis dans une version ultérieure d'eSignatures. |
/ |
/ |
L'installation allemande de Chrome peut générer des erreurs pendant la signature. |
1.4 Limitations connues
Général
- Un package ne peut pas excéder 150 Mo.
- Un seul document à l'intérieur d'un package ne peut pas excéder 30 Mo.
- Un package peut contenir un maximum de 15 documents.
- Un fichier .xml ne peut pas contenir plus de 2 millions de caractères par fichier. Un package ne peut pas contenir plus de 15 fichiers .xml.
- Les fichiers volumineux peuvent affecter les performances de signature selon la connexion Internet de l'utilisateur.
- Les documents qui font plus de 3,99 m sur 3,99 m ne sont pas pris en charge.
- Le chargement des documents PDF/A est uniquement autorisé si le format est PDF/A_2A ou PDF/A_1A.
- Lorsque vous chargez des documents PDF contenant déjà des champs de signature (créés dans une solution PDF telle qu'Adobe Acrobat Pro DC), assurez-vous que les noms des champs de signature contiennent uniquement des lettres et des nombres ou une combinaison des deux. Tous les caractères spéciaux, notamment les lettres accentuées, les points, les barres, etc. ne sont pas pris en charge et ne peuvent pas être utilisés. Les mêmes restrictions s'appliquent au chargement de documents PDF contenant des champs texte.
- L'ajout de plusieurs initiateurs dans un même package n'est pas pris en charge.
- L'application ne prend pas toujours en charge la combinaison des méthodes de signature eID et BeLawyer comme choix de signature : lorsque le paramètre MandatedSigningType a la valeur nameandbirthdate dans l'Index de configuration, ces deux méthodes ne peuvent pas être combinées.
- À l'heure actuelle, les packages ne peuvent pas contenir à la fois des documents XML et PDF sur lesquels des signatures seront apposées. Le type de package est déterminé par le premier document chargé.
- Les groupes par défaut « administrateurs » et « groupe d'utilisateurs par défaut » ne peuvent pas être utilisés comme signataires dans les templates (modèles).
- L'insertion d'une tabulation devant un marqueur texte dans Word n'est pas prise en charge. Aux tabulations préférez les tableaux, colonnes ou zones de texte. Si vous voulez néanmoins utiliser des tabulations, convertissez votre document Word au format PDF avant de le charger.
- Si vous utilisez Safari : après la mise à niveau d'une version antérieure, vous serez invité à fermer votre navigateur. Lorsque vous le rouvrez et que vos onglets précédents ne s'ouvrent pas automatiquement, ne réutilisez pas votre lien d'origine vers la page de signature. Sélectionnez plutôt History > Reopen All Windows From Last Session (Historique > Rouvrir toutes les fenêtres de la session précédente).
- Les applications de conception natives pour le DTP, CAO, etc. peuvent générer des documents très complexes (nombre important d'éléments, vecteurs, images, etc.) Il est dès lors possible que l'application ne puisse pas préparer le document dans un délai raisonnable. Il sera donc impossible d'ajouter ces fichiers à l'environnement de signature (via l'API ou le Portail de documents) en raison de l'expiration du délai imparti. Il n'est pas possible de savoir à l'avance si un document complexe va entraîner ou non une expiration dans la mesure où cela dépend d'un nombre trop important de facteurs. Les applications générant ces types de PDF disposent généralement d'une option pour créer un PDF adapté à une utilisation en ligne. Nous recommandons vivement d'utiliser cette option pour limiter la complexité du document avant son chargement.
Signature itsme
- Lorsque vous utilisez itsme comme méthode de signature, le type cible de vos documents doit être le format PDF/A-1 ou PDF/A-2. C'est à l'administrateur de vérifier que ces formats de sortie sont disponibles dans la solution eSignatures de l'utilisateur et c'est à l'utilisateur de sélectionner le format de sortie correct. Connective ne vérifie pas si le format de sortie correct a été sélectionné pour itsme.
- Lors de l'utilisation de la signature itsme dans des packages via le Portail Web, chaque document du package doit être signé individuellement.
- À l'heure actuelle, la signature itsme n'est pas prise en charge par un système macOS Mojave v10.14 exécutant Safari v12.0.
Preuves d'audit
- La fonction Audit Proof (Preuve d'audit) a une incidence importante sur la base de données eSignatures. Plus les documents sont volumineux, plus ils utiliseront d'espace. Cet impact est proportionnel à la taille des documents.
- La fonction Audit Proof (Preuve d'audit) a aussi un impact sur la vitesse de signature d'eSignatures. Plus les documents sont volumineux, plus il faudra de temps pour la signature. Les petits documents (< 1Mo) se semblent pas avoir d'impact sur la vitesse de signature.
Migration de la version v2 à v3 de l'API
Mode hérité (Legacy)
Si les clients ne sont pas en mesure d'effectuer la mise à niveau vers la version 3 de l'API parce qu'ils ne peuvent pas encore prendre en charge les URL ou les jetons d'accès à usage unique, ils peuvent utiliser le mode hérité (Legacy) en association avec la version 2 de l'API. Le mode hérité est une mesure temporaire qui prend en charge les « anciennes » URL et vous permet de terminer des documents inachevés. Sachez toutefois qu'il s'agit d'une fonctionnalité obsolète qui sera supprimée de la version 4 de l'API.
Les restrictions suivantes sont d'application :
- Lorsque le mode hérité est désactivé dans un environnement et que vous décidez de l'activer par la suite, les flux de l'API qui ont été créés alors que le mode hérité était désactivé ne fonctionneront plus.
- Lorsque le mode hérité est désactivé, les URL de téléchargement extraites de la version 2 de l'API ne peuvent être utilisées qu'une seule fois. Ces URL ne doivent pas être envoyées directement à l'utilisateur final dans un email puisqu'à la seconde ouverture de l'URL, l'utilisateur recevra un message d'erreur. Pour l'éviter, les clients peuvent prendre les mesures suivantes :
- Ils peuvent envoyer un e-mail avec une URL vers leur application de sorte que c'est l'application qui redirige vers l'URL de téléchargement la plus récente obtenue de la version API v2 juste avant la redirection.
- Ils peuvent ajouter « ?fromEmail=true » à l'URL extraite de la version API v2 afin que nous puissions afficher un écran d'erreur invitant l'utilisateur final à entrer son adresse email. Si cette adresse email correspond à un signataire ou un destinataire et que le package/document existe, celui-ci devrait recevoir un email de Connective avec une nouvelle URL opérationnelle.
Pour les clients signant avec des jetons physiques (eID, biométrique avec tablette de signature Wacom, etc.), le package Connective Browser Package doit être mis à niveau vers la version 2.0.6. La mise à niveau sera demandée automatiquement lorsque vous tenterez de signer un document.
Si vous disposez d'une version eSignatures antérieure à la version 5.3.1, consultez la documentation Connective - eSignatures 5.3.1 - Installation Documentation pour savoir comment effectuer une mise à niveau vers la version 5.3.1.