JPlatform 10 - Notes de migration

Cette page décrit la procédure de migration des sites et des modules pour être compatibles avec JPlatform 10.

1. Environnement Java et Java EE

1.1 Java 8 et serveurs d'applications

JPlatform 10 requiert l'utilisation de Java 8 (JCMS-5786). Si vous utilisez des certificats de sécurité, pensez à les reporter dans la nouvelle version.

Les versions des serveurs d'applications certifiés ont également évolué.
Procédez à la mise à jour de votre environnement applicatif.

1.2 web.xml

Reprenez les mises à jour du fichier web.xml fourni dans la webapp 10.

Notamment :

• JPlatform 10 requiert désormais un serveur d'application supportant la spécification Servlet 3.0 (cf JCMS-5580)
• JPlatform 10 utilise un nouveau ServletFilter : PluginAccessFilter

2. Modification de comportement

2.1 Configuration par défaut de C3P0

La configuration par défaut du pool de connexion C3P0 a été revue pour proposer des réglages plus en adéquation avec les installations standards de JPlatform 10.

Tous les réglages de C3P0 sont désormais fournis dans le fichier WEB-INF/data/custom.prop (Le fichier WEB-INF/classes/c3p0.properties ne contient plus de valeurs).

Reprenez les nouvelles valeurs par défaut de JPlatform 10. Pour cela, reprenez la section concernée du fichier custom.prop standard.
Si vous aviez personnalisé la configuration du pool, comparez vos valeurs avec les nouvelles valeurs fournies.

2.2 Portlet Requête Itération et types non sélectionnés pour la recherche

Le correctif JCMS-5753 modifie le comportement des Portlets Requête/Itération vis-à-vis des types décochés dans l'onglet "Recherche" des propriétés du site.

• Dans JPlatform 9 : les types décochés étaient exclus des résultat affichés par une PQF
• Dans JPlatform 10 : les types décochés sont inclus dans les résultats affichés par une PQF

Le comportement est configurable avec la propriété query.default.types-off.apply-to-pqf

2.3 Suppression des alertes

La propriété alert.trigger-deletion qui permettait d’empêcher la suppression des alertes n'est plus supportée.

2.4 Resources et propriétés pour Topbar

Dorénavant, pour surcharger la topbar, on peut soit :

• Surcharger la topbar pour toutes les zones du site (les zones étant Front, Admin et Work) via la propriété jcms.resource.topbar
• Surcharger indépendamment la resource topbar pour une zone dédiée via les propriétés suivantes (vides par défaut) :
  • jcms.resource.topbar.site
  • jcms.resource.topbar.admin
  • jcms.resource.topbar.work

Les clients ayant fait une surcharge de topbar devront adapter leur code pour utiliser cette nouvelle mécanique.
Les propriétés pour désactiver la topbar restent inchangées.

2.5 Ajax : plus de propagation automatique des paramètres

Les paramètres HTTP d'une requête (non Ajax) ne sont plus propagés aux requêtes Ajax effectuées par la suite.
Ce comportement était source de nombreux bugs, tous référencés en lien de l'issue JCMS-4951 qui décrit cette modification.

Cette modification ne devrait pas avoir d'incidence sur vos développements Ajax.
Dans le cas contraire, étudiez avec précision les paramètres qu'attend le JSP/handler invoqué en Ajax, et assurez-vous de les transmettre de façon explicite depuis les formulaires ou URLs.

2.6 [Sécurité] Algorithmes retirés pour les digests (mots de passe/cookie)

Pour des raisons de sécurité, suite à l'évolution JCMS-4769, tous les digests de sécurité utilisant l'algorithme Unix crypt ou MD5 sont désormais considérés comme invalides. Jalios n'utilise plus ces formats depuis JPlatform 7.1, diffusée en février 2012.
Cette modification concerne tous les digests de sécurité : hash de mots de passe stockés sur les Membres, tokens de sécurité utilisés pour les cookies ou les authkey.

La conséquence pour les utilisateurs n'ayant jamais mis à jour leur mot de passe depuis 2012 sera l'obligation de procéder à une réinitialisation du mot de passe.

2.7 [Sécurité] Cookie d'authentification renforcé

