JPlatform 10 SP8 comporte 808 changements (issues) réparties ainsi : 

• 35 nouvelles fonctionnalités
• 280 améliorations
• 410 correctifs de bug
• 85 tâches

Cet article vous présente les principales nouvelles fonctionnalités et améliorations apportées par JPlatform 10 SP8.

1. Classification des contenus

JPlatform est destiné à gérer l'ensemble des contenus et des documents d'une organisation. Ces éléments peuvent comporter des informations sensibles qui mettraient en péril l'organisation si des personnes non autorisées et mal intentionnées y avait accès.

La gestion des droits de JPlatform, déjà très riche, permet de contrôler qui a accès à quels contenus. Cette gestion se base sur des listes d'accréditation (via les membres ou les groupes), sur des catégories (via le module CategoryRight), sur l'appartenance aux espaces collaboratifs (secret/privé) ou par d'autres règles spécifiques aux données (via des RightPolicyFilter). Cependant cette gestion, qui convient pour de nombreux cas d'usages, trouve ses limites pour la classification des contenus sensible qui nécessite de pouvoir normer des niveaux d'accès et d'appliquer des contrôles particuliers selon le niveau. La nouvelle fonctionnalité de classification des contenus répond à cette attente. 

1.1 Principes

La classification des contenus est optionnelle et permet de définir des niveaux de classification normés (p. ex. Public, Interne, Restreint, Confidentiel, Secret, ...) qui sont affectés à tous les contenus de la plateforme. Une fois activée elle s'applique sur tous les contenus (document, page Wiki, article, ...) de la plateforme. Cette information est affichée sur les contenus sous forme d'un petit badge coloré avec le nom du niveau. Ainsi les utilisateurs connaissent la sensibilité de chaque contenu et savent comment ils peuvent les utiliser. Un jeu de niveau est proposé en standard (Public, Interne,  Restreint, Confidentiel) mais vous pouvez définir le nombre de niveaux, les libellés et les couleurs que vous voulez. Dans les captures d'écran ci-dessous, ces niveaux ont été préfixés par C0, C1, C2 et C3.

La classification est aussi être définie sur les espaces. L'information est affichée dans la Tobpar d'un espace de travail :

Ainsi que sur la page d'accueil d'un espace collaboratif : 

Dans l'interface de recherche, une nouvelle facette "Classification" vous permet de filtrer les résultats de la recherche en fonction de leur niveau de confidentialité :

1.2 Mise en place

La classification est par défaut désactivée. Si vous souhaitez la mettre en place, allez dans l'éditeur de propriété, dans l'onglet "Avancé", cochez l'option "Classification des contenus" et enregistrez les proprietés. 

La classification est désormais activée. Cliquez sur le bouton "Configurer la classification". Vous arrivez dans l'interface de gestion de la classification qui vous permet d'agir sur les fonctionnalités, les contraites, de faire un audit des fonctionnalités/contraites par niveau, de choisir les différents niveaux et autres options.

Tous les contenus et les espaces ont comme niveau de classification le niveau par de classification de référence défini dans l'onglet "Avancé" :

1.3 Habilitation des membres

La classification permet aussi, de façon optionnelle, d'appliquer des droits d'accès aux membres. On parle alors d'habilitation. Cette option s'active dans l'onglet "Avancé" de l'interface de gestion de la classification.

Une fois le contrôle de l'habilitation des membres activé, il faut ensuite définir pour chaque membre son niveau d'habilitation. Un membre ne pourra accéder qu'aux contenus inférieurs ou égal à son niveau. P. ex. un membre habilité au niveau Restreint, pourra voir les contenus de niveau Public, Interne et Restreint. Mais il n'aura pas accès aux contenus du niveau Confidentiel. Le niveau d'habilitation est une information nominative. Il ne peut pas être récupéré des groupes (qui n'ont pas cette notion). Cependant, vous pouvez utiliser le traitement groupé pour affecter à un niveau à un ensemble de membre.

Les contrôles de droits liés au niveau d'habilitation s'appliquent aussi aux administrateurs centraux. Pour autoriser les administrateurs à gérer et consulter des espaces et des publications classifiées, les administrateurs doivent explicitement être modifiés pour préciser leur niveau d'habilitation.

Le contrôle du niveau d’habilitation des membres a un impact sur la délégation. La délégation d'un utilisateur A vers un utilisateur B ne peut se faire que si A un niveau d'habilitation supérieur ou égal à celui de B. Un membre A connecté en délégation avec l'utilisateur B ne peut pas augmenter le niveau d'habilitation de l'utilisateur B.

1.4 Contrôle des fonctionnalités

La classification permet aussi d'agir sur les fonctionnalités disponibles à chaque niveau. Grace à cela il devient possible par exemple d'interdire le partage des contenus avec des externes (les liens publics) ou l'édition avec MS 365 si le contenu est confidentiel. L'interface présente toutes les fonctionnalités du cœur et celles des modules. Pour chaque fonctionnalité il est possible d'indiquer jusqu'à quel niveau elle est disponible.Au-delà, la fonctionnalité disparaitra sur les contenus concernés. 

Ce tableau décrit l'ensemble des fonctionnalités de JPlatform qui peuvent être désactivées selon le niveau de classification :

Ce tableau décrit l'ensemble des fonctionnalités des module qui peuvent être désactivées selon le niveau de classification. Les fonctionnalités proposées par les modules seront disponibles au fur des ressortis des modules.

1.5 Application de contraintes

La classification peut aussi imposer des contraintes selon le niveau : p. ex. imposer la présence d'un code d'accès sur un lien public ou exiger une authentification TOTP pour accéder au contenu.

Ce tableau décrit l'ensemble des contraintes de JPlatform qui peuvent être activées selon le niveau de classification :

Une authentification à 2 étapes (module TOTP 1.3) peut aussi être imposée pour accéder à un contenu selon son niveau de classification.

1.6 Audit des niveaux

L'onglet Audit donne une synthèse de fonctionnalités et des contraintes pour chaque niveau. Il est aussi possible de lister les membres qui ont accès à un niveau donné en allant dans l'onglet Audit de l'interface de gestion de la classification.

1.7 Définition des niveaux

Le nombre de niveaux, leur couleur et leur description est totalement configurable : 

Il est possible de déterminer le niveau de classification par défaut des contenus sur le site. En outre, il est également possible de spécifier ce niveau de manière plus précise pour un espace de travail particulier. Il est même envisageable d'imposer un niveau minimal de classification dans un espace dédié (par exemple, un espace contenant des contenus particulièrement sensibles).

Dans le cas des espaces collaboratifs, le choix du niveau de classification se fait depuis l'interface de paramétrage de l'espace.

Si vous augmentez le niveau de classification minimum d'un espace de travail, cela entraînera une mise à jour du niveau de classification de toutes publications ayant un niveau inférieur au nouveau niveau minimum.

2. Profilage des contenus

Diffuser la bonne information à la bonne personne est un point essentiel pour faciliter l'adoption des intranets. Pour cela, le profilage (profiling en anglais) consiste à filtrer les informations diffusées selon le profil de l'utilisateur. Le profil de l'utilisateur peut être défini selon plusieurs axes : le métier, la localisation géographique, la hiérarchique, .... P. ex. avec le profilage, une personne du département Marketing basée à Paris, pourra voir des informations différentes d'une autre personne basée sur un site de production à Toulouse. 

Le profilage est proche mais néanmoins distinct de la fonction d'audiencement de JPlatform. Celle-ci applique des droits selon des axes de profiling. La différence avec le profilage est que même si l'information diffusée est filtrée selon le profil, celle-ci reste consultable, par exemple par une recherche. 

2.1 Principes

Les axes de profilage sont définis par des arborescence de catégories. Vous choisissez le nombre et la nature des axes de profilage que vous souhaitez. Il est néanmoins recommandé de ne pas dépasser 4 axes de profilage.

Le profilage peut être appliqué à tout type de contenus pouvant être catégorisés. Les contenus profilés doivent être catégorisés sur ces axes. JPlatform se charge ensuite de faire la correspondance entre le profil du membre et les catégories des contenus.

2.2 Exemple

Prenons deux axes de profilages représentés par les arborescences de catégories ci-dessous : 

• Axe Métier
  • Tous les métiers
    
    • Achats
    • Bureau d'étude
    • Comptabilité
    • Marketing
    • RH
