Nouveautés de la version 4.4

1. Mise à jour de WildFly

Migration vers WildFly 33 (Java 11 et 17 seront toujours supportés) ;

NodeJS version 16 n’est plus supporté en raison de la mise à jour de la librairie Puppeteer utilisée principalement pour générer les rapports PDF avec l’API Ontomantics.
Ce qui implique que RedHat/CentOS 7, Ubuntu 17 et Debian 9 et antérieurs ne sont plus supportés par la plateforme (sauf si cette fonctionnalité n’est pas utilisée) ;

Le script config-datasource vérifie désormais que le dialecte sélectionné est bien compatible et est le meilleur avec la version de la base de donnée ;

Lors de la migration ou du démarrage, les mises à jour de NodeJS ne seront plus effectuées si la version détectée est incompatible;

Mise à jour mineure des dépendances (atmosphere, dropwizard metrics-core, pdf.js).

2. Navigateurs supportés pour la version 4.4

Les versions minimales sont les mêmes qu’en 4.3.

3. Gestion de l'authentification à deux facteurs TOTP

L’authentification à deux facteurs consiste à demander à l’utilisateur un code à usage unique après qu’il a validé son mot de passe. Ces codes à usage unique sont généralement composés de six chiffres renouvelés toutes les 30 secondes et sont générés par une application dédiée sur le mobile.
Les connexions via SSO ne sont pas concernées puisque c’est le rôle du SSO de gérer le second facteur.

Dans la politique de mot de passe, deux options Activer l'authentification à deux facteurs TOTP sont disponibles pour les comptes privilégiés et les comptes standards ;
Un paramètre Émetteur affiché dans l'application d'authentification apparaît alors. La valeur par défaut est le nom d’hôte ou le nom de l’entreprise en mode multi-entreprise PASS ;
Les comptes sont considérés comme privilégiés s’ils sont membres d’un groupe ayant l’option Groupe de compte à privilèges utilisant la politique de mot de passe renforcée comme les comptes système ;
À la première connexion d’un compte, il sera demandé à l’utilisateur d’activer la connexion à deux facteurs :
1. L’utilisateur devra télécharger une application telle que FreeOTP sur son mobile ou une extension pour son navigateur telle que Authenticator ;
2. La plateforme affichera alors un QRCode à scanner avec l’application ;
3. En cas d’impossibilité de scanner le QRCode, on peut afficher les informations à entrer manuellement dont la clé secrète, l’algorithme… ;
4. L’utilisateur devra ensuite entrer le code à six chiffres pour vérifier que la configuration est correcte ;
5. Apparaîtront ensuite 16 clés de récupération qui devront être sauvegardées en lieu sûr (de préférence dans un gestionnaire de mot de passe sécurisé) en cas de perte du mobile ;
6. À chaque connexion suivante, il sera demandé un code à six chiffres ou un code de récupération ;
7. En cas d’utilisation d’un code de récupération, il sera demandé si l’utilisateur souhaite reconfigurer l’authentification à deux facteurs.

Un administrateur peut réinitialiser les informations TOTP d’un compte sur le formulaire de l’utilisateur ;

Il est dorénavant possible de mettre des mots de passe de longueurs différentes pour les comptes privilégiés et standards ;

Il est enfin possible de spécifier une durée d’expiration des mots de passe différente pour les comptes privilégiés et standards. La CNIL recommande de ne pas faire expirer les mots de passe des comptes standards, mais de le faire pour les comptes privilégiés qui doivent utiliser un gestionnaire de mot de passe.

4. Amélioration de l'intégration de l'Intelligence Artificielle

Cette version améliore la prise en charge de l’Intelligence Artificielle sur la plateforme par l’exploitation de l’API Assistant d’OpenAI qui permet :

De répondre à des questions en s’appuyant sur la documentation de la plateforme ;

D’être moins limité par le nombre de Tokens Par Minutes de l’API /chat/completion empêchant son usage dans les gros modèles de données ;

De demander la génération de fichier Text/Word/Excel/PDF… (la génération d’images via Dall-E n’est pas implémentée pour le moment) ;

Le Chabot apparaît dorénavant dans tout le Designer.

Il peut afficher un lien vers la page de la documentation correspondante.

Dans les U.C. des écrans :

Possibilité de générer des écrans avec des contrôles ;

Possibilité de générer des écrans depuis une table existante du modèle de données ;

Dans les U.C. des contrôles :

Possibilité de générer des contrôles ;

Si l’écran contient un formulaire, alors la plateforme peut détecter la table liée et y ajouter les nouveaux champs et les insérer dans l’action d’ajout/modification et dans la règle de remplissage ;

Dans les U.C. de création des méthodes Web :

Possibilité de générer des méthodes via l’utilisation du format YAML OpenAPI ;

Possibilité de générer des méthodes depuis une table existante du modèle de données ;

Possibilité de générer des méthodes depuis une commande curl d’exemple ;

Possibilité de demander la création d’une commande curl d’exemple pour appeler une méthode existante ;

Dans les U.C. de fourniture des méthodes Web :

Possibilité de générer des méthodes via l’utilisation du format YAML OpenAPI ;

Possibilité de générer des méthodes depuis une commande curl d’exemple ;

Possibilité de demander la création d’une commande curl d’exemple pour appeler une méthode existante ;

Dans les U.C. de création des méthodes métier :

Possibilité de générer des méthodes depuis une table existante du modèle de données.

Dans les U.C. des requêtes et des requêtes et des règles :

Possibilité de générer des requêtes de sélection depuis les tables existante des modèles de données liés.

Ajout d’un composant Agent conversationnel dans le Player :

Il est lié à un jeu de données contenant les messages et les fichiers envoyés et reçus.