Version 23.R1 (11.50)

Quoi de neuf

OneSpan Notary (notarisation en ligne à distance)

• Présentation de OneSpan Notary : OneSpan Notary permet à la fois les notarisations en ligne à distance (RON) et les notarisations en personne. La fonctionnalité RON permet à un notaire et aux signataires de se joindre à une session notariale en ligne à distance dans laquelle le notaire : (1) agit en tant qu’hôte de la session ; (2) permet aux utilisateurs de signer des documents ; (3) confirme les documents signés avec un sceau notarié numérique.

• Cette fonctionnalité RON introduit les nouvelles fonctionnalités suivantes : (1) Commission notariale ; (2) Revue électronique ; (3) un type de transaction appelé notarisation en ligne à distance.

  Du point de vue de OneSpan Sign, un « notaire » est un expéditeur qui s’est vu accorder des « droits de notaire », ou qui s’est vu attribuer le rôle de notaire.

  Une fois qu’un expéditeur est notaire en ce sens, il doit configurer une « Commission notariale » en : (1) cliquant sur Mon compte > Commission notariale ; (2) Fournir des informations sur les commissions dans la boîte de dialogue qui s’affiche.

  Lorsqu’un expéditeur crée une transaction notariale en ligne à distance, il doit spécifier : (1) un notaire valide pour la transaction ; (2) la date et l’heure de la séance de signature de la transaction.

  Une fois que le notaire est entré dans une session notariale en ligne à distance, il doit confirmer l’identité de chaque signataire. Pour cette première version, la seule méthode d’authentification prise en charge est que le notaire connaît personnellement le signataire.

  Une séance de notaire en ligne à distance suit les mêmes règles qu’une session de salle virtuelle.

  Une fois que tous les documents ont été signés par les signataires et le notaire, celui-ci peut mettre fin à la session de notarisation à distance. Le notaire sera alors redirigé vers unjournal électronique. Il s’agit d’un registre électronique dans lequel le notaire doit consigner des informations relatives à sa notarisation. Le journal peut être téléchargé à partir du lien Mon compte > Journal dans la partie Expéditeur de la nouvelle expérience utilisateur.

  Pour cette version initiale, seules les juridictions notariales suivantes sont prises en charge : (1) Alaska ; (2) l’Arizona ; (3) Hawaï ; (4) Minnesota ; (5) l’Ohio ; (6) l’Oklahoma ; (7) Tennessee ; (8) le Texas ; (9) Virginie ; (10) État de Washington.

  Pour activer OneSpan Notary, veuillez contacter notre équipe des ventes.

Changement de marque

• OneSpan Sign rebaptisé avec de nouvelles couleurs et un nouveau logo : Nous avons mis à jour : (1) le logo et les couleurs du document de consentement électronique ; (2) le logo de signature en filigrane ; (3) le logo dans le résumé des preuves ; (4) les couleurs des modèles d’e-mails.

Expéditeurs

• Ajout de descriptions de transaction aux noms de transaction : dans la partie Expéditeur de la nouvelle expérience utilisateur, les descriptions de transaction apparaissent désormais dans toute liste ou table contenant des noms de transaction. Ces descriptions apparaissent directement sous les noms, mais utilisent une police plus petite. Cela permettra aux expéditeurs de différencier les transactions qui portent le même nom.

• Un document peut être signé par certains, et accepté par d’autres : Auparavant, les expéditeurs ne pouvaient attribuer qu’un seul des états suivants au document d’une transaction : (1) Signable ; (2) Acceptation seulement. L’état attribué s’appliquait à tous les destinataires de la transaction. Les expéditeurs ont désormais la possibilité d’attribuer un autre état à un document. Le nouvel État exige qu’un document soit : (1) signé par certains destinataires ; (2) accepté par d’autres destinataires. Remarque : Le propriétaire de la transaction (alias « moi-même ») ne peut pas accepter de documents.

• Peut repositionner plusieurs champs à la fois : Auparavant, la sélection multiple de champs dans le concepteur ne pouvait être utilisée que pour aligner les champs. Désormais, cette fonctionnalité de sélection multiple peut également être utilisée pour repositionner plusieurs champs à la fois dans le même document. Cela permettra de créer certaines transactions plus rapidement.

• La vérification d’identité prend en charge la même adresse e-mail : une transaction qui utilise la vérification d’identité peut désormais accueillir des signataires qui ont la même adresse e-mail.

Développeurs

• Ajout de l’ID de document et de l’ID de destinataire à l’API d’audit : l’ID de document et l’ID de destinataire sont désormais dans le JSON renvoyé par l’appel api/packages/<packageId>/audit. Ces informations permettront aux développeurs de : (1) différencier les documents qui portent le même nom ; (2) différencier les destinataires qui portent le même nom. Remarque : L’ID du destinataire n’est pas suivi pour les événements de vérification de l’ID.

Bogue

Authentification de l’utilisateur

• PB-87150 : Correction d’un problème concernant les tentatives d’authentification répétées via la configuration de la vérification d’identité appelée Vérification de documents uniquement. Le système n’aurait dû autoriser que trois tentatives infructueuses, mais il en a autorisé quatre.