• Axe Géographique
  •  Monde
    • Asie
      • Chine
      • Japon
    •  Europe
      • Allemagne
      • France 
        • Alsace
        • Bretagne

Et prenons 3 membres :

• Alice travaille au département Achat en Alsace.
• Bob travaille au Bureau d'étude en Bretagne.
• Carl travaille à la Bureau d'étude en Chine.

Dans les affichages profilés :

• Un article destiné à Tous les métiers en France, ne sera visibles que de Alice et le Bob
• Un article destiné au Bureau d'étude quelle que soit la zone géographique (Monde), ne sera visible que de Bob et Carl.
• Un article est destiné à l'Asie, ne sera visible que de Carl

2.3 Mise en oeuvre

Actuellement cette fonctionnalité nécessite d'avoir le module ESN. Dans une prochaine version, cette dépendance ne sera plus nécessaire.

Pour activer le profiling dans JPlatform 10 SP8, allez dans l'éditeur de propriété, dans l'onglet Utilisateurs et dans la section Profilage, sélectionnez une ou plusieurs arborescences de catégories représentant les axes.

Les utilisateurs doivent ensuite allez renseigner leur profilage sur leur page profil. Dans une prochaine version, il sera possible de définir des profils types par groupe. 

Ensuite, créez (ou modifiez) une portlet "Listes de contenus" en cochant l'option "Affiner sur les catégories de profilage"

Insérez cette portlet dans une page portail et elle affichera les contenus profilés des utilisateurs.

3. Analytics

3.1 Amélioration du rendu des graphiques

Jusqu'à présent, pour des périodes en dessous du mois, l'échelle de temps sur les graphiques temporels n'était pas toujours très lisible, car elle présentait des dates et des heures parfois en décalage avec les données affichées. A partir de JPlatform 10 SP8, l'échelle est désormais systématiquement en jour et cohérente avec les données présentées.

3.2 Export des métriques en CSV

Pour aller au-delà de ce que JPlatform propose dans l'analyse des usages, et faire d'autre analyse il peut être parfois nécessaire de passer par d'autres outils. Mais pour cela, il faut disposer des données. Désormais, sur chaque métrique vous pouvez exportez toutes les valeurs disponibles sur cette métrique sous forme d'un fichier CSV que vous pouvez ensuite ouvrir avec un tableur (Excel, LibreOffice) ou un outil de BI. L'export est proposé dans le menu "...".

3.3 Nouvelles périodes de filtrage

En plus des périodes déjà proposées et portant sur les 7, 30 et 90 derniers jours, l'interface propose aussi les 3 derniers mois, l'année passée et l'année courante.

3.4 Accès non authentifié ignoré par défaut

Enfin, par défaut, les accès non-authentifiés, comme ceux des robots d'indexation, ne sont plus pris en compte.

Si vous souhaitez néanmoins les prendre de nouveau en compte, il faut positionner la propriété suivante :

analytics.display-anonymous-visitor: true

4. Autres améliorations fonctionnelles

4.1 Lecteur de vidéo

Sur le lecteur de vidéos, vous pouvez augmenter ou réduire la vitesse de lecture des vidéos.

Si vous disposez du module Vidéo vous pouvez chapitrer la vidéo. Les utilisateurs verront le découpage en chapitres sur la barre de lecture et pourront passer rapidement d'un chapitre à l'autre.

Vous pouvez aussi récupérer un lien sur un passage précis de la vidéo en faisant un clic droit dans la vidéo et en cliquant sur le bouton "Copier le lien de la vidéo à partir de cette séquence". La personne qui ouvrira ce lien sera automatiquement positionné à cette position dans la vidéo.

4.2 Partage de contenus

Lorsque vous partagez un contenu à des membres, un petit message apparait confirmant que le contenu a bien été partagé.

De plus, il est désormais possible de masquer les destinataires afin que ces derniers ne voient pas avec qui le partage a été fait.

4.3 Amélioration de champs texte riches

Amélioration de l'édition dans la page

JPlatform vous permet de modifier le contenu d'un champ de type "Texte riches" (i.e. Wysiwyg) directement là où vous le consultez, en cliquant sur le bouton Modifier.  Lorsque la zone est petite, vous pouvez passer l'éditeur en plein écran pour plus de confort de rédaction. Une fois vos modifications faites, vous devez penser à quitter le mode plein écran pour enregistrer ces modifications.

Avec JPlatform 10 SP8, vous pouvez déclencher l'enregistrement directement depuis le mode plein écran et continuer votre rédaction.

Nouveau mode de comparaison des versions

JPlatform gère les versions des contenus qui sont modifiés. Il est ainsi possible de consulter l'ensemble des modifications qu'a subi un contenu. Il est aussi possible de comparer 2 versions pour voir les champs qui ont été mis à jour. Lorsque cette modification porte sur un champ de type "Texte riche" (ou Wysiwyg) jusqu'à présent JPlatform présenté les différents changement (ajout et suppression de texte) directement dans le corps du texte. Et cela sur le texte brut ou le code HTML. Il n'était donc pas toujours simple de voir où se situer le changement dans la page.

JPlatform 10 SP8 propose une troisième façon de présenter les différences : en comparant côte à côte les 2 versions mises en forme.

4.4 Nouvelle Médiathèque

Lorsque vous créez un contenu, vous pouvez insérer des images, ou des vidéos et ouvrant la médiathèque. Avec la version 10 SP8, elle a été repensée pour être encore plus simple à utiliser.

L'interface a été épurée. Différents filtres sont proposés (texte, espace, type, ...). L'ajout de média se fait par un simple/glisser déposer dans la zone ou en cliquant sur le bouton "Ajouter".

En cliquant sur l'icône Œil qui apparait au survol d'un média, une vue détaillée du média apparait : 

La médiathèque peut aussi se connecter à d'autres sources d'images, comme Giphy ou Unsplash. Vous les retrouvez dans le menu pour choisir l'espace, tout à la fin dans la section "Services externes". Pour cela, il faut installer les modules proposant la connexion avec ces services externes de média.

4.5 Création et modification par défaut en modal

De nombreux types de contenu proposent une page ou une modale dédiée pour la création et la modification. C'est par exemple le cas des articles de JNews, des événements de JEvent, des Flash Info, des albums de JGallery, ...

Jusqu'à présent le menu d'ajout des portlets Liste de publications ouvrait le formulaire avancé. Or ce formulaire s'ouvre en pop-up et est assez complexe. Et pour de nombreux types de contenu il est plus pratique d'utiliser la modale dédiée.

A partir de JPlatform 10 SP8, le menu de d'ajout des portlets "Liste de publications" ouvre désormais la modale associé au type de contenu. Cela peut être la modale spécifique à ce type de contenu, ou la modale générée automatiquement pour ce type de contenu.

Exemple de modal d'édition générique : 

Il est possible de désactiver ce comportement pour rétablir l'ancien édition en popup, en positionnant la propriété templates.edit.use-popup-and-front à true.

4.6 Amélioration sur les documents

Les surfaces de dépôt de documents ont été élargies pour faciliter le dépôt par glisser/déposer :

L'affichage des documents a été centré pour améliorer la lisibilité :

