Nouveautés Sycomore v20.06

5.25 - [CA-TS] Allègement des contrôles sur les fichiers de LCR

Pour les clients

Une nouvelle option dans l’exploitation de la plateforme permet d’accepter les fichiers de LCR au format CFONB, normalement constitués de lignes de longueur fixe.
Si il manque des caractères dans certaines lignes, le fichier ne sera pas rejeté mais corrigé.
La solution consiste ici à compléter les lignes avec des espaces si il manque des caractères.
Attention : Cette fonctionnalité n’est possible que pour les fichiers présentant des retours chariots à chaque ligne

Pour l’exploitation

• Dans les fichiers à longueur fixe comme LCR (idem sur tous les fichiers CFONB), il faut accepter les lignes même s’il leur manque des caractères
  • La solution consiste à compléter les lignes avec des espaces si il manque des caractères.
• Ajout d’un paramètre dans Menu Configuration > Traitements, Onglet Contrôle des dépôts pour chaque type de fichier concerné
  • Libellé : Valider la longueur des lignes
  • Infobulle : Si activée, alors les lignes ne répondant pas à la longueur stricte de la norme seront rejetées.
  • Modifier le traitement d’intégration des fichiers afin d’alléger le contrôle de longueur en fonction de la configuration positionnée sur le type de fichier.

    

5.25 - [CA-TS] Restriction de l’affectation des habilitations

La fonction de restriction des habilitations permet de contrôler qu’un utilisateur exploitant ne puisse pas s’affecter d’habilitation à lui-même (ou à l’utilisateur métier qui lui est associé).
Cette fonction est configurable via le paramètre ccom.post.securite.habilitationsExploitant.restreindreAutoAffectationHabilitations.
Attention, la restriction de l’affectation des habilitations n’est pas activée par défaut.

Règles appliquées

• Si le paramètre plateforme restreindreAutoAffectationHabilitations n’est pas activé, alors
  • Pas de restriction sur les habilitations (c’est à dire comportement actuel avant cette évolution)
• Sinon
  • L’utilisateur connecté ne peut pas modifier sur son propre utilisateur :
    • Les habilitations (abonné ou exploitant)
    • Si exploitant :
      • Association de l’utilisateur abonné
      • Modification des habilitations de l’utilisateur abonné qui lui est associé
  • Si l’utilisateur abonné connecté a le rôle Exploitant, alors
    • L’utilisateur abonné ne peut pas modifier les habilitations sur lui-même, quelle que soit son habilitation courante.
  • Sinon (utilisateur client)
    • La gestion d’affectation des habilitations reste identique au fonctionnement actuel.

IHM

Exemple de restriction d’auto-habilitation sur IHM :

Si un utilisateur ne peut pas modifier ses habilitations, la configuration des habilitations est grisée et le message suivant est affiché :
Vous ne pouvez pas modifier vos propres habilitations. Vous devez demander à un autre utilisateur habilité de vous affecter les habilitations souhaitées.
Côté Gestion des utilisateurs, un nouvel indicateur grapihque (icône ’E’) permet de mettre en évidence les utilisateurs disposant de l’habilitation Exploitant :

Association d’un utilisateur abonné à l’utilisateur exploitant

Sur l’écran détail d’un utilisateur exploitant un nouveau champ de saisie permet de saisir l’email de l’utilisateur abonné correspondant à l’utilisateur exploitant.
Champ de l’utilisateur abonné associé :

Seul un utilisateur abonné avec le rôle ‘exploitant’ et qui n’est associé à aucun exploitant peut être renseigné dans ce champ.
A partir du 1er symbole saisi dans le champ, la liste des propositions, constituée des utilisateurs éligibles, est affichée.
La recherche des utilisateurs est effectuée sur leur nom, prénom et email.
Champ de l’utilisateur abonné associé :

En mode création de l’exploitant, si l’email est saisi et l’utilisateur correspondant n’existe pas, alors un nouvel ’utilisateur abonné est créé et associé à l’exploitant :

• Il dispose des mêmes caractéristiques que l’utilisateur Exploitant (nom, prénom, …​),
• Il a le même mot de passe que l’exploitant,
• Il a le rôle Exploitant,
• Il est marqué comme ayant été créé par un exploitant.
  En mode modification de l’exploitant, seulement un utilisateur existant peut être fourni.
  Pour dissocier l’utilisateur abonné il faut laisser le champ de saisie ’Utilisateur Support’ vide.