• PB-87989 : Correction du problème suivant. Si un utilisateur utilisait un jeton d’authentification du signataire pour accéder à l’expérience du signataire, le système ne parvenait pas à afficher son message personnalisé pour accès non autorisé à l’OFAC .

Expérience du signataire

• PB-90661 : Correction d’un problème dans lequel un signataire qui venait de terminer toutes ses actions sur une transaction se voyait présenter le message trompeur : Actuellement, ce n’est pas à votre tour de signer.

• PB-89223 : Correction d’un problème qui survenait dans le volet gauche de l’expérience du signataire. Le problème était que le mot DOCUMENTS chevauchait le nombre de documents, et le mot UPLOADS chevauchait le nombre de téléchargements.

• PB-87913 : Correction d’un problème dans lequel le volet gauche de l’expérience du signataire affichait le statut d’un document comme Signature terminée, bien que le document nécessitait toujours des actions.

• PB-91298 : Correction d’une condition de concurrence rare qui faisait que le texte saisi par un signataire dans un champ de zone de texte n’apparaissait pas dans le document après que le signataire : (1) ait signé le document ; (2) rouvrir le document.

• PB-91711 : Correction d’un problème qui empêchait le remplissage de certains champs automatiques si plusieurs signataires avaient un champ automatique portant le même nom.

Expéditeurs

• PB-85790 : Correction d’un problème dans lequel un expéditeur ouvrait une transaction expirée à partir de l’onglet Brouillons , puis la renvoyait. Le problème était que le système n’a pas réussi à renvoyer la transaction.

• PB-89092 : Correction d’un problème dans lequel une transaction ne pouvait pas être envoyée comme prévu. La cause première était que la transaction avait été créée à partir d’un modèle qui utilisait la logique conditionnelle sur un champ qui n’existait plus.

• PB-87718 : Correction d’un problème dans lequel il était possible de configurer une date d’expiration de transaction qui dépassait le nombre maximum de jours avant l’expiration du Designer.

• PB-89186 : Correction d’un problème dans lequel un utilisateur se connectait à un compte d’essai gratuit, puis changeait la langue à partir du menu en haut à droite. Le problème était que le système n’a pas réussi à changer la langue de la bannière d’essai gratuit .

• PB-76319 : Correction du problème suivant. En cliquant sur l’icône Comptes organisationnels sur le tableau de bord, les expéditeurs ont consulté des sous-comptes qu’ils n’auraient pas dû être en mesure de voir. Il s’agissait de sous-comptes dans lesquels les expéditeurs n’avaient aucun rôle.

• PB-83290 : Correction d’un problème dans lequel les sous-comptes ne parvenaient pas à hériter du « thème » (par exemple, les couleurs de la marque) configuré dans la partie Expéditeur de la nouvelle expérience utilisateur.

Nouvelle expérience utilisateur

• PB-87999 : Correction d’un problème qui empêchait le rendu correct de certains textes dans les PDF dans la nouvelle expérience utilisateur. Le problème a affecté à la fois l’expérience du signataire et les expéditeurs (par exemple, le concepteur). Remarque : Ce problème a été résolu pour la plupart des cas d’utilisation. Cependant, cela peut toujours se produire lorsque des configurations matérielles spécifiques sont utilisées avec des documents PDF non conventionnels. Nous continuerons de surveiller PDF.js documentation pour toute résolution.

Développeurs

• PB-87868 : Correction du problème suivant. Si OneSpan Sign BackOffice est utilisé pour modifier la valeur du paramètre email.from dans la ressource email.properties, l’adresse e-mail FROM dans le JSON d’un modèle d’e-mail doit être mise à jour automatiquement. Le problème, c’est que cette mise à jour n’a pas eu lieu.

• PB-88857 : Correction d’un problème dans lequel le système ne parvenait pas à traduire un paramètre du modèle d’e-mail email.bulk.send.completed.

Salle virtuelle

• PB-89453 : Correction d’un problème dans lequel le bouton Commencer n’était pas visible pour les signataires dans une session de salle virtuelle s’ils étaient sur un appareil mobile.

• PB-89410 : Correction du problème suivant qui survenait lors d’une session de salle virtuelle. Lorsqu’un signataire cliquait à plusieurs reprises sur le bouton Suivant du navigateur de signatures, le système parcourait les champs obligatoires de tous les participants de la session. Il aurait dû être itéré uniquement dans les champs obligatoires du signataire actuel.

• PB-89278 : Correction d’un problème qui survenait lors d’une session de salle virtuelle. Le problème était que le système affichait un espace vide dans la liste des pièces jointes d’un signataire.

• PB-87215 : Correction d’un problème dans lequel : (1) un participant rejoignait une session de salle virtuelle après le début de la session ; (2) Le système n’a pas informé le participant qu’un enregistrement de la session était déjà en cours.

Délégation

• PB-88863 : Correction d’un problème dans lequel la fonction de délégation échouait dans les sous-comptes.

Résumé des données probantes

• PB-86851 : Correction d’un problème dans lequel le résumé des preuves enregistrait qu’un événement Confirmer les signatures était suivi d’un événement Vue . Le problème était que l’événement View ne s’est jamais produit.