JPlatform permet de demander aux utilisateurs de confirmer qu’ils ont bien pris connaissance d’un contenu. Cela se fait en activant la confirmation de lecture sur un contenu (depuis l'interface de suivi des lecteurs). Une zone de confirmation apparait alors sous le contenu. Du fait de cette position, les utilisateurs pouvaient ne pas la voir. Elle est désormais affichée au-dessus du document.

Par défaut, lors d'un dépôt de fichier, JPlatform remplace les caractères soulignés ("_") par des espaces pour création du titre du document. Et lorsque l'on télécharge le document, comme il se base sur le titre, les soulignés ne sont pas conservés. Ceci dérange certains utilisateurs qui ont des règles de nommage incluant l'utilisation des soulignés. La propriété file-document.title.replace-underscore permet de contrôler si les soulignés doivent être remplacés ou non. La propriété est par défaut à true pour garder le comportement existant.

4.7 Autres améliorations

La corbeille propose des opérations en masse sur les documents qui ont été mis dedans : vous pouvez ainsi rapidement restaurer ou supprimer définitivement toute une série de contenu à la fois.

L’interface pour déposer sa photo de profil a été simplifiée : l'utilisateur choisit la photo, la fenetre de recadrage apparait avec un cercle représentant la zone de recadrage, il enregistre et la photo est à jour

L’affichage des résultats de la recherche présente à la fois le contenu correspondant au texte recherché mais aussi deux petites cartes vers les l’annuaire des membres et celui de espaces collaboratifs avec le nombre de résultats correspondant à cette recherche.

Grâce aux liens publics, vous pouvez partager des documents de votre intranet avec des personnes externes. L’interface de partage a été améliorée pour donner des indications plus claires lorsque l’on vient de créer un lien public :

Lorsque vous ajoutez des contenus pour le traitement groupé, un icone apparait dans la Topbar avec le nombre de contenus ajoutés. Désormais, lorsque vous cliquez sur cette icône, un menu apparait et propose d'accéder à l'interface de gestion du traitement groupe ou de vider le traitement groupé. Dans le futur, d'autres fonctions pourront être proposées dans ce menu.

Lorsqu’un utilisateur n’a pas de photo, ses initiales sont affichées comme photo. Pour l’inciter à mettre une photo sur son profil, un icone appareil photo apparait en permanence sur ses initiales dans la fenêtre coulissante qui s’ouvre lorsqu’on clique sur la photo de la Topbar et dans sa page profil (module ESN).

L'interface de gestion des catégories a été allégée en regroupant les actions que l'on peut opérer sur chaque catégorie dans un menu contextuel.

Et il est possible de forcer le tri alphabétique sur un ensemble de catégories via le traitement groupé

5. Administration

5.1 Workflow

Dans l'interface de gestion des types d'un espace de travail, le choix du Workflow à utiliser se fait maintenant avec un menu disposant d'une zone de recherche.

Dans l'interface de gestion des modèles de Workflow, vous pouvez en un clic afficher l'ensemble des espaces dans lesquels un workflow est utilisé.

5.2 Membres et Groupes

Des nouveaux filtres ont été ajoutés dans la liste des membres et des groupes en back office : 

Nouveaux filtres sur les membres 

Synchronisation LDAP : filtre les membres locaux ou ceux synchronisés avec le LDAP.

Nouveaux filtres sur les groupes

• Transverse / Espace : filtre les groupes transverses ou les groupes d'espace de travail.
• Organisation : filtre sur les groupes qui composent l'arbre des groupes de l'organisation / organigramme.
• Visibilité : filtre sur les trois types de visibilité de groupe possible : défaut, membres ou administrateurs.
• Synchronisation LDAP : filtre les groupes locaux ou ceux synchronisés avec le LDAP.

Suppression de la photo d'un membre lors de sa désactivation

Pour respecter le RGPD, il peut être nécessaire de supprimer la photo d'un membre dont le compte est désactivé. Cela est désormais possible en positionnant la propriété member.photo.delete-on-disable est à true (elle est à false par défaut).

Suppression d'un admin espace

Il est désormais possible de supprimer un membre qui est administrateur d'espace à condition qu'il ne soit pas le dernier administrateur actif d'un espace.

Audit des lanceurs d'applications

Les membres peuvent ajouter, supprimer et réorganiser les applications de leur lanceur d'applications. Un nouvel outil, accessible depuis le Catalogue des applications est proposé aux administrateurs pour auditer le lanceur d'applications d'un membre et restaurer le lanceur par défaut si nécessaire

Support des fuseaux horaires activé par défaut

Le support des fuseaux horaires avait fait son apparition dans JPlatform 10 SP1 pour permettre la saisie et l'affichage des dates et heures dans le fuseau horaire de l'utilisateur. Il est désormais activé par défaut. Vous pouvez le désactiver en positionnant la propriété channel.timezone.enabled à false.

5.3 Organisation des propriétés des modules par section

Certains modules peuvent comporter de nombreuses propriétés pour leur configuration. Il n'est alors pas toujours simple de s'y retrouver, d'autant que les propriétés qui sont liées ne sont pas forcément mises les unes à la suite des autres.

Avec JPlatform 10 SP8, les modules peuvent maintenant présenter leurs propriétés organisées en sections. La documentation pour organiser les propriétés de votre module par sections est disponible ici : https://docs.jalios.com/jplatform10/jcms/fr/front-end/plugin-properties-388743

6. Sécurité

6.1 Envoi de message à la délégation

Lorsque vous utilisez le compte d'un autre membre via la délégation, vous pouvez saisir un message qui sera envoyé à ce membre pour l'informer de la raison pour laquelle vous utilisez son compte.

Le membre concerné reçoit alors une notification de sécurité (déjà existante depuis JPlatform 10 SP4), enrichie du message saisi : 

6.2 Vérification des droits : accès pour tous

L'interface de vérification des droits sur une publication est dorénavant accessible à n'importe quel membre qui peut consulter la publication.

6.3 Gestion des jetons d'accès

La gestion des jetons d'accès, clés d'authentification (authkey) et JSON Web Token (JWT), a été revue afin de permettre une meilleure gestion de ces derniers. 

Une nouvelle interface de gestion permet de créer des jetons, suivre leur utilisation et les révoquer au besoin.

L'interface pour créer un nouveau jeton a aussi été amélioré. Après avoir choisi le type de jeton à créer :

Il vous suffit de renseigner le formulaire : 

6.4 Limiter les droits du partage inter-espace

Jusqu'à présent, on pouvait limiter à certains membre l'usage du partage inter-espace par une ACL. Et tout membre qui disposait de ce droit pouvait partager ou départager n'importe quel contenu auquel il avait l'accès dans n'importe quel espace dans lequel il était contributeur.

Des demandes ont été faites avoir un contrôle plus fin : pouvoir limiter le partage inter-espace à ceux qui ont les droits de publier le même type de contenu dans l'espace cible. C'est-à-dire qu'Alice ne pourra partager (ou départager) un article dans l'espace E1 que si elle a le droit de publier des articles dans E1. Ce nouveau comportant n'est pas actif par défaut. Si vous souhaitez l'activer, il faut positionner la propriété publication.attach-ws.check-pub-rights à true.

6.5 Message aux utilisateurs lorsqu’un fichier est renommé

Pour des raisons de sécurités, certains fichiers, comme les SVG, sont automatiquement renommé par JPlatform. Lorsque cela arrive, l’utilisateur est prévenu par un message :

6.6 Limiter le droit d’activation des portlets depuis JPortal

Depuis l’interface d’édition simplifiée de JPortal, il est possible d’ajouter de nouvelle portlet. L’activation d’un nouveau type de portlet dans l’espace se fait alors automatiquement. Mais dans certains cas, on souhaite mieux contrôler ces activations de nouvelles portlet. Aussi Il est désormais possible de limiter les personnes qui peuvent faire ces créations de portlet avec l’ACL « Création de portlet en édition simplifié ».

7. JStore

7.1 Nouveau Store générationnel pour gérer de très gros volumes d'écritures

JPlatform stocke les données de structure (espace de travail, groupe, catégorie, portlet, ...) ainsi que les membres dans le Store. Le Store gère l'ensemble de ses données en mémoire et assure leur persistance dans le fichier store.xml. Ce fichier ne contient pas directement les données mais toutes les opérations d'écritures qui ont été faites sur ces données (création, modification et suppression). 

Il existe une limite si la taille du fichier store.xml dépasse les 2 GB. Par défaut, JPlatform utilise l’API Java NIO pour lire ce fichier. Or cette API ne peut pas lire des fichiers de plus de 2 GB. Au-delà, il faut utiliser l’API Classic IO mais qui offre de moins bonnes performances. Cela impacte le chargement du store, l’accès à l’historique et surtout les performances des synchronisations dans un cluster JSync.

JPlatform 10 SP8 introduit un nouveau mécanisme, le store générationnel, qui permet de prendre en charge des fichiers de plus de 2 GB avec l’API NIO et assure des performances accrues sur les clusters JSync. Il est donc recommandé d’activer le store générationnel si votre fichier store.xml s’approche ou dépasse les 2GB ou si vous utilisez un cluster JSync.

Le store générationnel consiste à scinder le fichier store.xml en plusieurs fichiers regroupés dans le répertoire WEB-INF/data/store/. Chaque fichier faisant moins de 2 GB et il est donc possible de les lire avec l’API NIO. JPlatform les lit séquentiellement comme s’il s’agissait d’un unique fichier. Ces fichiers sont nommés store-prefix-1.xml, store-prefix-2.xml, … et le dernier fichier est nommé store-work.xml. C’est dans celui-ci que seront enregistrées les nouvelles écritures. Il faut donc veiller à ce qu’il ne dépasse pas les 2 GB. À noter que dans le cas d’un cluster JSync, le mécanisme de consolidation des écritures prend en charge ce contrôle.

Pour activer le store générationnel, il vous faut créer un répertoire WEB-INF/data/store et y copier le fichier store.xml en le renommant store-prefix-1.xml. Puis créer un fichier vide store-work.xml. Enfin, il faut activer la propriété channel.store.dir à true :

channel.store.dir: true

Une fois le store générationnel activé, en allant dans Administration > Etat du store, vous pourrez voir l'état des différents fichiers du répertoire WEB-INF/data/store/ :

7.2 Compactage du store

Le compactage du store (appelé "Nettoyage du store" dans les précédentes version) consiste à diminuer le poids des fichiers du store en regroupant ou en supprimant certaines opérations. Le compactage agit sur des séries d’opérations de mise à jour (update) sur un même objet et sur toutes les opérations portant sur des objets détruits.

Le compactage est une opération d’exploitation sensible. Avec le store traditionnel, elle nécessite un arrêt des écritures et le redémarrage de la Webapp (et de chacune des Webapps dans le cas d'un cluster JSync). Avec le store générationnel, il est désormais possible de déclencher un compactage du store sans arrêter les écritures et sans avoir à redémarrer la webapp. Cela est possible car avec le store générationnel, le compactage ne porte que sur les fichiers préfixes du store. Ces fichiers ne sont pas modifiés (en dehors du cas particulier des consolidations) et donc ils peuvent être retravaillés sans pour autant bloquer les nouvelles écritures du store qui arrivent dans le fichier store-work.xml.

L’interface de compactage a été revue pour gérer de très grande quantité d’espace de travail (plusieurs milliers).

Lors du compactage, l’attribut opAuthor (auteur de l’écriture) n’est plus considéré comme une méta-donnée et n’empechera plus de compacter la ligne si l’option de fusion des méta-données n’a pas été cochée. A l’inverse l’attribut restrictUpdateRights est maintenant considéré comme une méta-donnée lors du compactage.

L'interface Etat du store propose aussi maintenant des indicateurs qui permettent de savoir si un compactage est nécessaire. Deux indicateurs généraux sont présentés dans l'onglet "Info. Store" :

1. le ratio Modification / Création représente le nombre de modifications par rapport au nombre de créations. Plus ce nombre est élevé, plus l'impact du compactage sera important.
2. le ratio Opérations/Objet représente le nombre d'opérations (créations, mises à jour, suppression). Cet indicateur est particulièrement utile lorsqu'il y a eu beaucoup de mises à jour ou de suppressions d'objets. 

La couleur de chaque indicateur varie selon la valeur :  

• Rouge si le ratio est supérieur à 10
• Orange si le ratio est supérieur à 4
• Bleu si le ratio est supérieur à 2
• Vert sinon

L'onglet "Classes" affiche ces ratios et le détail pour chaque classe :

8. JSync

8.1 Consolidation des écritures

Lorsque JPlatform fonctionne avec le store générationnel, les nouvelles écritures sont ajoutées au fichier store-work.xml. Dans un cluster JSync, les opérations de synchronisation consiste à propager ces nouvelles écritures et à les réintégrer dans les fichiers store-work.xml de chaque réplicas. En cas d'écriture concurrente, JSync procéde à une fusion dont les performances sont directement lié à la taille du fichier store-work.xml. Le module de centralisation des écritures permet de fortement réduire le risque de fusion. Néanmoins, tous les contributeurs potentiels n'étant pas centralisés, des écritures concurrentes peuvent encore avoir lieu et entrainer des fusions. Si les fichiers store-work.xml sont de taille raisonable (moins de 100 MB), la fusion est généralement très rapide. Or une fois les synchronisations réalisées, tous ces fichiers sont quasiment identique. Ils ne dirvegent que sur les éventuelles nouvelles opérations qui sont ajoutées en fin. 

JSync intègre un nouveau mécanisme, la consolidation des écritures, qui permet de transférer les préfixes d'écritures commun à l'ensemble du cluster du fichier store-work.xml au fichier store-prefix-n.xml, "n" étant le plus grand préfixe disponible. Cette opération peut être réalisé à chaud (i.e. sans interruption). Elle est pilotée par le leader et nécessite que tous les réplicas soient déclarées auprès du leader et connectés au leader au moment où l'opération à lieu. L'opération peut être manuellement (via l'interface de gestion de la réplication), répétitive (p. ex. toutes les heures) ou planifiée à une certaine date (p. ex. tous les dimanches à 04h00). 

La consolidation des écritures est un processus en quatre étapes :

• Étape 1 : Identification du GCS (Greatest Common Stamp), qui détermine la limite du préfixe commun dans les fichiers store-work.xml.
• Étape 2 : Vérification et validation auprès des réplicas.
• Étape 3 : Transfert des opérations communes du fichier store-work.xml vers le store portant le préfixe le plus avancé.
• Étape 4 : Traitement des éventuelles erreurs rencontrées lors de l'étape 3.

De nombreux contrôles sont effectués lors des étapes 1 et 2 afin de déclencher la consolidation uniquement lorsque JPlatform est certains, à ce moment-là, que la consolidation pourra être réalisée avec succès. Lors de l'étape 3, des risques d'échec peuvent se présenter ; toutefois, grâce aux étapes 1 et 2, ces risques sont considérablement atténués, car ils ne concernent que les changements survenus sur une très courte période (entre les étapes 2 et 3).  À l'étape 4, le leader est amené à prendre certaines décisions en fonction des erreurs potentielles rencontrées durant l'étape 3.

Durant toute la consolidation, les écritures sont verrouillées sur le store du leader. Si des nouvelles écritures surviennent, elles seront mises en attente.

Les mesures de performances qui ont été menée ont montrée que la consolidation était un processus rapide et performant. La consolidation de plus de 100 000 écritures (80 Mo) sur un cluster de 6 réplicas s'effectue en 11 secondes. La vérification nécessite moins d’une seconde par réplica, tandis que le transfert des plus de 100 000 écritures prend une seconde par réplica. La consolidation engendre une légère amélioration des performances des fusions, en réduisant le nombre d'opérations à traiter. Dans le cadre d'une simulation comportant 2400 écritures concurrentes, nous constatons un gain de 2 minutes (43 minutes contre 41 minutes). Cette faible différence s'explique par le fait qu'avec la version 10 SP8, la gestion des messages entrants a été optimisée, entraînant ainsi une diminution significative du nombre de fusions requises.

8.2 Nouvelle interface de gestion de la réplication

L'interface de gestion de la réplication a été retravaillée afin de fournir une meilleure expérience utilisateur et des informations plus complètes.

Elle est accessible quel que soit le nœud du cluster JSync que l'on accède. Cependant, certaines actions ne sont disponibles que lorsqu'on y accède depuis le leader.

L'interface est décomposée en onglet. 

Le nouvel onglet "Cluster" affiche l'état du cluster JSync. Il présente les réplicas actuellement connectés et ceux qui ne sont plus connectés. Les actions de reconnexion et déconnexion des réplicas ne sont possibles que lorsqu'on se trouve sur le leader. 

L'onglet "Journal" a aussi été revu pour offrir une présentation plus claire des interactions entre le leader et les réplicas.

Enfin, deux nouveaux onglets, "DBEventLogs" et "ReplicaMessages", affichent l'état de ces deux tables de la base de données et qui sont liées au fonctionnement en cluster. Ces deux onglets devraient être la majorité du temps vide puisqu'il s'agit de données de transition qui sont supprimées une fois que les réplicas les ont traitées.

8.3 Agent JMX pour JSync

JPlatform 10 SP8 intègre un nouvel agent JMX permettant de suivre les indicateurs sur le nombre de DBEventLog et ReplicaMessage.

8.4 Autres améliorations sur JSync

Paramétrage des timeout

Il est maintenant possible de paramétrer les timeout des échanges JSync. La valeur par défaut est de 3 minutes pour les échanges (join, disjoin, suggestJoin, acknowledge) et de 6 minutes pour les synchronisations (update).  Ces 2 valeurs peuvent être modifiées avec les propriétés suivantes (en secondes) :

jsync.request-timeout: 180
jsync.update-request-timeout: 360

Ré-emission des mises-à-jour

Jusqu’à présent, lorsqu’un replica envoyait une mise à jour (update), à son leader si celui-ci ne répondait pas, il fallait attendre une nouvelle écriture sur le réplica pour qu’il réémette la mise à jour. Désormais, en cas d’échec le réplica réessaiera d’envoyer sa mise à jour à fréquence régulière (par défaut toutes les 15 minutes). Cette durée est paramétrable avec la propriété suivante (en minutes) :

jsync.retry-update.delay: 15

Pause lors des envois partiels

Lorsque le leader est fortement sollicité en écriture (par exemple, lors d’une synchronisation LDAP, il doit envoyer un grand nombre de mise à jour aux répliques. Ces mises-à-jour sont envoyées partiellement, par paquet. Durant cette phase d’envoi qui peut durer plusieurs dizaines de minutes, le leader ignorait les demandes de mise à jour entrantes des réplicas. JPlatform 10 SP8 évite cet effet tunnel, en ajoutant un temps de pause entre chaque mise à jour partielle pour permettre au leader de traiter les mises à jour entrantes. Cette durée, par défaut de 500 ms et qui doit rester faible, est paramétrable avec la propriété suivante (en millisecondes) :

jsync.partial-update-interval: 500

Optimisation de l’algorithme de synchronisation

Plusieurs améliorations ont été apportées à l’algorithme de synchronisation. Certaines synchronisations qui étaient traitées comme des fusions, sont maintenant traitées comme de simple ajout (donc beaucoup rapide à traiter) grâce à une amélioration de la détection de divergence. La recherche du point de divergence a été améliorée à la fois par le store générationnel (car on sait que par définition la divergence est forcément cantonnée au fichier store-work.xml) et analyse plus poussée des tables d’avancements du leader et du réplica.

Enfin, lorsque JSync est actif, il n’est plus possible de poser des marques (milestone) dans le store car ces opérations ne sont pas répliquées et peuvent entrainer des différences sur le nombre de lignes des fichier store.

9. Outils

9.1 Anonymisation du store

Pour certaines anomalies, il est parfois nécessaire que vous envoyiez votre store à notre équipe support. Or le store peut contenir des données sensibles qui ne doivent pas sortir de votre organisation. Vous pouvez désormais générer une version anonymisé du store. Ce store contient exactement les mêmes opérations mais pour chaque opération la plupart des attributs ont été replacés par un texte générique, HIDDEN_n, avec n égal au nombre de caractères du texte d'origine. Seules les valeurs numériques, les dates et les identifiants sont conservés.

Par exemple, une opération de création d'un membre.

<member stamp="c_100001" id="c_100001" op="create" cdate="1091526019025" declaredGroups="@|j_1" email="HIDDEN_17" info="HIDDEN_13" isEmailVisible="false" language="fr" login="HIDDEN_5" mailFrequency="0" mdate="1091526019025" name="HIDDEN_5 j_2" password="HIDDEN_24" />

Pour obtenir la version anonymisé du store, allez dans Administration >  Supervision > Etat du store et cliquez sur le bouton "Télécharger un store anonymisé". Vous récupérerez un fichier ZIP contenant le store anonymisé.

9.2 Changement de la langue principale du site

JPlatform peut gérer des sites en plusieurs langues. Les contenus et certaines données (espaces, groupes, catégories) sont multilingues. Lorsque plusieurs langues sont activées sur un site JPlatform, l'une d'entre elle est déclarée comme la langue principale. C'est dans cette langue que les champs obligatoires (comme le titre) doivent être renseignés. Techniquement, le stockage des champs de la langue principale est différent du stockage des autres langues. Aussi, si la langue principale doit être changée cela nécessite de faire des modifications sur toutes les données multilingues déjà saisies. 

JPlatform 10 SP8 apporte un élément de réponse à ce besoin. Il est désormais possible de modifier la langue principale du site lorsque le mode développeur est activé.  La nouvelle langue cible peut être choisie parmi les autres langues du site. 

Si langue principale doit être changée il faut le faire lors de la création du site. Le processus ne doit pas être lancé sur un site en production, et il est conseillé de le faire sans utilisateurs connectés. Le site doit être redémarré dès la fin du traitement.

Pour changer la langue principale du site, il faut avoir activer le Mode Développement dans les propriétés avancées, puis choisir la nouvelle langue se fait tout simplement en cliquant sur l'icône d'édition de la langue principale dans l'interface d'édition des propriétés :

Sélectionnez ensuite la nouvelle langue principale et cliquer sur le bouton "Enregistrer".

Le processus de conversion va se lancer en traitement en arrière-plan. Il va : 

• Mettre à jour (intervertir) tous les champs texte multilingue des types suivants : Publication (store et DB), Groupes, Catégories, Workspace.
• Mettre à jour la propriété channel.default-lang dans le custom.prop
• Puis arrêter les écritures du site et demander un redémarrage

Les modifications dans le store sont entourées de deux milestones.

La propriété channel.default-country et la langue des membres sont inchangées. Elles peuvent l'être ultérieurement et manuellement.

9.3 Contrôle des catégories de publications en base

Un nouvel outil de contrôle des catégories de publication en base est disponible depuis la zone d'administration du site.

Cet outil permet d'auditer les publications en base afin de vérifier, et éventuellement corriger, les dénormalisations des catégories de chaque publication pour garantir leur correspondance avec l'arborescence de catégories actuelle.

Une incohérence peut en effet survenir après des déplacements de catégories non pris en compte. Par exemple, si l'opération a été effectuée en environnement de recette ou suite à un crash applicatif.

10. Performances

10.1 Framework des traitements en arrière-plan (Background Process)

Certaines fonctionnalités de JPlatform peuvent nécessiter un temps de traitement très long, posant ainsi des problèmes tant sur le plan de l'expérience utilisateur (UX) que sur le plan technique. En effet, les utilisateurs sont peu enclins à attendre sans savoir combien de temps le traitement prendra. Si une requête est déclenchée en Ajax et dépasse 30 secondes, l'interface risque de se geler, laissant l'utilisateur incertain quant à l'état du traitement. Ce dernier pourrait alors tenter de relancer le processus, même si celui-ci est toujours en cours. Pour des traitements particulièrement longs, il est nécessaire de pouvoir informer l'utilisateur une fois le processus terminé. 

Des traitements intermédiaires, bien que relativement courts (quelques dizaines de secondes), peuvent semer le doute chez l'utilisateur quant à la durée d'attente. Dans ce cas, il est crucial de tenir les utilisateurs informés de l'avancement et de leur offrir la possibilité de demander une notification une fois le traitement achevé, s'ils ne souhaitent pas patienter.

Enfin, certains traitements sont prévisiblement longs, comme la conversion d'anciens événements de calendrier ou la génération de sous-titres pour une vidéo, tandis que d'autres, comme la traduction ou la génération de quiz, peuvent varier en durée en fonction des données à traiter. Dans ces situations, il faut permettre à l'utilisateur de décider s'il souhaite attendre ou non.

Avec le Framework des traitements en arrière-plan (BackgroundProcess), JPlatform 10 SP8 apporte une réponse à toutes ces questions sur les processus qui prennent un temps important ou un temps non prédictible. Ils peuvent désormais s'appuyer sur un framework qui permet à la fois de

• Gérer le processus en arrière-plan
• Remonter à l'utilisateur l'avancement
• Permettre à l'utilisateur de choisir s'il préfère attendre la fin du traitement (en suivant son avancement) ou bien partir faire autre chose et être prévenu une fois que le processus sera terminé.

La plupart des traitement longs ou variables de JPlatform sont désormais gérés avec ce nouveau mécanisme.

• Mise à jour des propriétés du site
• Mise à jour des propriétés des modules
• Activation / désactivation de module
• Traitement groupé
• Déploiement et réinitialisation des lanceurs d'applications
• Ré-indexation Lucene
• Import des membres
• Contrôle d'intégrité des données
• Nettoyage du store
• Consolidation des opérations communes (JSync)

Lorsqu'un traitement démarre l'utilisateur voit un message qui indique la progression. L'utilisateur peut aussi demander à être prévenu lorsque le traitement sera terminé en cliquant sur le bouton "Me notifier" qui apparait si le traitement dure plus de 5 secondes :

Une fois le traitement terminé, l'utilisateur est informé et peut recharger la page.

Lorsqu'un traitement est trop long, l'utilisateur peut quitter la page et partir faire autre chose. Le traitement continuera en arrière-plan. Mais l'utilisateur peut à tout moment suivre l'avancement des traitements en cours depuis la Topbar. 

Enfin une interface dans l'espace d'administration permet de retrouver tous les traitements actuellement en arrière-plan :

10.2 Limite sur les synchronisations LDAP

Sur de grands volumes de membres, les synchronisations LDAP peuvent entrainer de nombreuses opérations d’écritures. Comme les membres sont des données stockées dans JStore, dans un cluster JSync, cela peut engendrer de nombreuses et longues phases de synchronisation. Afin de mieux maitriser ces synchronisations LDAP, elles sont par défaut limitées à 30 000 membres. Cette valeur est paramétrable avec la propriété ldap.periodic-sync.maximum-operation-per-sync.

10.3 Amélioration des interfaces

Limiter le nombre de catégories affichées 

L'affichage d'une catégorie contenant de nombreuses catégories fille peut prendre du temps et ralentir le rendu des interfaces. Par ailleurs, afficher des listes de centaines de catégories n'est pas pratique pour cocher une catégorie. Et dans bien des cas, cette liste est affichée alors que l'utilisateur ne va pas modifier les catégories (mais modifier le contenu par exemple).

JPlatfom 10 SP8 plafonne désormais à 100 le nombre de catégories affichées directement sous une catégorie parente. Au-delà, un message apparait pour indiquer que toutes les catégories n'ont pas été affichées. Dans le cas d'une modification de contenu existant, ce sont les 100 premières catégories filles qui sont affichées ainsi que toutes les catégories déjà sélectionnées.

Cette fonctionnalité est débrayable via la propriété suivante : 

treeview.max-categories-displayed-per-node.enabled: true

La limite de catégories qui active cette fonctionnalité peut être changée par la propriété suivante : 

treeview.max-categories-displayed-per-node: 200

Chargement asynchrone du statut des membres

Les statuts des membres affichés sur les photos (les pastilles de couleurs) sont maintenant chargés en asynchrone et disposent d'un cache côté client (de 5 minutes). Leur calcul ne ralentit donc plus le chargement de la page.

Annulation des requêtes Ajax en doublon 

Lorsqu'une requête Ajax portant sur un même élément (un autocomplete souvent) est déclenchée deux fois, la précédente est annulée, ceci permet de réduire les requêtes au serveur et d'éviter qu'une requête 1 arrive après une requête 2 et fausse le résultat.

Décodage retardé des champs multilingues des publications stockées en base

Les champs ML des publications stockées en base sont encodés en JSON. Jusqu'à présent, ces champs étaient décodés au chargement de la publication.

Or la mécanique de filtrage dynamique de JPlatform (RightPolicyFilter et QueryFilter) fait que l'on peut charger des objets que l'on ne retiendra finalement pas. Or pour ces filtrages, il n'est généralement pas nécessaire d'accéder aux champs multilingues.

Désormais, les champs multilingues ne sont plus décodés au chargement de la publication mais au premier accès au champ.

Autres améliorations de performances

Les autocomplete dans les champs de données (publication, membres, ...) ne se déclenchent qu'à partir du 3e caractère tapé.

La performance dans la gestion des liens "faibles" (WeakLink), c'est à dire les liens dans les champs de type Texte Riche, a été améliorée.

Des correctifs ont été faits dans la gestion des DBEventLog pour améliorer les performances dans les environnements utilisant JSync.

11. Développement Front-end

11.1 Nouveaux composants

Switches

Tous les champs booléens avec des libellés Oui/Non sont maintenant remplacés par le composant "switch".

Cette fonctionnalité est désactivable en positionnant la propriété ui.form.input-boolean.use-switch à false.

Champ téléphone

Un nouveau type de contrôle permet d'insérer des champs destinés à saisir un numéro de téléphone.

Exemple de code :

<jalios:field  name="phone" ... >
  <jalios:control type="<%= ControlType.TELEPHONE %>" />
</jalios:field>
<jalios:field  name="mobile" ... >
    <jalios:control settings='<%= new TelephoneSettings().placeholder("ui.com.placeholder.mobile") %>' />
</jalios:field>

Boutons segmentés

Ce nouveau composant affiche un choix multiple (de type radio ou checkbox) via des blocs de boutons à cocher : 

11.2 Tags

Tag memberphotogroup : Photos de membres groupées

Ce tag permet de présenter un ensemble de photos (ou initiales) de membres dans un espace réduit. Par défault, les photos affichées sont limitées à 5, au-delà un chiffre indique le nombre d'autres membres. Pour gagner encore de la place, les photos peuvent se chevaucher.

Exemple de code : 

<jalios:memberphotogroup members="<%= mbrSet %>" photoSize="TINY" moreButtonAction="MODAL" hoverMode="NONE"/>

<jalios:memberphotogroup members="<%= mbrSet %>" photoSize="TINY2" css="-grid" max="3" hoverMode="NONE"/>

Tag member : affichage de la photo et de nom d'un membre

Le tag <jalios:link> permet d'insérer un lien vers n'importe quelle données (Data) de JPlatform. Cela fonctionne donc aussi pour les membres. Mais dans de nombreuses interfaces, on a besoin de présenter à la fois la photo et le nom du membre. On peut utiliser le tag <jalios:memberphoto> mais pour respecter les critères d'accessibilité, il faut qu'il n'y ait qu'un seul lien pour la photo du membre et son nom.

Le nouveau tag <jalios:member> prend cela en charge. Il suffit d'indiquer le membre à afficher et la taille de la photo (si la taille n'est pas précisée, c'est la taille PhotoSize.ICON qui sera utilisée).

Exemple : 

<jalios:member member="<%= loggedMember %>" photoSize="<%= PhotoSize.TINY %>"/>

Tag Thumbnail : chargement différé de l'image

Par défaut les thumbnail sont chargés en différé. Le comportement peut être globalement changé avec la propriété tag.thumbnail.lazy-loading.enabled. Vous pouvez aussi le changer ponctuellement avec l'attribut lazy du tag <jalios:thumbnail>.

Exemple :

<jalios:thumbnail lazy="false" path="debug/components/images/sampleLazy.jpg" width="200" height="200" />

Dans la portlet Image, une option est disponible pour choisir si il faut différer ou non le chargement de l'image.

Tag cardsData : Défilement des cartes (card swiper)

JPlatform 10 SP8 propose un nouveau gabarit de présentation de cartes : un gabarit qui affiche un nombre de cartes adapté à la surface disponible et propose des flèches pour faire défiler les cartes horizontalement.

Ce nouveau gabarit est utilisé en standard pour présenter les publications liées.

Exemple de code : 

<jalios:cardsData collection="<%= pubRelatedCollection %>" titleTag="h3" maxItems="<%= pubRelatedMax %>" resource="cardsdata.relateds" />

11.3 Nouveau gabarit Carrousel

Ce nouveau gabarit, basé sur la librairie Swiper.js qui permettait d'améliorer l'accessibilité du carrousel.

11.4 Masquage des champs de portlet selon le gabarit choisi

Depuis l'édition d'une portlet via JPortal, il est maintenant possible d'indiquer quels champs sont disponibles selon le gabarit.

Exemple : 

jportal.edit-portlet-modal.portlet-hide-fields.PortletQueryForeachDetail.box.carousel: showTitle showAbstract showAuthor

Ici pour la PortletQueryForeachDetail et le gabarit template box.carousel, nous masquons les champs showTitle, showAbstract et showAuthor dans l'interface d'édition front office du JPortal.

Pour plus de détails consultez la documentation : https://docs.jalios.com/jplatform10/jcms/fr/front-end/composants/portal/hide-fields-depending-on-template-410677

11.5 API pour la copie dans le presse-papier

Une nouvelle API permet de faciliter le développement d'un bouton pour copier un contenu dans le presse-papier.

Exemple pour proposer la copie d'un texte brute : 

<% String rawTextSample = "The R&D is wonderful (and 42<666) !"; %>
<% String copyRawTextConfirmation = "The text was copied to the clipaboard."; %>
<button type="button" class="btn btn-default copy-to-clipboard"
        data-jalios-text-to-copy="<%= encodeForHTMLAttribute(rawTextSample) %>"
        data-jalios-toastr-text="<%= encodeForHTMLAttribute(copyRawTextConfirmation) %>">
        Copy text
</button>

Exemple pour proposer la copie de HTML : 

<% String copyHtmlConfirmation = "The HTML was copied to the clipaboard (pasted in a wysiwyg editor to see formated content)."; %>
<button type="button" class="btn btn-default copy-to-clipboard"
        data-jalios-target-to-copy="#html2copy"
        data-jalios-toastr-text="<%= encodeForHTMLAttribute(copyHtmlConfirmation) %>">
        Copy HTML
</button>
<div id="html2copy" class="hide" aria-hidden="true">
  <p><em>Hello</em> <strong>World</strong>!</p>
  <p>Follow this link to <a href="https://www.example.com/">access example.com</a></p>
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
  </ul>
</div>

11.6 Insérer une action dans le menu du Traitement groupé de la Topbar

Lorsqu'un membre ajoute des données dans le traitement groupé, un icone apparait dans la topbar qui rappelle le nombre d'éléments sélectionnés pour le traitement groupé. En cliquant sur cet icone, un menu apparait. Il est possible de s'insérer dans ce menu. Pour cela, déclarez votre JSP par une propriété ayant pour préfixe caddy-menu.item. suivi d'un numéro / index puis un identifiant libre.

caddy-menu.item.[order].[key]: [path-to-JSP]

Exemple en standard, les liens "Ouvrir" et "Vider" le traitement groupé :

caddy-menu.item.20.open:  jcore/topbar/items/doTopbarCaddyOpenItem.jsp
caddy-menu.item.60.clear: jcore/topbar/items/doTopbarCaddyClearItem.jsp

11.7 Librairie Front ajoutées, mises à jour ou supprimées

12. Développement Back-end

12.1 Classification

Si vous souhaitez pouvoir limiter l'accès à certaines fonctionnalités ou au contraire imposer des contraintes selon le niveau de classification d'un contenu, reportez vous à la documentation https://docs.jalios.com/jplatform10/jcms/fr/back-end/api-de-classification-des-publications-405761

12.2 Framework des traitements en arrière-plan (Background Process)

Pour intégrer le framework des traitements en arrière-plan, reportez-vous à la documentation : https://docs.jalios.com/jplatform10/jcms/fr/back-end/background-process-428389

12.3 Possibilité d'écouter l'activation et la désactivation des modules

Les PluginPolicyFilter sont notifiés lors de l'activation et lors de la désactivation des modules via les méthodes enablePlugin(Plugin) et disablePlugin(Plugin).

12.4 Analytics

En cas de délégation, l'information sur le membre délégué est désormais présente dans l'attribut delegationContext.

Il est aussi possible de filtrer programmatiquement ce qui est enregistré dans les fichiers JSON. Cela vous permet par exemple d'ignorer certaines requêtes comme celles faites par les outils de monitoring. Pour cela il faut développer un EventDataListener et implémenter la méthode processEventData() et de l'ajouter via la méthode AnalyticsManager.getInstance().addEventDataListener(). Pour ignorer un événement, il suffit alors que la méthode processEventData() renvoit null.

12.5 Ajout d'événement lors des connexions/déconnexions Push

Un événement interne et un log d'analyse des usages est maintenant généré lors de la connexion/déconnexion sur la fonctionnalité de push notification.

Pour l'événement interne, un nouveau listener PushEventListenerpeut être enregistré sur com.jalios.jcms.push.servlet.ProviderManager pour réagir à cet évènement.

12.6 SPI External Providers pour PubBrowser et MediaBrowser

Comme cela a été décrit plus haut, il est possible d'ouvrir les interfaces permettant de choisir une publication ou un média à des sources externes. La version 1.1 du module JDOC proposera ainsi de référencer dans n'importe quel champs publication ou documents, des fichiers issus d'une GED Externe.

De même, le module Giphy permet de sélectionner des GIF animé dans un champ média. Et le module Unsplash propose de faire de même avec un accès à la banque d'image éponyme.

Il vous est aussi possible de développer des connecteurs avec des service externes. Pour cela, suivez la documentation : PubChooser / Media browser : external providers

12.7 SPI pour l'envoi et la réception des mails

Il est à présent possible de remplacer le système d'envoi/réception des mails standard (basé sur les API JavaMail) par un autre service.

Ceci est notamment mis en œuvre par le module MS 365, pour permettre l'utilisation de l'API Graph pour l'envoi et la réception des mails.
L’utilisation de cette fonctionnalité passe par la déclaration d’un MailProvider dans les propriétés de la plateforme.
Exemple (déclaration du MailProvider utilisant l’api MS 365): 

mail.provider.m365Provider.class: com.jalios.jcmsplugin.office365.provider.Microsoft365MailProvider
mail.provider.m365Provider.apiKey:<API_KEY>
mail.provider.m365Provider.apiSecret:<API_SECRET>
mail.provider.m365Provider.tenantId:<TENANT_ID>

12.8 Chaînage de propriétés

Il est maintenant possible de créer des propriétés "chaînées", c'est à dire dont la valeur est la valeur d'une autre propriété. Une propriété peut prendre pour valeur la valeur d'une autre propriété. Pour cela il suffit d'indiquer en valeur le préfixe prop: suivi du nom de la propriété. 

Exemple :

my.legacy.prop: 1234
another.prop: prop:my.legacy.prop

12.9 OpenAPI / REST

Préférence utilisateurs (MbrPref)

Il est maintenant possible de consulter les memberPreferences d’un utilisateur via l’api REST /data/Member/{login}/preference/{key}.

Cette API est disponible en GET/PUT/POST/DELETE avec les contraintes suivantes :

• Un utilisateur sans droit particulier ne peut accéder qu’aux préférence qui le concernent
• Un administrateur (ou quelqu’un avec l’ACL admin/users/member) peut accéder aux memberPreferences des autres membres (en lecture comme en écriture)

Un utilisateur avec l’ACL ne peut accéder aux préférences d’un DBMember (en lecture comme en écriture). Les préférences par défaut (provenant du code ou des propriétés) sont en lecture seules sur l’API REST et accessible par tout utilisateur connecté sur l’URL members/defaultPreference/{key}.

Etat du site (StateManager)

Ajout dans le produit d’un manager portant l’état de la plateforme (StateManager.getInstance().getState()).

Cet état est parmi les valeurs suivantes (inspirées des états possibles dans Kubernetes) :

• JPlatformState.STARTUP : indiquant que la plateforme est en cours de démarrage
• JPlatformState.READY : la plateforme est disponible au service
• JPlatformState.ALIVE : la plateforme a fini de s’initialiser correctement (la plateforme répond aux requêtes web)
• JPlatformState.ERROR : la plateforme a rencontré une erreur grave et n’est pas disponible. L’état de la plateforme peut être accompagné d’un message explicatif optionnel.

L’état est consultable :

• via l’API REST : avec une adresse publique rest/state
• via une ressource JMX dont la clé est domain jalios.jplatform:Instance=<channel name>,component=StateManager,name=StateManager

L’état de la plateforme peut être modifié :

• via le code :  StateManager.getInstance().setState(JPlatformState.READY, message)
• via l’api REST (si l’utilisateur loggé est un admin ou avec l’ACL admin/operation/state-management)
• via une méthode JMX 

Enfin il est possible via un com.jalios.jcms.exploitation.state.StateNotifier pour être notifié de tous les changements d’état de la plateforme.

Les StateNotifier sont ajoutés via l’appel à la méthode addNotifier sur StateManager ou en positionnant le nom de classe du notifier via une variable d’environnement ou un paramètre système de la JVM (dans les 2 cas, la clé est préfixée par jplatform.state.notifier.class.).

Exemple : -Djplatform.state.notifier.class.file=com.jalios.jcms.exploitation.state.FileStateNotifier

Le StateNotifier par défaut (com.jalios.jcms.exploitation.state.FileStateNotifier) fournit l’état dans un fichier jplatform.alive, jplateform.ready,  ... dans le répertoire WEB-INF/jcmswork/ en étant compatible avec la fonctionnalité précédente (ReadinessManager étant maintenant déprécié).

Récupération des acteurs de workflow courant sur une publication

 Sur une publication, il est maintenant possible d’obtenir la liste des acteurs courants pouvant travailler sur la publication, via la méthode getCurrentWorkers().

Ces données sont aussi disponibles dans les champs related, ajoutables lors d’un export d’une publication via l’API REST (related=currentWorkers).

Modification des règles de notifications

Auparavant, la modification des règles de notifications d'un utilisateur nécessitait de préciser tous les paramètres alertLevels, alertDomainNames, alertChannels. Il est désormais possible de modifier ces réglages via le paramètre encodedAlertRules, objet JSON dont la valeur est retournée lors de la récupération des données d'un membre via l'API REST.

Exemple :

jQuery.ajax({
  method: 'POST',
  data: {
    "encodedAlertRules": '[{"levelKey":"warning","domain":"admin","alertChannels":["mail","web"]}]',
    "opUpdate": true
  },
  url : JcmsJsContext.getBaseUrl() + "rest/data/j_2",
  success: function(result) {
    console.log(result);
  }
});

12.10 Librairie Java ajoutées ou mises à jour

13. Compatibilité et migration

13.1 Tomcat 9 / Java 17

Tomcat 8.5 n'est plus supporté. Cette version est en fin de vie depuis le 31 mars 2024 et ne supporte pas la spécification des Servlet 4.0.

Vous devez utiliser Tomcat 9.x (Attention, Tomcat 10 et versions plus récentes ne sont PAS supportées).

JPlatform 10 SP8 est certifié avec Java 11 et Java 17.

13.2 Compilateur Java

ECJ (Eclipse Compiler For Java) est désormais le compilateur utilisé par défaut pour compiler les classes générées. Il permet de prendre en charge des boucles de dépendance de compilations que ne gère pas javac.

Si vous souhaitez néanmoins revenir au compilateur javac, vous pouvez le faire avec la propriété suivante :

channel.java-compiler: internal 

13.3 Bases de données

JPlatform 10 SP8 est certifié sur plusieurs SGBDR externes :

• PostgreSQL 12, 13, 14 et 15 et 16
• MySQL 8 (moteur de stockage InnoDB)
• Oracle 19c et 21c
• Microsoft SQL Server 2012, 2016 et 2019
• MariaDB 10

13.4 Modules

JPlatform 10 SP8 nécessite d'avoir les dernières versions de certains modules : 

• Module Calendrier Local 1.5.3 
• Contributions Centralisées 2.3 
• Module Espaces Collaboratifs 8.0.14 
• Module JCalendar 1.6.3 
• Module JDoc 1.0.1 
• Module JEvent 1.4.1 
• Module JNews 2.6.1 
• Module JProcess 2.7.1 
• Module JTask 3.8.1 

13.5 Store générationnel

Par défaut, JPlatform 10 SP8 est livré pour fonctionner avec le store classique (fichier store.xml).

Si vous souhaitez néanmoins, bénéficier du store générationnel, vous devez appliquer la procédure suivante :

Si votre fichier store.xml fait moins de 1,8 GB :

1. Créez un répertoire WEB-INF/data/store/
2. Copiez votre fichier WEB-INF/data/store.xml dans WEB-INF/data/store/store-prefix-1.xml
3. Créez un fichier un fichier vide WEB-INF/data/store/store-prefix-2.xml
4. Créez un fichier un fichier vide WEB-INF/data/store/store-work.xml

Si votre fichier store.xml fait plus de 1,8 GB :

1. Créez un répertoire WEB-INF/data/store/
2. Découpez votre fichier WEB-INF/data/store.xml en autant de fichiers de moins de 1,8 GB chacun.
3. Copiez ces fichiers dans le répertoire WEB-INF/data/store/ en respectant l'ordre du découpage et en les nommant respectivement store-prefix-1.xml, store-prefix-2.xml, ...
4. Créez un fichier un fichier vide WEB-INF/data/store/store-work.xml

Enfin, dans les 2 cas, ajouter la propriété suivante dans votre fichier WEB-INF/data/custom.prop :

channel.store.dir: true

13.6 web.xml

Le fichier WEB-INF/web.xml a été mis à jour pour utiliser Servlet API 4.0.
Si vous aviez personnalisé ce fichier avec des réglages spécifiques, vous devez reprendre les modifications.

13.7 Description de la notification (alerte) d'une recommandation

La propriété de langue alert.msg.recommendation.notification.description a évolué afin de dissocier & déplacer la liste des destinataires sous le message de la recommandation.

-alert.msg.recommendation.notification.description: <p>{author} shared you {data}</p> {recoContent}
+alert.msg.recommendation.notification.description: <p>{author} shared you {data}</p>

Vérifier vos éventuels développements spécifiques liés à cette notification.

13.8 Classification des publications

Suite à l'introduction de la fonctionnalité de classification des publications :

• Le champ "classificationLevel" sur le type Publication est réservé.
  Si un de vos types de contenu personalisés présente un champ de ce nom, il doit être renommé préalablement à la migration.
• Les colonnes exportées en CSV évoluent, ceci pourrait avoir des conséquentes sur d'éventuels traitements de données : 
  • Export CSV des publications : une nouvelle colonne est présente pour exporter la valeur du champ classificationLevel des Publications
  • Export CSV des membres : une nouvelle colonne est présente pour exporter la valeur du champ authorizationLevel des Membres
• Une réindexation complète des publications et des membres est requise après migration

Le fichier custom.prop comportent de nombreuses propriétés liées à la configuration de la classification. Elles commencent toutes par le préfixe classification. . Cependant, l'interface de gestion de la classification, vous permet de gérer ces propriétés sans avoir à les éditer manuellement.

13.9 Propriétés pour les jetons d'authentification

(1) Une authkey révocable est stockée en base à sa création, et controlée à son utilisation. Activer ce réglage permet de renforcer la sécurité.  Ce réglage est désactivé par défaut pour ne pas casser la compatibilité avec les authkeys déjà émises (n'ayant pas été stockée en base et donc non controlabe). Ce réglage s'applique pour toutes les authkeys correspondant à la cible de renforcement, qu'elles soit déjà émises ou nouvellement créées. 

(2-reco-activation) Recommandations : activez ce réglage pour une sécurité accrue

1. identifier les authkeys déjà émises sur les services externes, avec la cible de renforcerment (admin/prefix/expiration longue) 
2. regénérer des authkeys pour ces services
3. activer la fonctionnalité pour obliger le controle en base renforcer la sécurité
4. surveiller les échecs de services distant qui aurait été oubliés, et regénérer des authkeys pour ces services

13.10 Mise à jour de l'import CSV de membres

Dans les précédentes versions, les ressources JSPs et fichiers .csv d'exemple à télécharger se trouvaient dans /admin/import.
Ces fichiers ont été déplacés dans /admin/member/import.
Si vous avez des propriétés pointant l'ancien chemin, veuillez les mettre à jour.

L'ancienne API a été retirée au profit d'une refonte en traitement asynchrone.
Si vous aviez des développements liés à l'API dans le package  (com.jalios.jcms.handler.MembersCsvImportHandler, com.jalios.jcms.MemberImportManager), vous devrez les mettre à jour (Voir dans com.jalios.jcms.member.csvimport : MemberImportProcess, MemberCsvImportHandler).

Exemple de code pour réaliser un import de membres :

import static com.jalios.jcms.member.csvimport.*;

MemberImportContext ctx = new MemberImportContext();
if (csvFile != null) {
  ctx.setCsvFilePath(csvFile.getAbsolutePath());
}
ctx.setGuestMode(isGuest);
ctx.setImportAuthorId(loggedMember.getId());
ctx.setSeparator(separator);
ctx.setDBMemberImport(useDbMembers);
ctx.setSendEmail(sendEmail);
ctx.setGroupIds(groupIds);
ctx.setUsage(usage);
ctx.setSimulation(isSimulation);
// Start process
BackgroundProcess process = new MemberImportProcess(ctx);
process.start(loggedMember);

Modifier isSimulation pour lancer la validation (true) ou l'import réel (false).

L'import se lance en tâche de fond. Il peut être suivi dans l'interface de suivi des traitements longs.