5.24 - Masquage des utilisateurs typés Exploitants de la liste des utilisateurs d’un abonnement

Désormais, les utilisateurs typés exploitants ou techniques associés à des abonnements ne sont plus visibles dans l’écran "Liste des utilisateurs" côté abonnés.
De même, lors de la création d’un nouvel utilisateur métier sur l’abonnement ou de l’association d’un utilisateur existant à l’abonnement,
alors les utilisateurs typés exploitants ou techniques déjà associés à l’abonnement ne sont plus comptabilisés dans le nombre d’utilisateurs associés.
Ainsi, la limitation du nombre d’utilisateurs associés à un abonnement s’applique uniquement aux utilisateurs métiers.

5.25 - Modèles des emails de notification de création ou de modification d’abonnement

Les modèles par défaut des emails de notification envoyés suite à la création ou la modification d’un abonnement,
comportaient des variables qui ne sont plus remplacées dans les notifications concernant les abonnements.
Les variables concernées sont :

• $abonnement.categorie
• $abonnement.societe.nom
• $abonnement.societe.adresse.pays
• $abonnement.societe.adresse.region
• $abonnement.societe.adresse.ville
• $abonnement.societe.adresse.rue
• $abonnement.societe.adresse.codePostal
• $abonnement.banque.bic
• $abonnement.banque.iban
  Si les modèles contenus dans la base de données sont strictement identiques à ceux par défaut,
  les scripts de migration se chargent de supprimer l’utilisation de ces variables pour ces 2 notifications.
  Toutefois, si les modèles ont été modifiés, il convient de s’assurer que les variables utilisées sont bien prises en charge.
  Pour cela, il suffit d’afficher l’aperçu de l’objet et du corps de la notification pour s’assurer que les variables sont remplacées.
  Pour rappel, les modèles de notification se configurent côté exploitant, dans l’écran accessible depuis le menu "Configuration > Notifications".

5.25 - [CA-TS] Retrait des champs de délais sur la gestion des services

Dans l’écran de détail d’un abonnement, la popup permettant d’ouvrir un service sur un abonnement peut être adaptée pour être simplifiée.
Mode complet :

Les champs ’Période d’essai’ et ’Durée minimale’ d’engagement peuvent être masqués via un paramètre défini sur la plateforme.
Mode simplifié :

Ces deux champs sont dépréciés et seront supprimés définitivement dans une version ultérieure.
Pour l’instant, ils sont conservés sur les abonnements, leur valeur par défaut peut être définie via le menu Configuration > Modules fonctionnels.

Les deux paramètres suivants permettent de contrôler l’affichage de ces champs :

• ccom.post.ihm.deprecies.abonnements.champPeriodeEssai.afficher : Propriété indiquant si le champ ’Période d’essai’ doit être affiché ou non dans la popup.
• ccom.post.ihm.deprecies.abonnements.champDureeMinEngagement.afficher : Propriété indiquant si le champ Période d’engagement doit être affiché ou non dans la popup.

5.25 - [CA-TS] Acces à l’application d’ajout d’abonnement simplifiée

Pour le besoin de simplification de la démarche de création d’abonnement pour CA-TS, l’application d’inscription de prospects a été mise à disposition sur leur plateforme.
Cette IHM spécifique ne sera pas pour autant exposée à l’extérieur, elle sera uniquement accessible à une connexion via l’application IHM.
On peut désormais y accéder à partir d’un nouveau menu dans l’IHM Exploitant.
Menu Abonnements > Inscription

Coté exploitant : ajout du menu "Abonnements > Créer abonnement"
Le menu "Abonnements > Créer abonnement" a été ajouté du coté exploitant afin de créer des abonnements.
Le menu est affiché si le paramètre suivant est valorisé pour la webapp Sycomore :

• ccom.post.inscriptionProspects.url : URL relative de redirection vers l’application de création simplifée d’abonnement (L’application est aussi nommée "Application d’inscription des prospects").

Configuration de la webapp Sycomore

Ajout de la configuration de l’URL relative de redirection vers l’application de création simplifée d’abonnement :

Configuration de la gateway

Ajout du routage vers l’application d’inscription des propects :

Configuration de l’application de création simplifée d’abonnement

