JPlatform 10 - Notes de migration

Cette page décrit la procédure de migration des sites et des modules pour être compatible 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ées.
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 standard 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 Requete Itération et types désactivés

Le correctif JCMS-5753 modifie le comportement des portlet requêtes itération par rapport aux types désactivés dans l'onglet recherche des propriétés.

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

Le comportement est configurables 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’empercher la suppression des alertes n'est plus supportée.

2.4 Resource 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 automatiques des paramètres

Les paramètres HTTP d'une requete (non ajax) ne sont plus propagées aux requêtes Ajax effectuées par la suite.
Ce comportement était source de nombreux bug, 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écisions les paramètres que vous attendez le JSP/handler invoqué en Ajax, et assurez vous de les transmettre de façon explicite depuis les formulaire 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 digest de sécurité : hash de mots de passe stockés sur les Membres, token de sécurité utilisés pour les cookie 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édement é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 Code de retours HTTP 401 et 403

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

• 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 envoi 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'envoi 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 interpretable par ces client. (Ce qui n'est pas le cas d'une page HTML "fordibden ou login" dont l'unique but est de fournir une expérience utilisateur convernable 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/script 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. Toutes publications qui a un parent (eg Commentaire, FAQ Entry, Glossary Entry, un opportunité) a comme droit le droit de son parents.

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 prioritaire sur éléments en liste noire (Eg: un élément présent dans les 2 listes sera 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 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 interdit. Afin d'assurer la plus grande compatibilité possible avec les contenus existant, le comportement par défaut de ce nettoyage est de conserver les balises inconnus, non explicitement mis en liste noir ou en liste blanche.
• class : l'utilisation de certaines classes interne à JPlatform est désormais interdit. Pour garantir l'absence de régression sur vos contenus existant, cette régle de nettoyage fonctionne comme la précédente; les valeurs non explicitement exclues sont conservées.
• style : Contrairement au 2 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ées : 

• consultez les configurations des règles, via les propriétés suivant 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 : 
  • Enrichisez 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 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 connus 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 formattage bien spécifique) peut être modifié par les intégrateurs,
• il parsé au démarrage de JCMS pour en extraite une liste de style "globaux et locaux"
• cette liste peut être modifié via une WysiwygPolicyFilter
• chaque espace de travail peut ensuite être éditer pour sélectionner les styles qui seront proposée dans l'éditeur.
• l'éditeur wysiwyg (dans sa configuration la plus avancée) propose 2 menus de sélections 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 propre à chaque workspace en personnalise le rendu
• l'éditeur wysiwyg de JPlatform 10 est configurable de façon très aisé et modulaire, et donc permet de personnaliser rapidement les styles qui peuvent y être proposés

JPlatform 10 abandonne définitivement cette mécanique des styles globaux et style de workspace. JCMS-6052 

3. Modification d'API et de librairies

3.1 Librairies externes mises à jours 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 warning 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 disponible sur 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 : https://issues.jalios.com/browse/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>

Cet update a été fait 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 l'abstract 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, dans ce cas, le control était automatiquement résolu, c'est-à-dire que le type de control, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... est résolu à partir du TypeFieldEntry associé.

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

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

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

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

<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, dans ce cas, le control est automatiquement résolu, c'est-à-dire que le type de control, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... est résolu à partir du TypeFieldEntry associé.

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

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

Ceci est identique au comportement présent dans JPlatform 9

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

Il est obligatoire de déclarer l'attribut type ou settings pour afficher correctement le control.

<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ées
Procédez à la mise à jour des imports et signatures des méthodes dans vos développements (notamment WikiPolicyFilte et WysiwygPolicyFilter ).

• com.jalios.jcms.wiki. Pour le wiki des classes assurant une compatibilité partielles 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 d'éditeur 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és ci-dessus, aucun changement de votre WikiPolicyFilter n'est nécessaire.
• A l'édition des anciens champs contenu : une conversion automatique du texte wiki en HTML a lieu.Votre WikiPolicyFilter est également invoqué à ce moment, vous pouvez le déterminer via WikiRenderingHints.isWiki2JHTML. Adaptez éventuellement votre policy pour générer un HTML spécifique.

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

• Coté éditeur : Développement de plugin TinyMCE (en remplacement des WikiPolicyFilter.handleWikiToolbar permettant la modification des barres d'outils de l'éditeur wiki)
• Coté 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 texte wiki et JHTML a été modifié par rapport à celui des versions précédentes.
Si vous aviez personnaliser des feuilles de style avec vos propre CSS, vous devrez les modifier.

Voici les changements notables. Ils concernent principalement le rendu des fonctionnalités disponibles préalablement via le plugin Wiki (pour les WikiPage), qui sont désormais proposé 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és. 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 le compile plus :

jlearnResource.setDuration(240);

il faut désormais écrire :

jlearnResource.setDuration(240L);

Si cette évolution ne devrait donc avoir peu d'impact sur le code spécifique durant les migrations, elle peut avoir un impact sur les performances aux 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 alors toutes les anciennes instances vont être ré-enregistrés dès lors qu'elle seront chargés (au moment du commit de la transaction).

3.8 FriendlyURLSet pour les DB Content

Les DB Content type peuvent désormais définir des URLs intuitives (aka FriendlyURL) comme les 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 apparait 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 https://issues.jalios.com/browse/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çu de l'utilisateur (encodage ou nettoyage selon le type de champ concerné)
• Notamment, pour la gestion des valeur 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 correspondance 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 d'une de ses sous classes), et que vous aviez surchargé la méthode JcmsFormHandler.validate(). Vous devez surchargé la méthode JcmsFormHandler.processAction() à la place (le code de votre méthode ne nécessite aucune adaptation).

https://issues.jalios.com/browse/JCMS-6004 

3.11 Évolution de MenuInfo et MenuInfoFilter

Les classes MenuInfo et MenuInfoFilter (aidant à réaliser des menus de navigation) ont évoluées. 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é. Ce portail doit avoir la classe CSS jaliosAppPortal.

Pour bénéficier du portail des applications par défaut, ajoutez les lignes suivante dans le store.xml (positionnez les correctement selon leur stamp) :

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- |||||||||||||||||||||| 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" />  

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- |||||||||||||||||||||| 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ée à accueillir les fichiers de type image, video 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 type de fichier) dans TOUS les espaces dans lequel ces types de fichiers peuvent être déposé
2. Donner les droits de contributions sur ce type à l'ensemble des contributeurs qui ont le droit sur le type FileDocument ou un sous-type.

4.4 Sélection automatique du type de documents

Des nouvelles propriétés permettent de sélectionnez 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élection 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 standard dans le custom.prop de la plateform.

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-pack. 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-pack sont corrects. Si le site à 3 ou plus invité, il est nécessaire d'obtenir un nouveau add-pack avec la métrique "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 loggué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 loggué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 ne 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 cité au 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 class .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. (https://issues.jalios.com/browse/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 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é réintroduite dans JPlatform 10, voir  JPlatform 10 - API de gestion de l'organisation et des responsables de département.

Le module Organigramme ne fait plus que son rôle de rendu graphique de la structure de l'organisation.

Aussi les modules tels que JLearn ou VacationRequest, dans le version spécifique à 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 (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é-enregistrement 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 une des targets suivantes (SITE_TOPBAR_ADMIN_MENU, WORK_TOPBAR_ADMIN_MENU, ADMIN_TOPBAR_ADMIN_MENU), vérifiez et adaptez au besoin votre rendu.