"cannot resolve unprefixed role" suite à migration
Bonjour,
Depuis la migration d'un intranet de JCMS 8.0.2 vers JCMS 9.0.2, j'obtiens à chaque redémarrage du serveur l'avertissement suivant :
cleanUnprefixedRoleMap: cannot resolve unprefixed role 'redacteur2'
Savez-vous de quoi il s'agit ?
Merci d'avance.
Cordialement.
Bonjour,
Voilà ce qui est indiqué dans la note de migration vers JCMS 9.
3.2 Identifiants des rôles
Les identifiants des rôles dans les attributs roleMap des classes Workspace et Publication ayant changé, ils doivent être migrés.
JCMS 9 prend en charge cette migration.
Au premier démarrage, JCMS 9 génère des propriétés de conversion pour les anciens formats de rôle pour tous les workflows qui sont présents. Exemple :
workflow.unprefixed-role.writers: basic-writers workflow.unprefixed-role.validators: basic-validators workflow.unprefixed-role.writer: wfdraft-writer workflow.unprefixed-role.moderators: wfmoderation-moderators
Attention ! Si tous les workflows n'étaient pas présents lors du premier démarrage avec JCMS 9, il faut générer à nouveau ces propriétés. Pour cela, supprimez ces propriétés et relancez JCMS.
Malheureusement sur un de mes projets, j'ai aussi le même problème. J'ai ce message au démarrage alors que toutes mes propriétés ont été générées par JCMS.
Bonjour,
Si ce message, cleanUnprefixedRoleMap: cannot resolve unprefixed role 'xxx', continue à apparaitre
- après avoir effacé toutes les propriétés
workflow.unprefixed-role.ducustom.prop, - et relancé l'application,
cela signifie que les rôles "xxx" apparaissent dans le store, mais pas dans les fichiers de définition de workflows (/data/workflows/*.xml).
Il s'agit donc d'anciens rôles de workflows, plus utilisés dans l'application, mais toujours présents dans le store. Ce n'est donc pas "grave" en soi.
Néanmoins, si on désire supprimer ces warnings, le moyen le plus propre est de faire un nettoyage du store.
Bien cordialement.
Merci pour votre retour et désolé du retard de ma réponse. Est-ce que ce warning peut être lié à un autre problème que je rencontre, ici : https://community.jalios.com/jcms/2316_SocialQuestion/fr/migration-8-0-2-9-0-2-droits-de-contribution-sur-contenus-multi-positionnes
Merci pour votre aide. Bien cordialement,
Cette réponse mérite d'être la meilleure réponse.
Sinon, une petite commande pour être "rassuré" que ces rôles ne "traînent" plus dans les workflows.
grep -rnw '/path/to/data/workflows' -e "roleId='xyz'"
Même un nettoyage du store ne résout pas le problème. A moins d'éditer le store à la main...
Certe la question a été posée il y a trois ans, mais je ne viens personnellement d'analyser ce problème qu'aujourd'hui ;-)
Il faut donc commencer comme l'indique @Frédéric Touitou , à savoir supprimer les lignes du custom.prop commençant par "workflow.unprefixed-role." et redémarrer.
Cela vous enlève certain warning, mais pas tous.
Du coup, vous récupérer, dans les logs, les identifiants des WFRoles concernés, puis vous chercher les identifiants des workflows dans lesquels ces rôles sont présents, puis vous ajouter les lignes correspondantes de la forme :
workflow.unprefixed-role.<identifiant de rôle>: <identifiant de workflow>-<identifiant de rôle>
(en n'oubliant pas le tiret-dash entre les deux).
Le problème est que la mécanique d'automatisation de génération de ces lignes est incomplète, pour les wf spécifiques.
Ensuite, vous ne laissez pas ces lignes dans le custom.prop, mais vous le mettez dans le plugin.prop du module principal, de manière à ce qu'elles soient livrées avec votre webapp (et pas skippé).
Deux remarques :
- quand on package des modules pour les versions ultérieures à 9 qui existaient avant, et qui comprennent des WF, il est intéressant de mettre ces propriétés directement dans les plugin.prop des modules en question ;
- c'est un plus de pouvoir utiliser les mêmes identifiants pour des WF dirrérents, mais pour l'instant (encore en JDP 10), on a toujours des problèmes de collision entre les identifiants des workflows entre les différents plugins.
Statuts