Pour authentifier et auditer l’exploitant à l’initiative de la création de l’abonnement, un cookie X-Auth-Token est véhiculé.
Ce cookie contient le token JWT de l’exploitant.
Il est créé lors de la connexion à Sycomore, puis transmis à l’application de création simplifée d’abonnement.
Pour sécuriser l’appel via ce cookie, il est nécessaire de ne pas renseigner les paramètres suivants de l’application :

Si ces deux paramètres sont renseignés, il est possible d’appeler et valider directement le formulaire de création simplifée d’abonnement, ce qui n’est pas souhaité dans ce cas d’utilisation.
Enfin, concernant les appels vers l’application de validation des IBAN, il faut configurer l’URL afin que tous les appels passent par la gateway.
Le cookie X-Auth-Token est aussi propagé pour ces appels.

Sécurisation de l’application de création simplifée d’abonnement

Pour sécuriser l’application de création simplifée d’abonnement, il est nécessaire de bloquer l’accès en direct.
De cette façon, chaque exploitant souhaitant utiliser l’application, est obligé de se connecter à Sycomore, puis d’utiliser le menu "Abonnements > Créer abonnement" du coté exploitant.
Tous les appels passeront ainsi par la gateway.
L’authentification de l’exploitant est réalisée par un cookie X-Auth-Token qui véhicule son token JWT.

5.25 - [CA-TS] Désactivation de la fonction Gestion des revendeurs

Sur certaines plateformes, la gestion des revendeurs n’est pas une fonctionnalité utile.

Elle peut être désactivée via un paramètre : ccom.post.revendeurs.activer.
Si la fonction est désactivée, alors les champs relatifs aux revendeurs sont masqués sur les IHM.

Remplacement de la propriété masquant/affichant le menu Revendeurs

L’ancienne propriété post.exploitation.menu.revendeurs est remplacée au profit de la nouvelle propriété ccom.post.revendeurs.activer.

5.24 - Suppression du document CGU

Il est désormais possible de supprimer complètement le document CGU mis à disposition sur la plateforme et ainsi ne proposer aucune CGU d’utilisation de l’application.

5.24 - #6473 : PB0004267 : Sycomore - échec d’authentification 10/04/2020

Description

Incident de production sur le moteur SGBD de production SYCOMORE.
Impact fort, aucune action possible sur l’application.
Partition TMP full sur le moteur, du à un traitement client qui a saturé l’espace en 30 minutes.
Une extension de la partition a permis la fin du traitement. Et rendre l’application de nouveau opérationnelle.

Explication

Le problème est le même que celui rencontré le 14/11/2019.
Il est déclenché coté exploitant à partir de l’écran de recherche des transferts, dépôts et réceptions, lorsqu’une plage de date trop importante est renseignée et sans autre filtre.
La plage de date renseignée dans ce cas est du 2017-01-02 au 2020-04-10.
Le nombre d’enregistrements à traiter par la base de données est trop important pour le dimensionnement des ressources de la base de données, ce qui sature le moteur.

Solution mise en place

Avant traitement de la recherche, une requête de comptage plus légère a été mise en place afin d’estimer le nombre d’enregistrements manipulés par la base de données.
Si le nombre d’enregsitrements dépasse le nombre maximum autorisé, la recherche n’est pas réalisée et un message d’erreur est affiché à l’utilisateur.
Celui-ci indique à l’utilisateur qu’il doit affiner sa recherche.

Le nombre maximum autorisé est configurable avec le paramètre :

• ccom.post.exploitation.tableauBord.recherche.nbMaxResultats
• La valeur par défaut de ce paramètre est 1000.

Ecran tableau de bord Exploitant, limite du nombre de résultats.

5.24 - #6133 : PB0004234 : [STRATEGIA] : impossible de supprimer un serveur

Ajout d’un nouveau paramètre "Ne pas dupliquer" sur l’écran de configuration d’un serveur bancaire.
Ce paramètre est utilisé par la fonction de délégation de relevés, il permet d’indiquer que le serveur bancaire ne doit pas être dupliqué,
de l’entité de transfert vers l’entité comptable, lors de l’ajout du premier mandat sur une banque.

Il est visible seulement si :

• La fonction de délégation de relevés est activée sur la plateforme (Paramètre "ccom.post.releves.delegation.activer" est à vrai.).
• L’abonnement courant a une entité de transfert configurée (Abonnement "Strategia").
• L’entité courante associée au serveur bancaire, est l’entité de transfert de l’abonnement.

Ecran configuration serveur bancaire, paramètre ’Ne pas dupliquer’.

5.24 - #6170 : PB0004232 : [Strategia] : pas de vérification BIC/IBAN