Pour des raisons de sécurité, suite à l'évolution JCMS-5813, tous les cookies d'authentification sont désormais soumis à des validations supplémentaires.
La conséquence est que les cookies précédemment émis sont considérés comme invalides.
Tous les utilisateurs (dont l'authentification a été mémorisée par un cookie) devront procéder à une nouvelle authentification lors de leur premier accès à la plateforme, après migration à JPlatform 10.

2.8 Codes de retour HTTP 401 et 403

2 évolutions modifient les codes de retour HTTP envoyés aux clients HTTP "type ligne de commande" (pas depuis les navigateurs donc) :

• JCMS-5942 : Lorsqu'une page nécéssite des autorisations/habilitations spéciales, le code de retour 403 forbidden est envoyé directement (au lieu d'une redirection vers la page de login avec message "Forbidden") 
• JCMS-5648 : Lorsque le site est privé (eg : nécessite une authentification) et qu'un client sans authentification tente d'y accéder, un code de retour 401 "Unauthorized" est envoyé directement (au lieu d'une redirection vers la page de login avec message "Forbidden")

  Dans le détail : 

1. Quand un client HTTP envoie le header Accept: text/html, c'est un navigateur capable de récupérer du HTML et de l'afficher, le comportement existant n'est pas changé, et une redirection vers une page HTML a lieu.
2. Quand un client HTTP n'envoie pas ce header, c'est généralement un client HTTP programmatique, type ligne de commande, API REST, outil de supervision, etc. 

Pour ces clients HTTP "techniques", il est plus utile (pour eux) de renvoyer directement un code d'erreur 401/403. Il s'agit en effet de codes techniques standardisés, facilement interprétables par ces clients (ce qui n'est pas le cas d'une page HTML "forbidden ou login", dont l'unique but est de fournir une expérience utilisateur convenable quand il y a un humain derrière le client, cad quand il s'agit d'un navigateur Web).

Vérifiez le comportement de vos sondes/scripts de monitoring et autres clients externes.

2.9 Changement dans la politique de droits d'un espace collaboratif

Pour gérer l'évolution un changement notable a été apporté aux publications des espaces collaboratifs : toute publication qui a un parent (eg Commentaire, FAQ Entry, Glossary Entry, une opportunité) a comme droit celui de son parent.

2.10 [Sécurité] Wysiwyg : nettoyage renforcé des attributs HTML

Afin d'assurer une sécurité accrue sur l'utilisation des champs Wysiwyg, un nettoyage accru des balises HTML est effectué en standard dans JPlatform 10 (évolution JCMS-6170). 

Chaque attribut HTML bénéficie d'une règle de nettoyage spécifique, configurée dans les propriétés JCMS, et dans laquelle est configuré au moins un des éléments ci-dessous : 

• une liste blanche de valeurs autorisées (préfixe .whitelist dans les propriétés).
• une expression régulière permettant d'identifier des valeurs autorisées (préfixe .whitelist-regex).
• une liste noire de valeurs interdites (préfixe .blacklist).
• une expression régulière permettant d'identifier les valeurs interdites (préfixe .blacklist-regex).

Le éléments identifiés en liste blanche sont prioritaires sur les éléments en liste noire (un élément présent dans les 2 listes sera donc autorisé).
Une configuration supplémentaire permet de déterminer le comportement par défaut à appliquer pour les valeurs identifiées ni en liste blanche, ni en liste noire (préfixe .default-behavior dans les propriétés).
Dans tous les cas, les valeurs non autorisées sont supprimées à l'enregistrement.

JPlatform 10 applique en standard un nettoyage sur les 3 attributs suivants :

• id : l'utilisation de certains identifiants réservés à l'applicatif est désormais interdite. Afin d'assurer la plus grande compatibilité possible avec les contenus existants, le comportement par défaut de ce nettoyage est de conserver les balises inconnues, non explicitement mises en liste noire ou en liste blanche.
• class : l'utilisation de certaines classes internes à JPlatform est désormais interdite. Pour garantir l'absence de régression sur vos contenus existants, cette régle de nettoyage fonctionne comme la précédente : les valeurs non explicitement exclues sont conservées.
• style : contrairement aux deux précédentes règles, le nettoyage des styles est plus complet : seules les propriétés CSS explicitement présentes dans la liste blanche sont autorisées. Toutes les autres propriétés CSS non référencées sont supprimées à l'enregistrement.

Si vous autorisiez vos contributeurs à saisir des identifiants, classes ou styles avancés : 

• Consultez les configurations des règles, via les propriétés suivantes du fichier jcms.prop :
  
  • wysiwyg.sanitize-html.attributes
  • wysiwyg.sanitize-html.inline-styles
• Assurez-vous que ces configurations sont compatibles avec vos usages en terme de contribution. Dans le cas contraire, vous pouvez personnaliser les règles dans le fichier custom.prop ou plugin.prop de votre module de site : 
  • Enrichissez les règles, en ajoutant ou retirant des éléments en liste blanche.
  • En dernier recours, désactivez chacune des règles, avec les propriétés suivantes :
    • wysiwyg.sanitize-html.attributes.id.enabled: false
    • wysiwyg.sanitize-html.attributes.class.enabled: false
    • wysiwyg.sanitize-html.inline-styles.default.enabled: false
• Vous pouvez également désactiver les règles fournies en standard, et créer des règles de liste blanche plus strictes.

2.11 Editeur de texte riche : abandon des styles globaux et d'espace

JCMS 9 incluait une fonctionnalité qui permettait aux intégrateurs/développeurs, de proposer dans l'éditeur wysiwyg des classes spécifiques par espace de travail. Mécanique parfois connue sous le nom "style globaux/locaux".

En synthèse, cette mécanique fonctionnait de la façon suivante :

• un fichier de css, wysiwyg.css (respectant un formatage bien spécifique), peut être modifié par les intégrateurs ;
• il est parsé au démarrage de JCMS pour en extraire une liste de styles "globaux et locaux" ;
• cette liste peut être modifiée via une WysiwygPolicyFilter ;
• chaque espace de travail peut ensuite être édité pour sélectionner les styles qui seront proposés dans l'éditeur ;
• l'éditeur wysiwyg (dans sa configuration la plus avancée) propose 2 menus de sélection avec ces styles.

Tout cela est décrit dans l'article suivant : https://community.jalios.com/jcms/jc_87257/fr/definir-des-styles-css-pour-l-editeur-wysiwyg

Lors de la conception de l'éditeur texte riche de JPlatform 10, cette mécanique nous est apparue comme trop complexe et superflue :

• il est préférable de proposer des classes sémantiques, communes à tout le site, quitte à ce que des feuilles de styles propres à chaque espace de travail en personnalisent le rendu ;
• l'éditeur wysiwyg de JPlatform 10 est configurable de façon très aisée et modulaire, et permet donc de personnaliser rapidement les styles qui peuvent y être proposés.

JPlatform 10 abandonne ainsi définitivement cette mécanique des styles globaux et des styles d'espace. JCMS-6052 

3. Modification d'API et de librairies

3.1 Librairies externes mises à jour ou supprimées

Les librairies externes suivantes ont été mises à jour :

• Apache Derby 10.13.1.1 -- JCMS-6132
• Apache Lucene 6.4.2 -- JCMS-5562
• Apache PDFBox 2.0.7 -- JCMS-3672
• JSoup 1.9.2 -- JCMS-5563
• OWASP ESAPI supprimé, OWASP Encoder 1.2.1 ajouté -- JCMS-5568
• Jaxen 1.1.6
• Log4j 1.2.17
• slf4j 1.7.22
• commons-codec 1.10
• commons-collections 3.2.2 -- JCMS-5801
• commons-logging 1.2 -- JCMS-5801 + JCMS-3672
• commons-fileupload 1.3.3
• commons-httpclient 3.1
• commons-io 2.5
• yuicompressor (build custom) -- JCMS-5517
• Xalan Serializer 2.7.2
• UnboundID LDAP SDK 3.2.1

Les librairies externes suivantes ont été supprimées :

• acme -- JCMS-6171
• JFreeChart et JCommon -- JCMS-6081

Plusieurs modules livrés avec JPlatform 10 ont également mis à jour les librairies qu'ils utilisent, notamment : 

• Module d'Indexation des documents (Document Indexer Plugin) :
  • Apache POI -- DOCIDX-8
  • Text-Mining Extractor
• Module d'Authentification Windows (Waffle Plugin) : 
  • Waffle -- WAFFLE-23
• Module SAML
  • OpenSAML -- SAML-11
• ...

Si vous les utilisez dans le cadre de développement(s) spécifique(s), vous devrez migrer ces développements vers les nouvelles versions.
Consultez les documentations respectives de ces librairies pour les procédures de migration destinées aux développeurs.

3.2 Mise à jour de jquery et jquery-ui

JCMS-5501 - Passage de jquery 1.11.1 à jquery 3.2.1.

De nombreuses fonctions sont maintenant dépréciées. Les APIs obsolètes restent fonctionnelles grâce au plugin jquery-migrate, mais des warnings peuvent apparaître dans la console développeur des navigateurs.

jQuery fournit un "upgrade guide" pour vous aider dans votre migration : https://jquery.com/upgrade-guide/3.0/

JCMS-5540 - Passage de jquery-ui 1.10.4 à jquery-ui 1.12.1.

Procédures de migration disponibles dans la page suivante : https://jqueryui.com/upgrade-guide/1.12/
Les fonctions supprimées ou dépréciées sont maintenues grâce à la présence de jquery-migrate.

3.3 Mise à jour de librairies de Glyph Fonts

JCMS-6129 - Glyphicons a été mis à jour, certaines icônes ont changé de nom.
Procédez à une mise à jour des icônes suivantes en utilisant leurs nouveaux noms (extrait du changelog de Glyphicons) : 

------------
Renamed icons:

souncloud -> soundcloud (in Social set)
hotspot -> paired (in basic set)
airplane -> plane (in basic set)
bed -> bed-alt (in basic set)
bed-alt -> bed (in basic set)
remove-2 -> remove (in basic set)
remove -> remove-circle (in basic set)
ok -> ok-circle (in basic set)
ok-2 -> ok (in basic set)
circle-remove -> remove-sign (in basic set)
circle-plus -> plus-sign (in basic set)
circle-minus -> minus-sign (in basic set)
circle-ok -> ok-sign (in basic set)
circle-question-mark -> question-sign (in basic set)
circle-info -> info-sign (in basic set)
circle-exclamation-mark -> exclamation-sign (in basic set)
ban -> ban-circle (in basic set)
google-maps -> map-marker (in basic set)
left-arrow -> arrow-left(in basic set)
right-arrow -> arrow-right(in basic set)
down-arrow -> arrow-down (in basic set)
up-arrow -> arrow-up(in basic set)
ruller -> ruler (in basic set)
paragraph -> paragraph-alt (in basic set)
note -> music-alt (in basic set)
mosquito-net -> mosquito (in basic set)

glyph-lock -> lock (in Halflings set, only change of CSS class)
glyph-bookmark -> bookmark (in Halflings set, only change of CSS class)
glyph-camera -> camera (in Halflings set, only change of CSS class)
glyph-fire -> fire (in Halflings set, only change of CSS class)
glyph-calendar -> calendar (in Halflings set, only change of CSS class)
glyph-bell -> bell (in Halflings set, only change of CSS class)
glyph-wrench -> wrench (in Halflings set, only change of CSS class)
glyph-briefcase -> briefcase (in Halflings set, only change of CSS class)
glyph-paperclip -> paperclip (in Halflings set, only change of CSS class)
glyph-pushpin -> pushpin (in Halflings set, only change of CSS class)

(To explain changes above: it may seems crazy to rename such an amount of icons, but I had to sync these names between Basic and Halflings set - my apology, I should have done this long time before. On top of that, I've found a better way how to optimize certain icon names for older browsers inside the font file itself, so these tweaks with names are no longer necessary)

JCMS-6130 - Icomoon a été mis à jour avec de nouvelles images. Certaines images ont été supprimées, d'autres ajoutées.

• Icones supprimées :

  icomoon-apple2
  icomoon-chess-rock
  icomoon-coffee-baen
  icomoon-deviantart2
  icomoon-dribbble2
  icomoon-dribbble3
  icomoon-facebook3
  icomoon-feed2
  icomoon-feed3
  icomoon-feed4
  icomoon-forrst
  icomoon-forrst2
  icomoon-github2
  icomoon-github3
  icomoon-github4
  icomoon-github5
  icomoon-html5
  icomoon-html52
  icomoon-paypal2
  icomoon-paypal3
  icomoon-picassa
  icomoon-picassa2
  icomoon-twitter2
  icomoon-twitter3
  icomoon-vimeo3
  icomoon-wordpress2
  icomoon-youtube3
  icomoon-youtube4 

• Icones ajoutées :

  icomoon-500px
  icomoon-amazon
  icomoon-appleinc
  icomoon-basecamp
  icomoon-behance
  icomoon-behance2
  icomoon-calendar-day
  icomoon-calendar-empty
  icomoon-calendar-week
  icomoon-chess-rook
  icomoon-coffee-bean
  icomoon-edge
  icomoon-google2
  icomoon-google3
  icomoon-hackernews
  icomoon-hangouts
  icomoon-html-five
  icomoon-html-five2
  icomoon-npm
  icomoon-renren
  icomoon-rss
  icomoon-rss2
  icomoon-sina-weibo
  icomoon-spotify
  icomoon-telegram
  icomoon-trello
  icomoon-vine
  icomoon-vk
  icomoon-whatsapp
  icomoon-wikipedia
  icomoon-yahoo2

3.4 Mise à jour des templates d'alertes web

Issue correspondante : JCMS-5978

Si vous aviez surchargé la jsp d'alerte web pour vos propres alertes, vous devez mettre à jour votre jsp, et utiliser le code suivant :

<%@ include file='/jcore/alert/web/doInitWebAlert.jspf' %>
<div data-jalios-alert-id="<%= alert.getId() %>" class="<%= alertCss %>">   
  <%@ include file='/jcore/alert/web/doWebAlertHeader.jspf' %>  
  <%@ include file='/jcore/alert/web/doWebAlertBody.jspf' %>   
  <%@ include file='/jcore/alert/web/doWebAlertFooter.jspf' %>   
</div>  

<%@ include file='/jcore/alert/web/doInitWebAlert.jspf' %> 
<div data-jalios-alert-id="<%= alert.getId() %>" class="<%= alertCss %>"> 
  <%@ include file='/jcore/alert/web/doWebAlertHeader.jspf' %>
  <%@ include file='/jcore/alert/web/doWebAlertBody.jspf' %> 
  <%@ include file='/jcore/alert/web/doWebAlertFooter.jspf' %> 
</div>

Cette modification a été faite pour éviter d'avoir des jspf qui ouvrent une balise, et une autre jspf qui la ferme. Par ailleurs le rendu a aussi été changé pour pouvoir définir si on veut afficher le résumé de l'alerte.

3.5 Field/Control

Dans JPlatform 9
Si on n'indiquait pas de type sur le tag <jalios:control> ça rattrapait de la manière suivante :

• Si le tag <jalios:field> déclarait un FormHandler (celui généré pour un type), le contrôle était automatiquement résolu, c'est-à-dire que le type de contrôle, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... était résolu à partir du TypeFieldEntry associé.

<jalios:field name="myField" formHandler="<%= formHandler %>">
  <jalios:control />  
</jalios:field>  

• Si le tag <jalios:field> NE déclarait PAS de FormHandler, le contrôle rattrapait par défaut sur le type TEXTFIELD.

<jalios:field name="myField" value="<%= myValue %>>  
  <jalios:control />  
</jalios:field>  

Dans JPlatform 10
Si on n'indique pas de type sur le tag <jalios:control> ça rattrape de la manière suivante :

• Si le tag <jalios:field> déclare un FormHandler (celui généré pour un type), le contrôle est automatiquement résolu, c'est-à-dire que le type de contrôle, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... est résolu à partir du TypeFieldEntry associé.
  • (Cela est identique au comportement présent dans JPlatform 9)

<jalios:field name="myField" formHandler="<%= formHandler %>">
  <jalios:control />
</jalios:field>  

• Si le tag <jalios:field> NE déclare PAS de FormHandler, le contrôle NE rattrape PLUS sur le type TEXTFIELD.

Il est donc obligatoire de déclarer l'attribut "type" ou "settings" pour afficher correctement le contrôle.

<jalios:field name="myField" value="<%= myValue %>>
   <jalios:control type="<%= ControlType.TEXTFIELD %>" />  
</jalios:field>  

3.6 Wiki / Wysiwyg

3.6.1 Changement de package

Plusieurs APIs ont été déplacées dans des packages dédiés.
Procédez à la mise à jour des imports et signatures des méthodes dans vos développements (notamment WikiPolicyFilter et WysiwygPolicyFilter ).

• com.jalios.jcms.wiki. Pour le wiki, des classes assurant une compatibilité partielle sont toujours présentes dans les anciens packages :
  • com.jalios.jcms.WikiRenderingHints -> com.jalios.jcms.wiki.WikiRenderingHints
  • com.jalios.jcms.WikiRenderer -> com.jalios.jcms.wiki.WikiRenderer
• com.jalios.jcms.wysiwyg.
  • com.jalios.jcms.WysiwygManager -> =com.jalios.jcms.wysiwyg.WysiwygManager
  • com.jalios.jcms.WysiwygMediasRewriter -> com.jalios.jcms.wysiwyg.WysiwygMediasRewriter
  • com.jalios.jcms.WysiwygRendererr -> com.jalios.jcms.wysiwyg.WysiwygRenderer

3.6.2 Migration vers le wysiwyg

JPlatform 10 introduit l'usage exclusif de l'éditeur de texte riche, en lieu et place des champs wiki.
Si vous aviez développé des WikiPolicyFilter pour introduire des syntaxes personnalisées :

• A l'affichage des anciens champs wiki : un rendu wiki doit toujours être assuré. Hormis les signatures de package évoquées ci-dessus, aucun changement de votre WikiPolicyFilter n'est nécessaire.
• A l'édition des anciens champs wiki : une conversion automatique du texte wiki en HTML a lieu. Votre WikiPolicyFilter est également invoqué à ce moment, ce que vous pouvez déterminer via WikiRenderingHints.isWiki2JHTML. Adaptez éventuellement votre policy pour générer un HTML spécifique.

Pour vos nouveaux développements, les APIs wiki sont dépréciées et le Wysiwyg doit être utilisé :

• Côté éditeur : Développement de plugins TinyMCE (en remplacement des WikiPolicyFilter.handleWikiToolbar permettant la modification des barres d'outil de l'éditeur wiki)
• Côté rendu : Développement de WysiwygPolicyFilter pour adapter le HTML si besoin.

3.6.3 Modification du DOM généré

Le DOM généré pour le rendu des textes wiki et JHTML a été modifié par rapport à celui des versions précédentes.
Si vous aviez personnalisé des feuilles de style avec vos propres CSS, vous devrez les modifier.

Voici les changements notables. Ils concernent principalement le rendu des fonctionnalités disponibles auparavant via le plugin Wiki (pour les WikiPage), qui sont désormais proposés par le coeur : 

Résumé  (tag wiki [jalios:abstract], tag JHTML <jalios:abstract/>) :

• rendu JPlatform 9 : <p class="abstract">...</p>
• rendu JPlatform 10 : <div class="abstract">...</div>

Table de matières et identifiant sur en-tête :

• rendu JPlatform 9 :  via des table/tr/td et ul/li,  
• rendu JPlatform 10 : via les balises sémantiques nav, h1 et ul/li

3.7 Publication en base : signature des setter de champs primitifs monovalués

Dans le cadre de l'issue JCMS-5940, les setters des champs primitifs monovalués des publications en base ont changé. Il reçoivent désormais un type de wrapping au lieu du type primitif.
Exemple, sur le type DBMailMessage, le setter du champ priorité :

• Avant : setPriority(int)
• Après : setPriority(Integer)

Grâce à l'autoboxing, c'est transparent mais moins souple qu'avec les types primitifs. Un setter primitif de type double accepte aussi bien un double, un long ou un int. Ce n'est pas le cas avec le type de wrapping Double. Il faut impérativement lui fournir une valeur de type double ou Double. Ainsi, l'appel au setter suivant ne compile plus :

jlearnResource.setDuration(240);

il faut désormais écrire :

jlearnResource.setDuration(240L);

Si cette évolution devrait avoir peu d'impact sur le code spécifique durant les migrations, elle peut avoir un impact sur les performances lors des premiers démarrages après la migration. Si un type de données (coeur ou module) est livré dans sa nouvelle version avec un nouveau champ primitif, toutes les anciennes instances vont être ré-enregistrés dès qu'elles seront chargées (au moment du commit de la transaction).

3.8 FriendlyURLSet pour les DB Content

Les types DB Content peuvent désormais définir des URLs intuitives (aka FriendlyURL), à l'instar des contenus du Store.
Ceci a nécessité l'ajout d'une déclaration de la collection friendlyURLSet dans les fichier HBM. Ceci est pris en charge par le générateur de type.
Il n'y a pas de migration particulière à prévoir sur les types de données de Jalios.

Si vous avez développé des DB Content spécifiques à votre site avec un fichier HBM personnalisé, modifiez le fichier HBM pour ajouter la déclaration suivante :

<!--  COLLECTIONS FOR FRIENDLYURL -->
<set name="friendlyURLSet" table="G_MYCUSTOMDEBTYPE_FURLSET" lazy="true">
  <cache usage="read-write" />  
  <key>
    <column name="ITEM_ID" index="IG_MYDEBTYPE_FURLSET_I"></column>
  </key>  
  <element type="string">
    <column name="VALUE"/>  
  </element>
</set>     

Si ce n'est pas fait, le message suivant apparaîtra lors du démarrage de JPlatform :

The friendlyURLSet collection is not declared in mapping file (HBM) for class MYDEBTYPE. This HBM should be updated to add this new collection.

Issue JCMS-5941.

3.9 Form Handler / Edit Handler : setters de champ texte (mono/multivalué, mono/multilingue)

Les APIs utilisées dans les setters des EditHandler ont étés revues.

• Afin de simplifier leur usage ;
• Afin de garantir le traitement approprié des valeurs textuelles reçues de l'utilisateur (encodage ou nettoyage selon le type de champ concerné) ;
• Notamment pour la gestion des valeurs wiki et wysiwyg.

Les APIs suivantes de la classe com.jalios.jcms.handler.JcmsFormHandler sont dépréciées :

• protected String getMainLangValue(String[] array, boolean trim, boolean escape)
• protected HashMap<String,String> getMLMap(String[] array, boolean trim, boolean escape)
• protected String[] getMainLangValueArray(String[] array, boolean trim, boolean escape)
• protected HashMap<String,String[]> getMLMapArray(String[] array, boolean trim, boolean escape)

Elles sont remplacées par les méthodes suivantes :

• protected static String getMonolingualValue(TypeFieldEntry tfe, String[] array)
• protected static String[] getMonolingualValueArray(TypeFieldEntry tfe, String[] array)
• protected static String getMultilingualMainValue(TypeFieldEntry tfe, String[] array)
• protected static HashMap<String,String> getMultilingualMLMap(TypeFieldEntry tfe, String[] array)
• protected static String[] getMultilingualMainValueArray(TypeFieldEntry tfe, String[] array)
• protected static HashMap<String,String[]> getMultilingualMLMapArray(TypeFieldEntry tfe, String[] array)

Pour une gestion correcte des champs wiki et wysiwyg, vous devez impérativement migrer vos handler spécifiques pour utiliser les nouvelles APIs.
Utilisez le tableau de correspondances ci-dessous, et consultez la Javadoc de ces méthodes pour des exemples et plus d'informations.

Dans JPlatform 9

Dans JPlatform 10

3.10 Form Handler : méthode validate "final"

La méthode com.jalios.jcms.handler.JcmsFormHandler.validate() est désormais final.

Si vous aviez développé des handler personnalisés dérivant de la classe JcmsFormHandler (ou de l'une de ses sous-classes), et que vous aviez surchargé la méthode JcmsFormHandler.validate(), vous devez maintenant surcharger - à la place de cette dernière - la méthode JcmsFormHandler.processAction() (le code lui-même de votre méthode ne nécessite aucune adaptation).

Issue JCMS-6004.

3.11 Évolution de MenuInfo et MenuInfoFilter

Les classes MenuInfo et MenuInfoFilter (aidant à réaliser des menus de navigation) ont évolué. Elles n'utilisent plus de type générique.
Recherchez l'utilisation de ces classes dans vos JSPs et/ou classes Java, et remplacez par exemple MenuInfo<Category> et MenuInfoFilter<Category> respectivement par MenuInfo et MenuInfoFilter tout court.

4. Configuration et Données

4.1 Index lucene

• Supprimez le répertoire WEB-INF/data/lucene. Sans cette étape, vous observerez l'erreur suivante au démarrage :

org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource BufferedChecksumIndexInput(MMapIndexInput(path="C:\....\WEB-INF\data\lucene\PublicationsIndices\en\segments_vb"))): -9 (needs to be between 1071082519 and 1071082519). This version of Lucene only supports indexes created with release 5.0 and later.
 at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:295)
 at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:284)
 at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:910)
 at com.jalios.jcms.search.LuceneDataSearchEngine.<init>(LuceneDataSearchEngine.java:210)
 at com.jalios.jcms.search.LucenePublicationSearchEngine.<init>(LucenePublicationSearchEngine.java:178)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
 at java.lang.Class.newInstance(Class.java:442)
 at com.jalios.jcms.QueryManager.initEngine(QueryManager.java:107)
 at com.jalios.jcms.QueryManager.<init>(QueryManager.java:79)
 at com.jalios.jcms.QueryManager.getQueryManager(QueryManager.java:67)

