1. Notes de distribution 5.4.2
Date de distribution: 29-10-2019
1.1 Nouvelles fonctionnalités d’eSignatures 5.4.2
Groupes de contacts
Il est désormais possible de rassembler des contacts pour constituer des groupes de contacts (contact groups) qui peuvent être ajoutés à un champ de signature comme de simples contacts individuels. Tout contact appartenant au groupe de contacts peut alors signer dans le champ de signature. Peu importe l’identité du contact qui signe le document ; il suffit qu’il soit membre du groupe. Sachez toutefois que dès qu’un membre du groupe a signé le document, les autres ne peuvent plus le faire. Lorsqu’un document a été signé par un membre de groupe de contacts, tous les autres membres reçoivent une notification.
Partage de contacts et de groupes de contacts
Les contacts et les groupes de contacts peuvent désormais être partagés entre utilisateurs. Vous pouvez ainsi, lorsque vous créez un nouvel utilisateur dans eSignatures, lui fournir immédiatement tous les contacts requis.
Dans les versions précédentes, le nouvel utilisateur devait toujours créer sa liste de contacts manuellement.
Création automatique de contact lors de l’auto-enregistrement
Lorsqu’un utilisateur crée un compte eSignatures, un contact correspondant est désormais automatiquement créé.
Les utilisateurs ne sont donc plus obligés de créer leur propre contact manuellement. La seule chose qu’il leur reste à faire, c’est d’indiquer le numéro de téléphone du contact (s’ils veulent signer avec SMS OTP) et un identifiant unique (s’ils veulent utiliser la validation de signataire mandaté en combinaison avec la signature eID ou BeLawyer).
Différents types de parties prenantes dans l’API
Pour refléter la fonctionnalité de groupes de contacts dans l’API, trois types de parties prenantes ont été introduites ; elles peuvent être transmises dans les appels Set Process Information (v3.1) et Instant Package Creation. Les parties prenantes peuvent être des personnes (par défaut), des groupes de personnes ou des groupes de contacts. En cas d’utilisation d’un groupe de personnes ou d’un groupe de contacts, une seule personne pourra signer le package pour l’ensemble du groupe.
Nouvel appel d’API : Get ContactGroups
Cet appel permet aux utilisateurs de l’API d’obtenir la liste des groupes de contacts actuellement utilisés sur le portail Web eSignatures, ainsi que leur code correspondant.
Le code ContactGroup peut être saisi comme paramètre Request lors de la réalisation d’un appel Set Process Information (v3.1) ou Instant Package Creation. Tout membre du groupe de contacts demandé pourra signer le package pour l’ensemble du groupe.
Profils de signature OpenID Connect multiples
Les administrateurs peuvent désormais configurer plusieurs profils de signature OpenID Connect dans l’Index de configuration. Cela permet d’offrir plusieurs types de signatures personnalisées dans eSignatures.
Centre de notification
Le centre de notification (Notification Hub) permettra à eSignatures d’utiliser de manière flexible des fournisseurs de SMS et de courrier électronique de tierce partie.
Important : cette fonctionnalité est destinée à un usage ultérieur et ne doit pas être activée ni configurée dans eSignatures 5.4.2, même si elle est disponible dans l’Index de configuration.
1.2 Problèmes résolus
Jira code | Issue code | Description |
---|---|---|
CEP-5494 | 29381 | Login fields were not filled automatically when using password managers. |
CEP-6739 | 31497 | Adding phonenumber to receiver issue has been fixed. |
CEP-6731 | eSignatures could not connect to SMTP server with NTLM and GSSAPI auth methods | |
CEP-6751 | / | iDIN is still available as signing method even though mandated signing based on nameandbirthdate is enabled and the contact’s info doesn’t contain a birthdate. |
CEP-6795 | / | Correction in API documentation |
CEP-6738 | Contacts could not be edited in signing field creation modal. | |
CEP-6323 | / | XML signing issue has been fixed. |
CEP-6398 | / | Changes to the “Unselected colour” setting in Theme > Portal > After login > Big tabs > Background can’t be saved. |
CEP-6515 | / | WYSIWYS message error has been fixed. |
CEP-6674 | / | Favicon issue in Theming has been fixed. |
CEP-6722 | / | Error message color issue in Theming has been fixed. |
CEP-6743 | / | Document group theming issue has been fixed. |
CEP-6749 | / | OIDC signing error message has been added to the log when response info is not in the configured format (JWT or json) |
CEP-6750 | / | Default document theme issue when using API v2 has been fixed. |
CEP-6753 | / | Issue when creating a contact that contains a phone number during the addition of a receiver has been fixed. |
CEP-6768 | / | Disabling legal notice issue has been fixed. |
CEP-6783 | / | EmailOTP case sensitive issue has been fixed: EmailOTP is no longer case sensitive. |
CEP-6789 | / | Input field text wasn’t themable. |
CEP-6744 | / | Multiple OpenID Connect profiles could not be loaded in clean install. |
CEP-6808 | / | Preselecting signing methods issue has been fixed. |
CEP-6809 | / | Error messages have been improved. |
CEP-6813 | / | Correct error message is now returned when creating a draft document with invalid document group in API v2. |
CEP-6816 | / | Matchid issue when adding a signer without unique identifier has been fixed. |
CEP-6820 | / | Specific signing order issue with EmailOTP and SMSOTP has been fixed. |
CEP-6824 | / | Preview issue with checkboxes/marks in Theming has been fixed. |
CEP-6823 | / | OpenID Connect upgrade issue has been fixed |
CEP-6816 | / | While matchid is enabled it is possible to add a signer that does not have a unique identifier. |
CEP-6844 | / | Unique identifier issue has been fixed. |
CEP-6767 | / | OpenID Connect profile that was only linked to a package in final state could not be deleted. |
CEP-6766 | / | OpenID Connect profiles are now sorted alphabetically. |
CEP-6764 | / | OpenID Connect settings visibility issue has been fixed. |
CEP-6763, CEP-6762 | / | OpenID profile creation issue has been fixed. |
CEP-6726 | Some special characters were not displayed in Config Index. | |
CEP-6542 | Mouse over functionality over Big tabs has been removed. | |
CEP-6519 | Download unsigned doc issue on iOS has been fixed. | |
CEP-6452 | / | ‘ |
CEP-6095 | / | Package title field is now required. |
1.3 Problèmes connus
eSignatures 5.4.2
Jira code | Issue code | Description |
---|---|---|
CEP-6870 | / | Configuration layout of OIDC field should be improved. |
CEP-6874 | / | Inconsistent casing of query parameter “SessionId” in case of invalidToken. |
CEP-6883 | / | PersonGroup signer is not displayed in package summary. |
CEP-6884 | / | Wrong PersonGroup icon is displayed in signing field. |
CEP-6288 | / | Branding issue: saving a change in one of the subtabs navigates to 1 tab above. |
CEP-6736 | / | Google Drive issue during upload. |
CEP-6838 | / | Some extensions are mentioned twice in the custom files list when selecting a favicon in Theming. |
CEP-6854 | / | Signing method is not visible in draft package in combination with OIDC. |
CEP-6859 | / | Contact groups/Person groups WYSIWYS svgs not found when using azurefilestorage. |
CEP-6865 | / | When upgrading from 5.0.7 the Environment settings page prompts to save without having made a change. |
CEP-6878 | / | Personal contacts are missing during creation of contact group. |
eSignatures 5.4.1
Jira code | Issue code | Description |
---|---|---|
CEP-6651 | / | QuickSigning with multiple signing fields leads to deadlock while package is ending |
eSignatures 5.4.0
Jira code | Issue code | Description |
---|---|---|
CEP-6651 | / | QuickSigning multiple fields in a single document while the end document flow has been initialized currently causes Deadlock logs. |
CEP-6589 | / | When the status of a document is “Ending” it’s currently not possible to view its details. |
eSignatures 5.3.0
Jira code | Issue code | Description |
---|---|---|
CEP-5944 | / | Itsme scrolling is not as smooth as expected on Safari on iPhone. |
eSignatures 5.2.4
Jira code | Issue code | Description |
---|---|---|
CEP-5564 | / | When a package contains both an asynchronous and synchronous signing method, and the asynchronous signing fails, the signing session cannot be recovered. |
eSignatures 5.2.0
Jira code | Issue code | Description |
---|---|---|
CEP-4817 | / | Display bugs when using complex signing on Safari and Chrome |
eSignatures 5.1.1
Jira code | Issue code | Description |
---|---|---|
CEP-4719 | / | The timeout of the session is currently absolute. Users are logged out even if they have been active. |
Older known issues
Jira code | Issue code | Description |
---|---|---|
/ | / | German installation of Chrome can generate errors during signing. |
1.5 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.
- Uploading PDF portfolios is not supported.
- 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.
2. Informations de mise à niveau
Pour les clients qui signent avec des jetons physiques (eID, méthode 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 lors de la tentative de signature d’un document.
Si vous disposez d’une version d’eSignatures installée avant la version 5.4.2, référez-vous à la documentation d’installation Connective – eSignatures 5.4.2 – Installation Documentation pour apprendre comment effectuer une mise à niveau vers la version 5.4.