1. Notes de distribution 5.3.0
Date de publication : 21/06/2019
1.1 Nouvelles fonctionnalités dans eSignatures 5.3.0
Personnalisation du Portail Web eSignatures avec l'image de marque du client
Il est désormais possible de personnaliser l'apparence du Portail Web eSignatures avec l'image de marque du client.
Dans les versions précédentes d'eSignatures, il était déjà possible de personnaliser dans une certaine mesure la page WYSIWYS mais à présent chaque élément du Portail Web peut être personnalisé. En d'autres termes, vous pouvez utiliser une certaine image de marque sur le Portail de documents et une autre pour la page WYSIWYS.
Pour cela, vous devez créer des thèmes dans l'Index de configuration. C'est la raison pour laquelle nous avons créé un nouveau type d'utilisateur : Administrateur client. Les administrateurs client peuvent accéder au paramètre Theme de l'Index de configuration, sans pouvoir modifier les autres paramètres de configuration.
Vous pouvez appliquer une image de marque au niveau de l'environnement eSignatures– ce qui signifie qu'il sera identique pour tous les utilisateurs et signataires –, et vous pouvez aussi appliquer un thème différent par groupe de documents. Ainsi, tous les documents téléchargés dans un groupe de documents, par exemple Ventes, auront une page WYSIWYS personnalisée et les documents RH une autre. Il est même possible d'appliquer un thème spécifique au niveau du package : pour chaque package chargé par les initiateurs, ces derniers auront le choix entre différents thèmes à appliquer.
Pour des explications détaillées sur la personnalisation d'eSignatures avec l'image de marque, voir Connective - eSignatures 5.3.0 - Branding Documentation - Limited Public.
Important : pour que la fonction d'image de marque fonctionne bien, les administrateurs doivent utiliser l'outil de maintenance eSigner. Pour en savoir plus, voir Connective - eSignatures 5.3.0 - Installation Documentation d'installation - Limited Public.
Signature rapide (QuickSign) de packages contenant une mention légale
Dans eSignatures 5.3, vous pouvez désormais utiliser QuickSign pour signer rapidement un package, même s'il contient une mention légale. Notez toutefois que les mentions légales d'un package doivent être identiques par signataire. Il n'est pas possible d'utiliser la méthode QuickSign si le signataire doit indiquer un type de mention légale dans un document et un autre type dans un autre document du package.
Lorsque le paramètre IsQuickSignForLegalNoticeWithTagsEnabled sous Signing Options Settings est activé dans l'Index de configuration, les mentions légales peuvent même contenir un champ variable (entre balises) que les signataires doivent compléter manuellement. La valeur saisie entre les balises doit être identique par signataire pour que la méthode de signature rapide (QuickSign) fonctionne.
Dans les versions précédentes d'eSignatures, chaque champ de signature d'un package devait être signé individuellement dès que le package incluait une mention légale.
Conditions
La signature rapide est toutefois soumise à plusieurs conditions.
- Lorsque plusieurs méthodes de signature sont proposées au signataire, le même choix doit être proposé à ce signataire pour chaque document du package. Il est impossible d'avoir recours à la méthode QuickSign pour signer un package si le signataire peut choisir entre une paire de méthodes de signature sur un document et une autre paire sur un autre document.
- Les deux méthodes de signature suivantes ne peuvent pas être combinées avec la méthode QuickSign : signature manuscrite+eID et biométrique. Si l'une de ces méthodes a été sélectionnée pour vous, chaque champ du package doit être signé individuellement.
- La signature eID exige un lecteur de cartes transparent, par ex. un lecteur de cartes sans clavier de saisie de code PIN. Si le signataire utilise un lecteur de carte eID avec clavier de saisie, il sera invité à signer chaque champ individuellement.
- Lorsque le package contient des mentions légales, leur contenu doit être identique par signataire, comme indiqué ci-dessus.
Téléchargement de documents non signés à partir de la page WYSIWYS
Vous pouvez désormais télécharger des documents non signés à partir de la page WYSIWYS. De cette façon, vous pouvez les ouvrir dans un visualiseur PDF pour les lire plus facilement ou, le cas échéant, les imprimer et les lire en version papier avant de les signer.
L'icône de téléchargement est disponible ou non dans la page WYSIWYS selon que l'option correspondante a été activée dans l'Index de configuration et que l'initiateur active ou non l'option pendant le chargement du document.
Utilisation des langues de prédilection dans eSignatures
Les administrateurs pouvaient déjà configurer la langue par défaut de l'environnement dans les versions précédentes d'eSignatures.
Dans eSignatures 5.3, les administrateurs peuvent toujours sélectionner une langue par défaut au niveau de l'environnement mais, lorsqu'ils créent un nouvel utilisateur, ils peuvent sélectionner une langue de prédilection différente de celle de l'environnement pour cet utilisateur. C'est également valable pour les utilisateurs qui créent un compte eSignatures.
La langue de prédilection est utilisée dans toute l'application eSignatures :
- L'e-mail que l'utilisateur reçoit pour activer son compte sera rédigé dans la langue de prédilection.
- Lorsque l'utilisateur crée un nouveau contact, la langue par défaut est identique à celle de l'utilisateur.
- Lorsque l'utilisateur charge un package, la même langue de prédilection est utilisée.
- Les e-mails que les signataires reçoivent sont rédigés dans la langue de prédilection.
Notez toutefois que la langue de prédilection peut toujours être modifiée au niveau du contact et du package.
Notez aussi que, lorsqu'un utilisateur crée un nouvel utilisateur dans la section Gestion des utilisateurs et qu'un utilisateur crée un compte eSignatures, la langue par défaut de ce nouvel utilisateur est celle configurée au niveau de l'environnement.
Identifiants uniques pour la signature mandatée
Si vous souhaitez qu'un contact puisse utiliser eID ou BeLawyer pour la signature mandatée conformément au paramètre « matchid » défini, vous devez ajouter un identifiant unique pour les types de signature susmentionnées lors de la création du contact.
L'identifiant unique permet de déterminer qui est mandaté pour signer au cours d'une session donnée, sur la base des éléments suivants :
- Numéro de Registre National pour la signature eID
- Id d'avocat pour la signature BeLawyer
Notez que c'est l'administrateur qui doit définir le paramètre MandatedSignerType avec la valeur matchid dans l'Index de configuration pour que ce type de signature mandatée fonctionne.
Signature mandatée combinée avec iDIN
La signature mandatée basée sur le nom et la date de naissance peut désormais être utilisée avec la signature iDIN.
Informations supplémentaires dans la fenêtre de sélection de la méthode de signature
Dans la fenêtre de sélection de la méthode de signature, les utilisateurs peuvent désormais voir les types de signature qui ne sont pas configurés correctement ou qui sont incomplets et par conséquent non disponibles. Une info-bulle explique les éléments manquants lorsque vous passez avec le curseur sur le type de signature. Par exemple, l'option Code SMS n'est pas disponible si les données du contact n'incluent pas son numéro de téléphone. La signature mandatée avec BeLawyer n'est pas disponible si les données du contact n'incluent pas une date de naissance ou un identifiant unique.
Dans les versions précédentes d'eSignatures, un type de signature qui n'était pas configuré correctement ne s'affichait pas dans la fenêtre de sélection de la méthode de signature.
Informations supplémentaires dans le Portail de document : méthodes de signature disponibles et méthode de signature utilisée
Lorsqu'ils vérifient les détails d'un document dans le Portail de documents, les initiateurs peuvent désormais voir les méthodes de signature proposées aux signataires et la méthode de signature utilisée par ceux-ci.
Les méthodes de signature que le signataire peut utiliser sont affichées en gris. La méthode de signature utilisée par le signataire est affichée en vert.
Informations supplémentaires dans l'appel Get Package Status : Type de signature utilisé
Comme dans le Portail Web, les utilisateurs de l'API peuvent désormais voir le type de signature choisi par un signataire. À cette fin, un paramètre de réponse supplémentaire a été ajouté dans l'appel Get Package Status : SignatureTypeUsed. Si aucun type de signature n'a été utilisé (par ex. si le document n'a pas encore été signé), ce paramètre renvoie la valeur « null ».
Nouvel appel d'API : Get Package Identity
Les utilisateurs de l'API peuvent désormais récupérer les données d'identité de tous les acteurs iDIN d'un package complètement signé et de ses documents. Ces données d'identité sont renvoyées par le service iDIN lui-même et récupérées via l'API eSignatures.
Notez toutefois qu'il n'est pas possible de récupérer des données d'identité tant que le package n'a pas le statut FullySigned.
Nouvel appel d'API : Get Themes
Les utilisateurs de l'API peuvent désormais récupérer la liste de thèmes créés dans l'Index de configuration, ainsi que les codes des thèmes.
Le code du thème peut être indiqué comme paramètre de demande (Request) lors de la création des packages et des packages instantanés. Le thème demandé sera alors appliqué aux packages en question.
Activation distincte des comptes Cloud
eSignatures prenait déjà en charge le chargement de documents depuis Dropbox, Google Drive et OneDrive. Dans eSignatures 5.3, les administrateurs peuvent désormais choisir quel compte Cloud activer. Chaque compte Cloud peut être activé ou désactivé séparément par environnement.
Notez que cette fonction est prise en charge au niveau de l'environnement. Pour l'heure, elle n'est pas prise en charge au niveau utilisateur.
Activation distincte des conditions d'utilisation, de la politique de confidentialité et de la politique de cookies.
Les administrateurs peuvent désormais choisir la politique qu'ils souhaitent activer ou désactiver. Les conditions d'utilisation, la politique de confidentialité et la politique de cookies peuvent toutes être activées ou désactivées séparément par environnement. Dans les versions précédentes d'eSignatures, les trois devaient être activées ou désactivées ensemble.
1.2 Améliorations
Traitement optimisé des documents
Le traitement des documents a été optimisé à différents égards.
Pré-rendu asynchrone
Les documents sont désormais pré-rendus de façon asynchrone. Au moment où l'utilisateur peut signer le package, le rendu est déjà effectué, ce qui accélère la signature puisque l'utilisateur ne doit plus attendre que le document soit chargé. Un autre avantage est que le rendu du document n'est effectué qu'une seule fois : une fois le document rendu pour le premier signataire, il ne doit plus l'être pour les autres.
Pas de pré-rendu pour la signature via serveur
Pour la signature de packages via serveur, aucun rendu n'est effectué puisqu'aucune action utilisateur n'est requise.
Files d'attente multiples dans REST Worker
Les différents processus Worker sont désormais exécutés par une file d'attente désignée, au lieu d'une seule file d'attente. Par exemple, CommandQueue effectue la signature, CommandQueue2 le pré-rendu et CommandQueue3 le changement de statut. Comme les tâches sont désormais effectuées selon le principe PEPS (premier entré, premier sorti), les utilisateurs ne doivent plus attendre que tous les processus soient terminés pour voir le changement de statut.
Notez que les administrateurs peuvent, au besoin, ajouter d'autres CommandQueues. Notez aussi que chaque CommandQueue possède sa propre file d'attente. Attention : l'appel Clear Poison Queue supprime toutes les files d'attente. Pour l'heure, la suppression d'une ou plusieurs files spécifiques n'est pas prise en charge.
Les fichiers Audit Proof ne sont plus stockés dans la base de données
Dans les précédentes versions d'eSignatures, la fonction Audit Proof (Preuve d'audit) avait une incidence importante sur la base de données eSignatures. À partir d'eSignatures 5.3, les fichiers Audit Proof sont stockés sur le lecteur de stockage du serveur qui héberge les données. Cela contribue à réduire la charge sur la base de données mais cela augmente évidemment celle imposée au lecteur de stockage.
Les preuves d'audit sont supprimées du lecteur de stockage dès que le package correspondant a été supprimé via l'appel d'API ou le Portail Web.
Les traductions par défaut ne sont plus stockées dans la base de données
Les messages par défaut du système principal et leurs traductions – utilisées dans les textes de signatures, les emails, etc. – ne sont plus stockés dans la table Translation de la base de données mais gérés par l'application eSignatures elle-même.
Si les clients souhaitent utiliser des messages personnalisés et non par défaut, ils peuvent les indiquer ans la table Translation, ce qui remplacera les traductions par défaut.
Attention : les clients sur site qui utilisaient déjà des messages personnalisés doivent sauvegarder leur table Translation existante (puisque la table Translation d'eSignatures 5.3 sera vide) et la réexécuter après la mise à niveau. Pour en savoir plus, voir Connective - eSignatures 5.3.0 - Installation Documentation.
Les vignettes ne sont plus stockées dans la base de données
Les vignettes que vous voyez lorsque vous parcourez les documents d'un package ne sont plus stockées dans la base de données mais dans le compte de stockage pour des raisons de performances.
Attention : en cas de mise à niveau depuis une version précédente d'eSignatures, les administrateurs doivent exécuter l'outil de maintenance eSigner pour avoir un rendu correct des vignettes dans eSignatures 5.3. Pour en savoir plus, voir Connective - eSignatures 5.3.0 - Installation Documentation - Limited Public.
Transfert amélioré vers la couche d'intégration itsme
Lors de l'envoi de packages et documents vers la couche d'intégration itsme avant de signer, le champ Description itsme contient désormais le nom du document si le package ne comprend qu'un seul document, et le nom du package si ce dernier comprend plusieurs documents.
Dans les versions précédentes d'eSignatures, le champ Description comprenait les valeurs que l'administrateur eSignatures avait configuré comme champs texte libre dans l'Index de configuration.
Appel Instant Package amélioré
Lors d'un appel Instant Package Creation alors que la fonction Audit Proof est activée, l'ID d'emplacement (obligatoire pour un appel Post extra proof) est désormais renvoyé par défaut. De cette façon, il n'est plus nécessaire d'utiliser l'appel Get Signing Locations pour obtenir l'ID d'emplacement des packages instantanés.
1.3 Problèmes résolus
Code Jira | Code du problème | Description |
---|---|---|
CEP-5612 | / | Les traductions OpenID Connect ne se chargent pas correctement . |
CEP-5972 | / | La migration des thèmes créés dans des versions antérieures d'eSignatures ne fonctionne pas correctement. |
CEP-5578 | / | Le logo Connective apparaît parfois lors du chargement de la page WYSIWYS même s'il a été modifié. |
CEP-5370 | / | L'utilisation de templates avec la signature mandatée basée sur matchid n'est pas prise en charge actuellement. |
CEP-6140 | / | Les administrateurs client n'avaient les autorisations appropriées pour modifier les thèmes dans l'Index de configuration. |
CEP-6116 | / | L'appel Get Package Identity pour récupérer les données iDIN fonctionne désormais correctement. |
CEP-6112 | / | La valeur par défaut : du paramètre CombineLegalNoticeAndSigningPolicy dans l'Index de configuration est correctement défini avec la valeur True. |
CEP-6111 | / | Le problème de signature iDIN avec la signature mandatée désactivée dans l'Index de configuration a été résolu. |
CEP-6110 | / | Le nom du paramètre d'API DownloadUnsignedFile a été remplacé par le nom correct : DownloadUnsignedFiles. |
CEP-6103 | / | La réutilisation de l'URL de téléchargement après le téléchargement d'un package non signé à partir de la page WSIWYS fonctionne désormais comme prévu. |
CEP-6102 | / | Lors du téléchargement d'un document non signé à partir de la page WYWISY, le document est correctement téléchargé et vous êtes aussi bien redirigé. |
CEP-6100 | / | Le problème lié au bouton de téléchargement des documents non signés a été résolu. |
CEP-6098 | / | Le problème de chargement « Document corrompu » a été résolu. |
CEP-6097 | / | La création de paires de clés dans l'Index de configuration ne fonctionnait pas. |
CEP-6096 | / | L'erreur CookiePolicy qui empêchait l'installation correcte d'eSignatures 5.3 Build: 5.3.19136.01 a été résolue. |
CEP-6094 | / | La modification des traductions dans la base de données ne fonctionnait plus. |
CEP-6015 | / | Les contacts créés dans une version eSignatures bien antérieure ne peuvent pas signer par code SMS même si leur numéro de téléphone est correctement renseigné. En effet, le champ PhoneNumberCountry n'existait pas dans les versions antérieures et n'est donc pas complété pour ces contacts. |
CEP-5980 | / | La fenêtre de signature ne se chargeait pas toujours correctement . |
CEP-5979 | / | Lors de l'utilisation d'un DSS sans paramètre tenantId, l'onglet DSS dans l'Index de configuration ne se chargeait pas correctement. |
CEP-5961 | / | La création d'un contact pendant le flux de chargement ne crée plus plusieurs signataires au lieu d'un seul lorsque ce dernier doit signer plusieurs champs. |
CEP-5960 | / | Le changement de réponse pour la signature via serveur par rapport à l'API v2 a désormais été implémenté. |
CEP-5959 | / | L'URL de téléchargement d'un appel Package Status de l'API v2 renvoie désormais le nom .zip correct. |
CEP-5952 | / | Les problèmes de création d'utilisateurs dans la section Gestion des utilisateurs ont été résolus. |
CEP-5950 | / | La signature iDIN ne fonctionnait plus. |
CEP-5939 | / | Le problème de chargement de DSS TrustStoreAlias a été résolu. |
CEP-5916 | / | Le message d'erreur incorrect lorsque vous sélectionniez eID et BeLawyer avec le paramètre MandatedSignerType défini sur matchid a été résolu. |
CEP-5913 | / | Les détails du package s'affichent désormais correctement dans le groupe de documents. |
CEP-5912 | / | L'erreur de signature « en personne » a été résolue. |
CEP-5909 | / | Lors de la signature rapide (QuickSign) d'un package contenant une mention légale et plus de deux champs de signatures avec eID, l'appel de blocage est désormais correctement déclenché avant que vous ne commenciez à le compléter. |
CEP-5905 | / | Le paramètre SigningTypeUsed dans l'appel Get Status Call renvoie désormais tous les types de signatures utilisés pour un acteur. |
CEP-5807 | / | La signature XML contient le mauvais type de média MIME. |
CEP-5700 | / | Lorsque vous signez avec ManualBeid et utilisez l'appel Get Status, le paramètre « SigningTypeUsed » renvoie « ManualDigital » au lieu de « ManualBeid ». |
CEP-5698 | / | La table DocumentSigners avec l'erreur du type d'erreur nvarchar(MAX) a été résolue. |
CEP-5685 | / | L'ajout d'un nouveau contact dans l'écran de résumé ferme désormais correctement la fenêtre de création de contact (Firefox). |
CEP-5680 | / | L'appel Get Package Status ne renvoyait pas l'horodatage correct |
CEP-5678 | Lors de la signature avec iDIN, le numéro de la transaction est désormais présent dans la signature. | |
CEP-5656 | / | La désinstallation de REST Worker était impossible sans redémarrage du serveur. |
CEP-5603 | / | Les très longs noms de signatures ne sont plus hors limites. |
CEP-5656 | / | La désinstallation de REST Worker était impossible sans redémarrage du serveur. |
CEP-5603 | / | Les très longs noms de signatures ne sont plus hors limites. |
CEP-5596 | / | La signature d'un document après la mise à niveau ne génère plus d'erreurs dans les journaux Worker. |
CEP-5591 | / | Le problème lié à la sélection du signataire lors du refus de la méthode « en personne » a été résolu. |
CEP-5400 | / | Le problème lié à la signature asynchrone où vous pouviez toujours refuser un document après l'avoir signé et fermé la fenêtre a été résolu. |
CEP-5399 | / | Le problème lié au nommage du package pendant le chargement a été résolu. |
CEP-5398 | / | Le problème de placement des champs de signature et de la sélection de la méthode de signature avec iDIN été résolu. |
CEP-5373 | / | Le problème de l'écran tactile a été résolu. |
CEP-5275 | 29067 | L'erreur de notification a été résolue. |
CEP-4765 | / | Lors d'une signature complexe avec itsme, une erreur de mention légale s'affichait même si aucune mention légale n'était utilisée. |
CEP-4977 | / | Lors du téléchargement de PDF dans Safari sur MacOS, les PDF avaient une extension .dms au lieu de .pdf |
1.4 Problèmes connus
eSignatures 5.3.0
Code Jira | Code du problème | Description |
---|---|---|
CEP-5972 | / | La migration des thèmes créés dans des versions antérieures d'eSignatures ne fonctionne pas correctement. |
CEP-5944 | / | Le défilement itsme n'est pas aussi fluide que prévu dans Safari sur un iPhone. |
CEP-5612 | / | Les traductions OpenID Connect ne se chargent pas correctement . |
CEP-5578 | / | Le logo Connective apparaît parfois lors du chargement de la page WYSIWYS même s'il a été modifié. |
CEP-5370 | / | L'utilisation de templates avec la signature mandatée basée sur matchid n'est pas prise en charge actuellement. |
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.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.
- 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 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.0, consultez la documentation Connective - eSignatures 5.3.0 - Installation Documentation pour savoir comment effectuer une mise à niveau vers la version 5.3.0.