Dans Strategia, ajout de la vérification de la correspondance BIC/IBAN des mandats :

• Lors de la création d’un mandat : Ecran de détails d’un dossier : erreur de correspondance BIC/IBAN.

  

• Lors de l’import d’un mandat : Ecran d’import de dossiers : erreurs de correspondance BIC/IBAN.

  

  La vérification de la cohérence BIC / IBAN est réalisée par interrogation de notre référentiel (Module de validation BIC/IBAN, service "/api/validationiban/ibans/description").
  Cette fonction est activée comme pour la plateforme Sycomore si le paramètre "post.validationIban.activer" est configuré à true. La vérification est réalisée par le backend de Stratégia.

5.24 - Configuration des Agents

Module fonctionnel ’Agent Sycomore’

Un nouveau module fonctionnel permet d’activer l’utilisation de l’agent Sycomore et l’accès à son écran de configuration.
L’activation se fait via l’écran de Configuration / Gestion des modules fonctionnels pour un exploitant.
Le module fonctionnel ’Agent Sycomore’ n’est pas activé par défaut pour les abonnements existants.
Charge au support de l’activer sur les abonnements utilisant l’agent aujourd’hui.
Ecran de gestion des modules fonctionnels :

Habilitation d’administration des configuration Agent

Une nouvelle habilitation permet de contrôler l’accès à l’écran de configuration des agents Sycomore sur un abonnement.
Cette habilitation peut être positionnée via l’écran de configuration d’un utilisateur côté abonné ou via l’écran d’affectation des habilitations sur un abonnement côté exploitant.
Cette habilitation peut être positionnée via web service via la constante ROLE_ADMIN_AGENT.
Ecran détail d’un utilisateur :

Ajout de la possibilité de saisir plusieurs configurations

La limitation empêchant la création de plus d’une configuration d’installation ne possédant qu’une seule configuration métier a été levée.
Il est désormais possible de créer plusieurs configurations d’installation ainsi que plusieurs configurations métier pour chacune d’elle.
Cela permet alors de gérer plus d’une configuration d’installation d’agent par abonnement et ainsi d’activer la gestion "multi-configuration" par un agent.
Au delà d’une gestion "multi-abonnement", c’est-à-dire des configurations récupérées par l’agent qui s’appliquent sur des abonnements différents,
l’agent est en fait "multi-configuration", ce qui inclut le multi-abonnement mais qui permet également d’avoir plusieurs configurations métier différentes pour un même abonnement.
Pour avoir une configuration d’agent multi-abonnement, il faut alors associer un utilisateur technique multi-abonnement à la configuration d’installation.
Cette configuration d’installation pourra alors contenir des configurations métier dans les abonnements auxquels l’utilisateur technique est associé.
Ainsi, pour créer une configuration métier dans un autre abonnement, il est nécessaire de changer d’abonnement courant.
De même, l’édition d’une configuration métier ne peut se faire que si l’abonnement courant correspond à l’abonnement associé.

Ecran listant les configurations d’installation

Afin de visualiser les configurations d’installation disponibles, un nouvel écran a été ajouté.
Les habilitations nécessaires restent les mêmes pour accéder à la fonctionnalité de configuration d’Agent.
Accessible directement depuis le menu, il liste les configurations d’installation liées à l’abonnement courant,
c’est-à-dire celles qui sont associées à un utilisateur technique appartenant à l’abonnement courant.
Cet écran permet alors de créer une nouvelle configuration d’installation, de supprimer une configuration existante ou d’accéder à son écran de détail.

Configuration d’installation

Ajout/Suppression de configuration métier

Dans l’écran de détail d’une configuration d’installation, il est maintenant possible de créer une nouvelle configuration métier ou de supprimer une configuration métier existante.
Même si toutes les configurations métier appartenant à la configuration d’installation sont listées,
la suppression de l’une d’elles ou l’accès à son écran de détail ne sont possibles que si l’abonnement à laquelle elle est associée est l’abonnement courant.

Configuration des notifications

Cette nouvelle section, dans l’écran de détail d’une configuration d’installation, permet à l’utilisateur de configurer un serveur de notification afin d’être averti en cas d’erreur de traitement.
L’utilisateur à saisir dans cette partie n’est pas un utilisateur Sycomore mais un utilisateur du serveur SMTP de notifications.

Configuration du proxy