Accessibilité

• PB-89715 : Correction d’un problème dans lequel les lecteurs d’écran ne parvenaient pas à lire correctement la logique conditionnelle qui apparaissait dans le concepteur.

• PB-91835, PB-91405 : Correction d’un problème dans lequel les lecteurs d’écran sur les ordinateurs de bureau ou les appareils mobiles ne parvenaient pas à lire les messages d’erreur concernant les codes d’accès SMS invalides ou expirés.

Comportement modifié

• PB-88352 : Dans la boîte de dialogue Conservation des données, nous avons modifié la configuration d’une période de rétention illimitée . Une case à cocher a été ajoutée.

• PB-89362 : Si la fonction de résumé des preuves incomplètes est activée pour un compte, les expéditeurs de ce compte peuvent désormais télécharger le résumé des preuves, quel que soit l’état de la transaction (y compris les brouillons).

• PB-87819 : Le système n’affichera plus la fenêtre contextuelle qui était auparavant utilisée pour identifier les destinataires en tant qu’accepteurs ou réviseurs. Au lieu de cela : (1) pour faire d’un destinataire un accepteur, le créateur de la transaction peut simplement cocher la case Accepter uniquement pour ce destinataire ; (2) pour qu’un destinataire soit réviseur, le créateur de la transaction peut simplement : (a) laisser la case Accepter uniquement décochée pour ce destinataire ; b) ne pas ajouter de champs au document pour ce destinataire.

• PB-86346 : Avant la fin de la signature, les champs Initiales indiquaient le nom complet du signataire. Ces champs n’affichent plus que les initiales du signataire (telles qu’elles apparaîtront dans la vue aplatie, c’est-à-dire terminée, du document).

• PB-88409 : Ce changement concerne le message d’expérience du signataire qui avertit les signataires que leur session va bientôt expirer. Auparavant, le temps restant avant l’expiration était exprimé sous la forme d’un nombre décimal (par exemple, 4,83 minutes). Ce temps est maintenant exprimé en nombre entier de minutes et de secondes (par exemple, 4 minutes et 50 secondes). Le nouveau format est plus convivial.

Changements à venir

• Dans le cadre de notre initiative Rebranding , nous mettrons à jour le logo du filigrane qui apparaît dans les blocs de signature signés.

• À partir de la version 23.R2 (11.51), vous ne pourrez plus activer la fonctionnalité de sous-comptes de l’administration d’entreprise. Pour les clients qui utilisent actuellement des sous-comptes, les incidents liés à des cas d’utilisation non documentés seront abaissés à la priorité P3 ou P4. Pour les incidents prioritaires P1 ou P2 liés à des sous-comptes, nous déploierons des efforts commercialement raisonnables pour fournir des solutions de contournement si : (1) l’utilisation du compte est affectée sur le plan opérationnel ; (2) le client ne peut pas trouver la cause profonde de cet impact dans ses propres systèmes ; (3) Nous déterminons qu’une solution à l’incident ne nécessite pas de nouveau code. Nous avons pris cette décision de nous concentrer sur la création de fonctionnalités de gestion de compte améliorées qui peuvent être réalisées en intégrant OneSpan Sign à notre nouvelle plateforme OneSpan Transaction Cloud. Remarque : Dans la version 23.R2, les clients pourront toujours : (1) demander la création de nouveaux comptes ; (2) obtenir l’aide de notre équipe d’assistance pour configurer leurs comptes.

• PB-89265 : La version 23.R2 (11.51) améliorera les performances de l’expérience du signataire en modifiant les règles qui régissent la récupération des documents. En particulier, dans certaines situations, le système récupère un PDF original au lieu d’un PDF aplati. La récupération d’un PDF original est plus rapide car elle est stockée dans la mémoire cache, tandis qu’un PDF aplati est toujours régénéré lorsqu’il est récupéré.

  Les paragraphes suivants fournissent de plus amples détails.

• PDF aplatis : les PDF aplatis ne seront récupérés que pour les activités suivantes : (1) affichage d’un document signé dont les signatures ont été confirmées ; (2) l’affichage d’un document en acceptation seulement après qu’il a été accepté ; (3) l’affichage d’un document qui a été signé ou accepté par un autre destinataire avant que le destinataire actuel n’accède à la transaction.

  PDF originaux : Les PDF originaux seront récupérés pour toutes les activités suivantes : (1) accès à un document (qu’il ait été désigné pour la signature, la révision uniquement ou l’acceptation uniquement) ; (2) la consultation d’un document signé dont les signatures n’ont pas été confirmées ; (3) la consultation d’un document de consentement électronique ; (4) l’affichage d’un document en révision uniquement ; (5) la consultation d’un document pour lequel : (a) le destinataire actuel a accompli toutes ses actions ; (b) un autre destinataire a encore des actions en attente (signer ou accepter).

  Remarque : Lors de la mise en œuvre de ces modifications, nous nous sommes efforcés de préserver l’intégrité des rappels, c’est-à-dire de nous assurer que les intégrations de rappel des clients continueront de fonctionner sans modification.