Bienvenue
Jalios Community
Tout ce que vous souhaitez savoir sur l'écosystème Jalios
La ttCard d'un Membre a été revue avec une interface plus moderne et plus homogène avec la page profil.
Elle regroupe désormais tous les moyens pour rentrer en contact avec ce membre (représenté par un icône)
Les membres sans photo ont désormais un avatar basé sur leurs initiales.
Les initiales sont calculées à partir de la 1ère lettre du prénom, et de la 1ère lettre du nom. Elles peuvent donc être sur une ou deux lettres.
La couleur est choisie :
Toutes les cartes ont maintenant par défaut des coins arrondis.
Quelques exemples :
L'interface de sélection d'un contenu a été revue afin d'offrir une meilleure ergonomie.
Les filtres et la recherche sont regroupés dans la barre du haut. La recherche est proposée au sein des filtre.
Toute la ligne d'une publication est cliquable pour sélectionner.
A noter qu'il est possible de revenir à l'ancienne version via la propriété suivante : pubchooser.use-jplatform10-pubchooser: false
Les termes Groupe global, Groupes globaux, Groupe(s) commun(s) sont abandonnés et remplacés par le terme Groupe(s) transverse(s).
Les 3 première actions de l'insertion on été renommées afin de clarifier leur portée.
Dans l'interface de recherche, le filtre Dates permet désormais de choisir un période précise (en plus de périodes prédéfinies) :
La recherche de membre propose désormais un tri par nom et prénom prenant mieux en compte les caractères accentués de certaines langues (notamment l'allemand).
Une réindexation des membres est nécessaire.
Une nouvelle action est ajoutée dans la définition d'un workflow : elle permet de prévenir le responsable du rédacteur de la publication.
Lors de la définition d'un rôle dans un espace on peut désormais choisir comme valideur le responsable de l'auteur de la publication :
Un responsable peut modifier un contenu d'un membre de son équipe lorsque ce contenu est dans un état pour lequel il existe une transition sortante gérée par un rôle "responsable".
Certaines branches de catégories (notamment celles des mots-clés) sont ouvertes à de nombreux contributeurs. Elles sont donc sujettes, au fil du temps, à avoir des catégories en doublon. Ces doublons gênent à la fois les contributeurs (quelle catégorie choisir lors de la publication) et les lecteurs (quelle catégorie choisir pour faire une recherche).
Un nouvel outil permettant de nettoyer les catégories filles d'une branche donnée est disponible dans l'espace d'administration.
Lorsqu'on arrive sur le nettoyage des catégories, la branche de catégories contenant les mots-clés du site est sélectionnée par défaut.
On peut choisir le niveau de similarité entre les catégories. En dessous de 100%, plusieurs algorithme de calcul de similarité sont proposés.
Les clusters de catégories similaires sont affichés. L'interface permet de fusionner les catégories d'un cluster ou de masquer un cluster.
Lorsqu'on fait une fusion, on choisit les catégories du cluster qui seront fusionnées et le nom qui sera donné à la catégorie de fusion. Les publications attachées aux catégories fusionnées sont automatiquement rattachées à la catégorie de fusion.
Lorsque le panier est composé uniquement de portlet ou de portail, les attributs communs (habillage, apparence, espacements, alignements, caches, ...) peuvent être modifiés en masse.
La fonctionnalité d'import d'un arbre de catégories existe depuis longtemps. Elle attend un fichier .txt
en entrée.
La fonctionnalité d'export de catégories existe elle aussi, mais ne se faisait pas au même format (.csv
), ce qui empêchait l'import / export sur le même fichier.
Désormais, il est possible d'exporter puis de ré-importer une branche de catégories.
Plusieurs modifications concernant la prise en compte de recherche pour l'analyse des usages :
Les documents importés sur la plateforme lors de la gestion des mails entrants sont maintenant créés avec le même type que lors d'un dépôt.
Ainsi, par défaut, les images seront enregistrées avec le type Media
et les autres documents avec le type DBFileDocument
.
Les vignettes (thumbnail) sont désormais générées dans le format de l'image d'origine, si celui-ci est supporté (jpg
, gif
, ou png
).
Ce comportement par défaut est défini par la propriété tag.thumbnail.format: auto
Un format peut être spécifié :
format="jpg|png|gif"
du tag thumbnail,tag.thumbnail.format: jpg|png|gif
. Dans ce cas, seule l'utilisation du format JPEG
est recommandée pour garantir un équilibre entre qualité et poid des aperçus générés.La configuration par défaut de JPlatform a été modifiée : WebDAV est désactivé en standard.
custom.prop
contient déjà l'activation de la fonctionnalité.Propriété correspondante : channel.webdav.enabled: false
Les gabarits d'habillage (skins) gèrent maintenant l'intégration du champ skinFooter
(Pied de page de l'habillage) qui permet d'ajouter du HTML dans le footer d'un skin via un champ dédié.
Dans l'édition d'une portlet via JPortal vous avez maintenant accès dans l'onglet Avancé aux attributs suivant
La recherche de portlets au premier niveau cherche maintenant par type de portlet, et non plus par instance de portlet
Afin d'être plus compréhensible les portlets Requête itération, Requête/Itération cartes et Requête/Iteration Détaillée ont été respectivement renommées en :
Vous pouvez maintenant plus simplement pointer directement certaines publications de la portlet en choisissant d'entrer :
Au passage, certains champs avancés ont été déplacés dans le champ Avancé.
La recherche dans les publications stockées en base de données est activée par défaut.
La portlet Liste de publication est par défaut configurée par date de publication.
Le gabarit Carrousel de la portlet Liste de Publications a été complétement refait. Il utilise le même rendu que celui de la nouvelle portlet Carrousel.
Cette portlet permet d'afficher un liste de publications sous forme de carrousel.
Champs présents:
Cette portlet permet d'afficher le full display d'une publication.
Si la publication comporte plusieurs templates, il est possible de choisir le template de la publication.
Champs présents :
Un nouveau gabarit affichant les publications sous forme de cartes est disponible. Il est issu du module JNews.
Le tag CardData
permet désormais l'utilisation d'une image spécifique au travers d'un nouvel attribut image
.
Si laissé vide, le comportement ne change pas et utilise la data-image
de la Data
.
Il est possible de débrayer le coins arrondis sur les cartes en surchargeant la variable less (via custom.less) :
Ce tag affiche des publications au format carousel. Il offre le même rendu que la portlet Carrousel.
Ce tag produit un fil d'ariane d'un ensemble d'items. Le rendu est le même que dans le module Explorer, JTask et Espaces de conversations.
Exemple d'utilisation :
<%
List<BreadcrumbItem> items = new ArrayList<>();
items.add(new
BreadcrumbItem().label("Home").url("debug/debugBreadcrumb.jsp").attributes(new
DataAttribute().addData("data-jalios-test", true)));
items.add(new BreadcrumbItem().label("Page 1").url("debug/debugBreadcrumb.jsp?
test=test").active(true));
%>
<jalios:breadcrumb items="<%= items %>" />
L'attribut alt du tag MemberPhoto
est désormais surchargeable.
Si laissé vide, le comportement ne change pas et utilise le nom complet du membre.
Deux nouvelles propriétés permettent de gérer la taille du logo dans la topbar :
jcms.topbar.logo-width
jcms.topbar.logo-height
Pour certaines fonctionnalités, non liées à la sécurité, il est d'usage dans JPlatform et ses modules de proposer le fonctionnement suivant :
JPlatform 10 SP4 simplifie la mise en oeuvre de cette approche grâce à la méthode AccessControlManager.checkAccessIfAclExists(Member, String, Map<String, Object>)
Exemple pour contrôler l'accès au menu Publier de la Topbar :
private static final AccessControlManager ACL_MGR = AccessControlManager.getInstance();
public boolean canUsePublishMenu(Member mbr) {
return ACL_MGR.checkAccessIfAclExists(mbr, TopbarManager.ACL_CAN_USE_PUBLISH_MENU, null);
}
Vous pouvez retirer toutes les infos liées aux départements dans le catalogue des applications en ajoutant cette propriété :
appstore.departments.enabled: false
Le service ConnectionEventManager
permet d'obtenir des informations de connexion d'un membre sur une période donnée.
Les membres ayant l'ACL admin/users/member
ou admin/users/dbmember
peuvent désormais uploader des photos de membres même si la propriété member.photo.upload
est à false.
Le rendu des initiales d'un membre (utilisé s'il n'a pas de photo) est effectuée en pur CSS/HTML.
Les couleurs sont définies par la propriété member.photo.initials.colors
.
Les valeurs acceptées sont :
Color.java
),Exemple : uniquement des couleurs de la palette de couleurs JPlatform
member.photo.initials.colors: GREEN_LIGHT, BLUE_LIGHT, GREEN, BLUE, PINK_DARK
Exemple : uniquement des couleurs custom
member.photo.initials.colors: #FF0000, #00FF00, #0000FF
Exemple : mixte de couleurs Jalios et custom
member.photo.initials.colors: GREEN_LIGHT, #FF0000, BLUE, #00FF00
Cette fonctionnalité ne peut pas être désactivée.
Le nouvel end-point /rest/data/Member/updatephoto/{login}
permet de mettre à jour la photo d'un membre.
Les data image d'un FileDocument invoque désormais la génération de l'aperçu pour le document concerné (sauf pour les document de type images qui continuent à renvoyer l'image elle même).
Les dimensions par défaut utilisées pour la génération de l'aperçu peuvent être configurées avec les propriétés suivantes :
file-document.data-image-thumbnail.width: 960
file-document.data-image-thumbnail.height: 540
Ce nouveau comportement peut être débrayé avec la propriété file-document.data-image-thumbnail.enabled: false
Tous les Comparator
permettant de trier des données JStore par titre/nom utilisent désormais en standard un tri dépendant de la locale de l'utilisateur afin de proposer un tri plus en adéquation avec les attentes des utilisateurs internationaux.
Data.DataNameComparator
Publication.TitleComparator
Member.NameComparator
Member.FirstNameComparator
Group.NameComparator
Workspace.NameComparator
Category.DataNameComparator
PortletSkinnable PortletSkinableTitleComparator
PortletSkinnable ContentTitleComparator
Des alertes de sécurités sont désormais envoyées aux utilisateurs lorsque certaines opérations sensibles sont effectuées avec/sur leur compte.
Notamment :
Voici un exemple d'alerte reçu par un utilisateur en cas d'utilisation de la délagation :
Configuration :
Comme toutes les alertes, une configuration par défaut est possible par l'administrateur, et chaque utilisateur peut configurer les paramétres de réception des alerte (canaux, activation, ...)
Les alertes émises affichent notamment les informations suivantes :
security-alert.display-details.member: false
security-alert.display-details.ip: true
Ces informations peuvent être entièrement omises via la propriété security-alert.display-details: false
Chaque alerte peut également être configurée, grace à des propriétés utilisant le nom technique de l'alerte, tel que consultable dans les fichier fr/en.prop
(auth-delegation
, profile-login-modified
, profile-email-modified
, ...) :
alert.name.security.{name}.enabled: true|false
alert.name.security.{name}.level: info|action|warning
, par défaut toutes les alertes sont de niveau Avertissement.html
, htm
, shtml
, body
, jsv
, js
-> déposé en tant que .txt
swf
, svg
, svgz
-> déposé en tant que .bin
Il est fortement recommandé de conserver cette configuration standard.
Cependant, si vous souhaitez réactiver ces formats, vous pouvez le faire en réassociant chaque extension à son extension d'origine.
Exemple pour ré-autoriser le format SVG.
file-document.invalid-extension.svg: svg
A nouveau : la réactivation de ces formats de fichier n'est pas recommandée si le dépôt de fichier est ouvert largement et que vous souhaitez garantir la sécurité de votre plateforme.
Dans ce cas, vous êtes fortement invités à considérer la mise en oeuvre d'une politique de sécurité plus fine par développement spécifique.
Par exemple en autorisant le dépôt de ces fichiers sensibles uniquement à certains contributeurs de confiance.
Une nouvelle option est disponible pour interdire la modification du login par l'utilisateur lui-même.
Lorsque la propriété member.rights.allow-login-change: false
est positionnée, seul un administrateur ou un utilisateur autorisé à éditer les membres via l'ACL dédiée, sera autorisé à modifier le login d'un membre.
Une nouvelle option est disponible pour interdire la modification de l'adresse e-mail par l'utilisateur lui-même.
Lorsque la propriété member.rights.allow-mail-change: false
est positionnée, seul un administrateur ou un utilisateur autorisé à éditer les membres via l'ACL dédiée, sera autorisé à modifier l'adresse e-mail d'un membre.
Un nouveau contrôle est effectué sur les membres lors de leur création ou de leur mise à jour afin d'interdire l'utilisation d'une adresse e-mail déjà utilisée par un autre utilisateur.
Afin de mieux prémunir le site contre les attaques de type force brute, la configuration par défaut de l'algorithme de hashage BCrypt a été renforcé.
Le réglage possible sur l'algo était de 10
, il a été augmenté à 12
:
channel.bcrypt.log2rounds: 12
Les utilisateurs doivent modifier/ré-enregistrer leur mot de passe pour bénéficier de cette sécurisation supplémentaire.
Pour plus d'informations sur les configuration possible, consultez Quelle protection existe-t-il contre les attaques brute-force sur le login ?
Afin d'éviter des attaques par la JSyncServlet
, toutes les requêtes arrivant sur cette servlet doivent contenir un paramètre secret contenant un secret partagé (une String) commun entre le leader et tous les réplicas.
Ce secret est stocké dans la propriété jsync.shared-secret
.
Au démarrage, si cette propriété est vide :