La section Proxy, dans l’écran de détail d’une configuration d’installation, permet de configurer l’agent si celui-ci doit se connecter à un proxy.
Liste des données constituant la configuration du proxy pour une instance d’agent :

• Liste déroulante du mode :
  • Mode « Pas de proxy » : L’agent Sycomore n’applique aucune configuration de proxy
  • Mode « Système » : L’agent Sycomore applique la configuration de proxy définie au niveau du système
  • Mode « Surcharge » : L’agent Sycomore applique la configuration de proxy définie dans l’écran
    Les champs de configuration ci-dessous ne s’appliquent alors que pour le mode « Surcharge ».
    Les sections « HTTP » et « HTTPS » (visible seulement si le mode « Surcharge » est sélectionné) :
• Host : Nom du serveur proxy (1 seule entrée possible)
• Port : Numéro du port
• Utilisateur : Adresse email d’authentification sur le serveur proxy
• Mot de passe : Mot de passe de l’utilisateur sur le serveur proxy
• Hosts sans proxy : Liste des noms de serveur pour lesquels, ne pas appliquer la configuration de proxy
  Le mode « Système » est sélectionné par défaut, c’est-à-dire que l’agent va récupérer la configuration du proxy présente sur l’OS où il est installé.

** Configuration métier

Définition de groupes de répertoires de dépôts

Il est possible de définir, par FQA, des dossiers ’entrée’, ’encours’, ’archive’, ’erreur’ différents de ceux par défaut.
Pour cela, il faut définir un groupe de répertoires dans l’onglet "Dépôts".

• Chaque groupe de répertoires est identifié par un identifiant pouvant contenir des lettres de ’a’ à ’z’, majuscules et minuscules et des chiffres.
• Chacun des répertoires du groupe défini doit correspondre à un dossier différent et ne doit pas contenir de sous-dossier.
• Ils doivent, de plus, n’être référencés qu’une seule fois sur l’ensemble de la configuration.
  L’identifiant du groupe de répertoires peut ensuite être associé à une règle de nommage de type Expression régulière ("regexp").

Onglet de configuration des conversions

Cet onglet permet de configurer les conversions des fichiers.
Les paramètres suivants sont à définir dans cet onglet :

• La fréquence à laquelle les répertoires de dépôt des fichiers à convertir sont scannés
• Répertoire de dépôt des fichiers à convertir en SCT
• Répertoire de dépôt des fichiers à convertir en SCT avec création d’un dépôt
• Répertoire de dépôt des fichiers à convertir en SDD
• Répertoire de dépôt des fichiers à convertir en SDD avec création d’un dépôt
• L’actualisation ou non de la base ’référentiel Mandats’ lors de la conversion du fichier CSV ou CFONB
• La présence ou non de la RUM dans le libellé de l’opération
• Répertoire des fichiers en cours de conversion
• Répertoire des fichiers en cours de conversion avec création d’un dépôt
• Répertoire d’archivage
• Répertoire des conversions en erreur

Chiffrement des mots de passe

Désormais, les mots de passe utilisés dans la configuration de l’agent Sycomore sont chiffrés :

• Les mots de passe de l’utilisateur pour la connexion à Sycomore (dans la configuration d’installation et les onglets "Dépôts", "Réceptions" et "Conversions" de la configuration métier)
• Les mots de passe de l’utilisateur pour la connexion au serveur SMTP
• Les mots de passe de l’utilisateur pour la connexion au serveur PROXY
  Les mots de passe sont chiffrés via un algorithme qui permet leur déchiffrement par l’agent, et uniquement par lui.
  Pour cette raison, seuls les utilisateurs techniques utilisés dans une configuration d’agent ont leur mot de passe chiffré de la sorte.
  Les mots de passe chiffrés des utilisateurs de connexion aux serveurs SMTP ou proxy sont stockés dans les configurations d’installation d’agent.
  Les mots de passe chiffrés des utilisateurs techniques sont stockés dans une colonne dédiée de la table COMPTE_UTILISATEUR.
  La taille des mots de passe chiffrés dépend directement de la taille du mot de passe en clair.
  La taille actuelle de la colonne permet de gérer des mots de passe en clair possédant entre 96 et 144 caractères maximum.
• La borne minimum (96 caractères) correspond à un mot de passe ne possédant que des caractères encodés sur 3 octets en UTF-8.
• La borne maximum (144 caractères) correspond à un mot de passe ne possédant que des caractères encodés sur 2 octets en UTF-8.