Bonjour,
Avec l’outil Builder 4.2, j’ai personnalisé ScenariSuiteStarter4.2, notamment les rôles.
L’utilisation du serveur personnalisé fonctionne comme prévu sur le portlet « chain ». Les utilisateurs sont membres de groupes qui leur attribuent des droits. La rédaction s’effectue sur des ateliers calques de travail et, après validation, la génération des documents est faite sur l’atelier de référence (pas sûr de l’appellation). Les droits de rédaction, de publication et de validation sont donnés sur certains espaces de l’atelier.
Par contre, avec le portlet « depot », un utilisateur avec le rôle de publication ne peut pas choisir un emplacement sur le dépôt avec l’erreur « accès non autorisé » lors de la publication suite à une génération.
Le fonctionnement des droits attendu est le suivant :
lecture : accès en lecture seule au contenu,
rédaction : modification du contenu et les droits « lecture »,
validation : validation du contenu depuis un atelier calque de travail vers l’atelier de référence et les droits « rédaction »
publication : génération des supports à partir du contenu validé (donc depuis l’atelier de référence) et transfert sur le dépôt.
Les droits et les rôles sont définis de cette façon :
default.right (globalPerm « DO » et « DATA »)
lecture.role (superRole : « default », allowPerms : « read »/« use » et denyPerms : « DO »/publier.perm/valider.perm)
Les permissions personnalisées sont les suivantes :
publier.perm (globalPerm « write.UTNode »)
valider.perm (globalPerm « commit.drf »)
Les portels « chain » et « depot » ont tous les deux les mêmes « rolesDefinition ».
J’aurais voulu savoir si ce paramétrage est cohérent par rapport au fonctionnement attendu et pourquoi est-ce que l’utilisateur qui a les droits de publication ne peut pas envoyer de documents sur le dépot. Un utilisateur avec le role « gestion » peut lui, publier.
Autre question annexe, quelle est la réelle utilité du rôle « default » et pourquoi a-t’il autant de droits ?
Merci pour vos retours et bonne nouvelle année à tous !
pourquoi est-ce que l’utilisateur qui a les droits de publication ne peut pas envoyer de documents sur le dépot
J’imagine que vous avez affecté le rôle « publication » à votre utilisateur sur un atelier (voir un espace) et non à l’utilisateur lui-même. Si c’est bien le cas, le comportement est « logique » : le système dépôt n’est dépendant d’aucun atelier particulier, tous les rôles spécifiques à chaque atelier (ou espace dans l’atelier) ne peut être pris en compte : lorsque la brique dépôt contrôle les permissions, elle le fait dans sa propre structure, prenant en compte les rôles directement associés à l’utilisateur et les rôles associés à la hiérarchie des dossiers du dépôt.
Dites-nous si vous n’êtes pas dans ce cas…
quelle est la réelle utilité du rôle « default » et pourquoi a-t’il autant de droits
Le droit « default » (c’est un .right, pas un .role, il n’est pas manipulable dans les interfaces graphique), défini le comportement par défaut de l’application quand il n’y a pas d’utilisateurs. C’est le cas lorsque vous utilisez SCENARIchain avec l’entrepôt local.
Faire hériter tous les rôles de ce rôle « racine » permet aisément d’éliminer des fonctions très précises de l’application (car inutiles dans le contexte cible) quelque-soit l’utilisateur connecté et ses rôles.
Dans SCENARIchain en entrepôt local, ce rôle « default » autorise évidemment tout. Par analogie, dans nos portails où nous souhaitons pouvoir tout ajuster nous avons redéclaré ce rôle « default » avec les mêmes règles : tout autoriser par défaut puis contraint dans les sous-rôles. Mais d’un point de vue logique cela peut surprendre (et cela vous a semble-t-il surpris !). C’est pourquoi nous avons depuis renversé la configuration dans nos modèles en 5.0 : tout est interdit par défaut pour le rôle « default » (mais tant que la configuration est cohérente cela peut revenir au même !).
Une bonne pratique peut être de créer un groupe « publication » avec - au niveau de l’entrepôt chain - un rôle autorisant les permissions :
read.UTNode
write.UTNode
admin.UTNode (si vous activez la couche de gestion des rôles dans les dossiers du dépôt)
ui.depotBrowseView
ui.depotDesk
En procédant ainsi, ces users auront des permissions étendues sur l’ensemble de l’application (chain/dépôt) mais ces permissions ne ciblent que des fonctions de dépôt.
Vous pouvez ensuite procéder comme vous le faites actuellement côté chain.
Si jamais vous souhaitez gérer des dossiers avec des permissions de publication différenciées côté dépôt, il faut activer la couche de gestion des rôles du dépôt (cf : ScenariSuite-Starter - Gestion du dépôt - #4 par tha).
Ensuite, il vous faudra :
Décommenter le processing folder dans le fichier depot.portlet
Lui ajouter dans la partie mainView la balise smp:EditRolesTab.
faire un rôle de lecture du dépôt (le même qu’au dessus sans write.UTNode et admin.UTnode) et un rôle d’écriture (lecture + write.UTNode et admin.UTnode).
Associer le rôle lecture à votre groupe « publication »
dans l’interface du dépôt, sélectionner les dossiers sur lesquels un user ou groupe a le droit de publier, aller dans l’onglet précédemment déclaré et ajouter le rôle d’écriture à ce user ou groupe.
Bonjour Sylvain et Thibaut,
Merci beaucoup pour vos réponses. En appliquant vos indications, j’ai pu faire en sorte qu’un utilisateur puisse envoyer des générations sur le dépôt.
Pour cela, j’ai créé un nouveau rôle de « diffusion » (sans groupe exclusif) comme suit :
Ajouté à l’entrepôt complet, ce rôle permet bien aux utilisateurs membres de groupes « de publication » de diffuser les contenus sur le dépôt.
Je vais donc maintenant travailler pour affiner les permissions de diffusion dossier par dossier comme vous le décrivez Thibaut.
Merci pour l’explication du rôle par défaut c’est plus clair et pour le lien vers la documentation ou certains droits sont expliqués.
et pour le lien vers la documentation ou certains droits sont expliqués.