• Démarrez

Une réindexation complète aura lieu au démarrage (en application de l'évolution JCMS-1612 introduite dans JPlatform 6.1).

Si vous ne le souhaitez pas et préférez faire une réindexation manuelle, changez la propriété suivante :

search-engine.auto-indexing-on-first-startup:false

puis lancez l'indexation depuis l'interface d'administration.

4.2 Portail des Applications

Pour bénéficier du portail des applications (portail utilisé par défaut pour l'affichage d'une application), il faut ajouter la déclaration de ce portail dans les propriétés (channel.app-portal).

Dans une application JPlatform 10 vierge, un portail des applications par défaut est proposé (j_231).

Vous pouvez le reprendre et éventuellement l'adapter lors d'une migration. Vous pouvez aussi en définir un nouveau et le déclarer dans l'éditeur de propriétés. Ce portail doit avoir la classe CSS jaliosAppPortal.

Pour bénéficier du portail des applications par défaut, ajoutez les lignes suivantes dans le store.xml (positionnez-les correctement selon leurs stamps respectifs) :

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- |||||||||||||||||||||| App Portal ||||||||||||||||| -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<generated.PortletColumn stamp="j_230" id="j_230" op="create" abilities="" adate="" alignH="center" alignHorizontal="" alignTable=" " alignV="middle" alignVertical="" author="j_2" authorDBID="" authorizedGroupSet="" authorizedMemberSet="" backColor="" backImage="" backgroundColor="" backgroundImage="" backgroundRepeat="" behaviorCopy="true" border="0" borderColor="" cacheSensibility="None" cacheType="None" categories="" cdate="1495373583125" cellPadding="0" children="@|j_205" childrenBindings="" colSpacing="0" condition="@|None" cssClasses="" cssId="" dbFriendlyURLSet="" description="" descriptionML="%|java.lang.String/fr=java.lang.String/" displayCSS="" edate="" extension="" extraDataMap="" friendlyURLSet="" importMap="" insetBottom="0" insetLeft="0" insetRight="0" insetTop="0" invalidClass="" invalidTime="60" isTracked="false" mainInstance="" mainLanguage="en" majorVersion="1" mdate="1495373583125" mergeDate="" mergeId="" opAuthor="j_2" opDelegate="" originalPortlet="" pdate="" portletImage="" portletImageML="" pstatus="0" roleMap="" sdate="" templates="@|box.default|query.default" title="App Portal - Main Column" titleML="%|java.lang.String/fr=java.lang.String/Portail App - Colonne Principale|java.lang.String/en=java.lang.String/App Portal - Main Column" udate="1495373583125" updateGroupSet="" updateMemberSet="" width="100" workflowId="" workspace="j_4" />
<generated.PortletPortal stamp="j_231" id="j_231" op="create" abilities="" adate="" author="j_2" authorDBID="" authorizedGroupSet="" authorizedMemberSet="" behaviorCopy="true" cacheSensibility="None" cacheType="None" categories="@|j_5" cdate="1495373583131" child="j_230" cssClasses="jaliosAppPortal" cssFile="css/portal/jalios.css" cssId="" dbFriendlyURLSet="" description="The HomePage Portal of the JCMS Channel" descriptionML="%|java.lang.String/fr=java.lang.String/Portail Page d&apos;Accueil du canal JCMS" edate="" exactCategory="false" extension="" extraDataMap="" friendlyURLSet="" importMap="" invalidClass="" invalidTime="60" isTracked="false" mainInstance="" mainLanguage="en" majorVersion="1" mdate="1495373583131" mergeDate="" mergeId="" opAuthor="j_2" opDelegate="" pageTitle="" pageTitleML="" pdate="" portletImage="" portletImageML="" pstatus="0" roleMap="" sdate="" templates="@|box.default|query.default" title="App Portal" titleML="%|java.lang.String/fr=java.lang.String/Portail Application|java.lang.String/en=java.lang.String/App Portal" udate="1495373583131" updateGroupSet="" updateMemberSet="" workflowId="" workspace="j_4" />  

Issue : JCMS-5979

4.3 Type Média

Le type Média est par défaut le nouveau type destiné à accueillir les fichiers de type Image, Vidéo et Audio déposés sur la plateforme.

Bien que ce ne soit pas obligatoire, il est recommandé de :

1. Activer ce type (ou un autre type destiné à ces types de fichier) dans TOUS les espaces dans lesquels ces types de fichiers peuvent être déposés ;
2. Donner les droits de contribution sur ce type à l'ensemble des contributeurs qui ont le droit sur le type FileDocument ou l'un de ses sous-types.

4.4 Sélection automatique du type de documents

Des nouvelles propriétés permettent de sélectionner automatiquement un type de document en fonction du Mime Type de son fichier (et des droits de l'utilisateur qui fait le dépôt).

En standard ces propriétés sont définies ainsi :

file-document.upload.class.image: generated.Media
file-document.upload.class.video: generated.Media
file-document.upload.class.audio: generated.Media

Une propriété permet aussi de sélectionner un type de document par défaut. En standard cette propriété est définie ainsi :

file-document.upload.class.default: com.jalios.jcms.DBFileDocument

Il est recommandé de reporter ces propriétés standards dans le custom.prop de la plateforme.

4.5 Add-pack : limite sur les invités

JPlatform 10 contrôle le nombre d'invités (issue JCMS-5924)

C'est une nouvelle dimension disponible sur les add-packs. Si la dimension n'est pas renseignée, la limite est à 3 invités.
En conséquence, les dimensions "Member" et "DBMember" ignorent désormais les comptes invités.
Donc pour un site n'ayant que 3 ou moins invités, les anciens add-packs sont corrects. Si le site a 3 ou plus invités, il est nécessaire d'obtenir un nouvel add-pack avec la dimension "Nombre d'invités" renseignée correctement.

4.6 Alerte : dénormalisation du champ Workspace

Une colonne WORKSPACE_ID a été ajoutée à la table J_ALERT. Pour toutes les alertes ayant une Data de type Publication (donc un workspace), il faut mettre à jour le workspace de l'alerte.
Appelez la JSP suivante en tant qu'administrateur : http://localhost:8080/jcms/jcore/alert/updateAlertWorkspace.jsp.

Les alertes mises à jour seront loguées dans la console.

4.7 Recommandation : dénormalisation du champ Workspace

Une colonne WORKSPACE_ID a été ajoutée à la table J_RECOMMENDATION. Pour toutes les recommandations ayant une Data de type Publication (donc un workspace), il faut mettre à jour le workspace de la recommendation.
Appelez la JSP suivante en tant qu'administrateur : http://localhost:8080/jcms/jcore/alert/updateRecommendationWorkspace.jsp.

Les recommendations mises à jour seront loguées dans la console.

4.8 Modification du processus de stockage des données Analytics

JCMS-6082 apporte la possibilité de choisir un système de stockage des données Analytics (EventData).

Plusieurs stockages sont possibles, mais un seul pourra être utilisé pour effectuer les analyses.

Les stockages sont à configurer via des propriétés ayant le prefixe jcms.analytics.storage-handler..

Exemple de configuration :

jcms.analytics.storage-handler.1.classname: com.jalios.jcms.analytics.storage.impl.FileSystemStorage
jcms.analytics.storage-handler.1.directory: $DATA_DIR/analytics
jcms.analytics.storage-handler.1.isAnalysisProvider:true

Note : il s'agit de la configuration par défaut, si aucune propriété n'existe avec le préfixe indiqué ci-dessus. 

Aucune modification du custom.prop n'est nécessaire pour assurer la compatibilité ascendante. Toutefois vous pouvez reprendre le paramétrage désormais fourni dans le fichier custom.prop livré par défaut.

5. Modules

5.1 Module DBComment

DBCP-154 - Renommage de la classe .comment en .dbcomment sur la vue desktop des commentaires, pour éviter un conflit avec le SyntaxHighlighterPlugin.

5.2 Module Blog

Passage du type BlogPost en Content (issue BLOG-176).

Ce changement implique que les utilisateurs, pour pouvoir publier des billets de Blog, devront faire partie d'un groupe qui peut publier ce type de contenu dans l'espace concerné.

Auparavant, le type BlogPost était un UserContent ; la simple appartenance à l'espace suffisait donc pour pouvoir publier des billets. 

Il existait cependant des règles permettant de limiter ce droit, via le groupe bloggers défini sur le Blog. On vérifiait aussi que le membre appartenait aux "Workers" de l'espace.

5.3 Module Organigramme

5.3.1 Relâchement des dépendances

Plusieurs modules ont besoin d'accéder à la structure de l'organisation (département, responsable, équipe, ...) Jusqu'à présent, ces notions étaient fournies par le Module Organigramme (FlowChart).

Toute cette gestion a été introduite dans le coeur de JPlatform 10, voir  JPlatform 10 - API de gestion de l'organisation et des responsables de département.

Le Module Organigramme n'assure donc plus que son rôle de rendu graphique de la structure de l'organisation.

Aussi les modules tels que JLearn ou VacationRequest, dans leurs versions spécifiques à JPlatform 10, n'auront plus besoin de la présence du Module Organigramme pour fonctionner.

5.3.2 Migration

Dans le fichier custom.prop, la propriété jcmsplugin.flowchart.root.id pouvait désigner soit un groupe, soit une catégorie.

Le groupe doit désormais être déclaré par la propriété $channel.organization-root-group, qui est éditable dans le gestionnaire des propriétés du site (onglet Utilisateurs).

Si vous utilisiez une catégorie, elle doit désormais être déclarée par la propriété jcmsplugin.flowchart.root-cat.id, éditable dans les propriétés du module.

Les données du Module Organigramme (ExtraData/ExtraDBData) présentes sur les membres et les groupes sont automatiquement migrées (en "lazy" lors des ré-enregistrements des objets).

6. UI

6.1 Réécriture du menu Topbar admin

Ce menu a été réécrit en "slide menu".

Si vous vous branchiez via l'une des targets suivantes : SITE_TOPBAR_ADMIN_MENU, WORK_TOPBAR_ADMIN_MENU, ADMIN_TOPBAR_ADMIN_MENU, vérifiez et adaptez au besoin votre rendu.