Découvrez comment partager un contenu entre plusieurs espaces.
Voir les 79 commentaires
79 commentaires
1 vote :
Bonjour,
Comment sont gérés les droits de consultation appliqués à un contenu partagé entre espaces collaboratifs privés et/ou secrets ? Est-il bien visible par les membres qui ne font pas partie de l'espace de rattachement d'origine du contenu ?
Merci d'avance de votre réponse.
1 vote :
Bonjour,
Plusieurs questions :
- Le partage de document n'est valable qu'entre espaces collaboratifs ou également entre espaces éditoriaux ?
- Le partage n'est en lui même qu'un pointeur vers le document de référence ? sous entendu toute modification du document est visible dans les espaces ou il est partagé ?
1 vote :
@tfeignon : Oui le but est justement de pouvoir rendre exceptionnellement visible un document dans un autre espace.
@fabrice mathieu : Le partage portlet sur l'espace de travail donc Collaboratif ou éditorial. Il n'y a pas duplication, donc les modifications seront bien visibles dans tous les espaces de partages.
Merci Guillaume.
Autre question pour compléter : les droits de contribution/modification/suppression sont-ils uniquement liés à l'espace d'appartenance du contenu ou à l'instar des droits de consultation, sont-ils "partagés" ?
1 vote :
Bonjour,
En quoi consiste le partage ? Cela se traduit-il par la création d'un contenu "passerelle", référençant le contenu source ?
Autre question : pourquoi avoir limité le partage aux administrateurs de l'espace cible ?
Merci d'avance,
3 votes :
Bonjour,
Si le partage est uniquement possible pour les administrateurs de l'espace, ca enlève beaucoup d’intérêt à cette nouvelle fonctionnalité 
1 vote :
@tfeignon Les droits de modification et de suppression sont ceux dans l'espace d'origine. Les espaces de rattachement n'élargissent que les droits de consultation aux membres des espaces rattachés.
@cyril.david Techniquement, dans JPlatform 10, chaque publication possède dans un champ Espace de rattachement contenant les espaces dans lesquelle elle a été partagé (il n'y a pas de contenu "passerelle", c'est bien le même contenu qui apparait dans les différents espaces).
@Pascal DEREX et @cyril.david Concernant la limite aux administrateurs de l'espace cible, on a fait ce choix un peu drastique car cette nouvelle fonction permet d'exposer dans des espaces public des contenus issues d'espaces secrets ou privés. Aussi, on ne voulait pas permettre à tout le monde d'en disposer.
Nous sommes conscient qu'il s'agit d'une restriction trop forte. Nous envisageons de proposer une ACL permettant de définir les personnes ayant ce droit. Mais c'est encore en réflexion.
1 vote :
Bonjour,
Y-a-t-il un événement (opération) disponible dans les DataController pour pouvoir agir programmatiquement lors d'un partage de document entre espaces ?
Comment est géré au niveau des statistiques, la visualisation d'un document partagé dans l'espace cible ? Est-ce que la visualisation est comptabilisée dans l'espace d'origine ?
Benoît
3 votes :
Je partage l'avis de Pascal DEREX en ce qui concerne les personnes pour lesquelles cette fonctionnalité est disponible?
En ce qui me concerne, un hook de type canShare(member, doc, targetSpace) serait idéal.
Benoît
2 votes :
J'appuis la demande de @Pascal DEREX, la limitation aux administrateurs seulement n'a clairement aucun intérêt pour nous.
Nos collaborateurs utilisent le multiclassement d'un document et commencent à en être fortement friand... Leur mettre à disposition la possibilité de partager un document entre plusieurs espaces est clairement une demande chez nous.
Nous disposons d'un espace par projet et il n'est pas rare qu'un document se retrouve dans plusieurs projets. Aujourd'hui il n'y a que la duplication qui fonctionne (au vu de la configuration de nos espaces et de nos portlet explorer la simple multicatégorisation ne fonctionne pas).
Leur offrir la possibilité de réaliser eux même l'opération c'est clairement offrir l'option décisive aux derniers récalcitrants pour utiliser l'outil.
Nous savons que vous êtes à l'écoute, alors nous faisons nos propositions et feedback sur les éléments les plus importants de JPlatform.
La partie documentaire est aujourd'hui le coeur des discussions dans notre entreprise qui n'en est qu'à ces débuts d'usage de JPlatform.
1 vote :
@Benoît Dissert On peut agir programmatiquement avec un DataController sur le partage inter-espace puisqu'il est matérialisé par le champ attachWorkspaceSet de la class Publication. Il est ainsi possible de l'interdire programmatiquement (dans checkWrite()) ou de l'enrichir (dans beforeWrite())
Concernant la comptabilisation de visualisation, pour le suivi des lecteurs (ReaderTracker) toutes les lectures sont aggrégées.
Pour les statistiques, (fichiers json), c'est le portail d'affichage et l'espace de ce portail qui sont enregistrée. Ainsi, si la publication P1 de l'espace E1 est partagé dans l'espace E2, lorsque P1 sera affichée dans E1 elle sera comptabilisé dans le rapport pour E1, lorsqu'elle sera affiché dans E2 elle sera comptabilisé dans le rapport de E2.
5 votes :
@Benoît Dissert @Pascal DEREX @Cédric BERGOUGNOUX
Suite à vos retours, et à notre propre retour en interne, nous allons changer la politique de partage inter-espace.
Voici ce que j'envisage :
Soit C un contenu appartenant à l'espace E1
Le contenu C peut être partagé vers l'espace E2 par le membre M si la condition suivante est vrai :
(M est admin central OU M est admin de E1 OU M est auteur de C) ET M peut contributer dans E2
Un membre M peut arrêter le partager le contenu C de l'espace E2 si la condition suivante est vraie :
(M est admin central OU M est admin de E1 OU M est auteur de C OU M est admin de E2)
Qu'en pensez-vous ?
@Olivier Dedieu Par rapport au commentaire #12 En ce qui concerne les statistiques (JSON), c'est également le cas pour le téléchargement des pièces jointes ?
@Olivier Dedieu #13 Dans le cas d'une implémentation client que j'ai du faire, les contenus à partager étaient dans des espaces collaboratifs et le partage permettait de publier les documents dans le référentiel (autre espace). Les contributeurs des espaces d'origine n'étaient pas autoriser à contribuer dans le référentiel par un autre moyen que par ce canal. (donc la règle de gestion imaginée ne fonctionne pas)
@Benoît Dissert Pour les stats sur les téléchargements je pense que oui (je n'ai pas vérifié) car il s'agit des même données issue du JSON qui sont utilisées.
Concernant ma proposition au commentaire #13, ce qui te gêne est uniquement que M doit être contributeur dans E2 ? C'est bien ca ?
Mais si on ne met pas en place cette limitation n'importe qui peut partager un de ses contenus dans n'importe quel espace auquel il appartient. N'est-ce pas un peu trop violent ?
@Olivier Dedieu, je rejoins @Benoît Dissert : d'expérience, le scénario est de rendre visible un contenu d'un espace collaboratif dans un espace de travail "plus fréquenté".
En un sens, on se rapproche un peu du principe de curation.
Le cas d'usage, selon moi serait plutôt :
- un membre
Mnavigue dans son site, et voit un contenu dans un espaceE1qu'il trouve très intéressant - il se trouve que le membre
Mest contributeur dans un espaceE2du site, et qu'il se dit qu'il serait intéressant de partager les informations contenues dans ce contenu - dans ce cas, plusieurs possibilités (liste non-exhaustive) :
- créer un contenu dans l'espace
E2qui référence le contenu de l'espaceE1 - doublonner le contenu dans l'espace
E1==> très mauvaise pratique, on va alors se retrouver avec un doublon, et si le contenu initial est mis à jour, le doublon ne profitera pas des mises à jour - profiter d'une fonctionnalité de partage, permettant de référencer intelligemment le contenu initial, sans pour autant créer de nouveau contenu
- créer un contenu dans l'espace
C'est justement cette 3ème approche que nous avons déjà mise en oeuvre pour des clients.
La différence fondamentale entre l'approche que tu proposes, et l'approche que nous avons suivie, est la gestion des accès : dans notre cas, un membre M2 ne peut voir le partage de contenu dans l'espace E2 que s'il dispose des droits d'accès au contenu source de l'espace E1.
1 vote :
@cyril.david Le scénario est intéressant. Dans celui-ci M a les droit de contribution dans E2 (nouvel espace de rattachement du contenu). Or @Benoît Dissert expose un cas opposé : M doit rattacher un contenu dans un espace E2 dans lequel il n'a aucun droit de contribution.
Pour ce qui est de la dernière contrainte : (M ne voit un contenus partagé dans E2 que si il a accès à ce contenu dans l'espace E1) ca pourrait être traité en complément avec une RightPolicyFilter spécifique.
Si on voulait couvrir ces 2 scénarios, il faut alors relâcher toutes les contraintes par défaut : n'importe qui peut rattacher n'importe quel contenu n'importe où. Puis ajouter des RightPolicyFilter pour préciser les règles au cas par cas.
Cette approche n'est pas satisfaisante car sans développement additionnel la fonctionnalité est trop permissive et donc inutilisable.
Une autre solution serait d'avoir un comportement correspondant à un cas d'usage simple de partage avec un minimum de contrôle. Puis d'avoir moyen de prendre la main programmatiquement pour restreindre ou élargir le droit de rattachement (quelque chose du genre RightPolicyFilter.canAttach(isAuthorized, pub, ws, mbr)). C'est quelque chose que l'on peut envisager en SP1 car nous sommes trop proche de la sortie pour ajouter ces fonctionnalités maintenant.
@Olivier Dedieu Oui, tout à fait, Cyril et moi avons deux cas de figure distincts. Pour être plus précis dans les choix de conception qu'on avait fait : lorsqu'on était sur un document de travail (dans un espace collaboratif), et qu'on avait le droit de passer ce document dans un état de workflow précis "référencé", alors on a un bouton de plus dans les interfaces de contribution de ce document, qui ouvre en modale la contribution d'un formulaire "de référencement", qui contient plein de méta-donnée additionnelles, qui permettent au référenceur de proposer des méta-données pour la cible (le document référencé), mais l'application précise de ces méta-données étaient laissées à l'appréciation d'un autre rôle, dans le référentiel, que nous appelons des "documentalistes".
Autre cas de partage de documents entre espaces auquel je pense, sur Interstices.info, les articles, dans des espaces de travail sont publiés dans un autre espace s'ils changent d'état de workflow (suite à validation par un quorum de reviewer).
@Benoît Dissert Le rattachement d'un contenu à un espace en fonction de son état de Workflow peut être traité je pense avec un DataController.
Par contre, il ne faut pas oublier que tous les commentaires associés au contenu partagés sont visibles quelque soit l'espace d'affichage. L'objectif est de permettre l'échange entre les participants quelque soit l'espace dans lequel il consulte le contenu. C'est aussi quelque chose sur lequel on prévoit des évolutions (commentaires partagés ou cloisonnés)
2 votes :
@Olivier Dedieu Oui, c'est une première itération, mais je pense que c'est une fonctionnalité qui va intéresser beaucoup de monde, avec des petites spécificités fonctionnelles au cas par cas.
Dans le cas présenté par @Benoît Dissert, si je comprends bien, il ne s'agit pas à proprement parler d'un partage de contenu, mais plutôt d'un routage de contenu, non ? Le contenu source n'a pas nécessairement vocation à être conservé dans l'espace initial, me trompe-je ?
Je te rejoins @Olivier Dedieu sur la philosophie, quand tu dis qu'il faut peut-être voir plus global, en disposant de la possibilité d'affiner la règle.
Il est peut-être possible de trouver un juste milieu, pour que la fonctionnalité soit par défaut exploitable.
Exemple :
- via une propriété, on référence un groupe Jalios, pour lequel ses membres ont la faculté de partager un contenu dans n'importe quel espace (sous réserve qu'ils disposent d'un accès en écriture)
- ensuite, au regard des besoins, un hook tel que tu le proposais permettrait d'affiner cette règle
Qu'en dites-vous ?
Je me rends compte que nous sommes peut-être en train d'utiliser les commentaires de ce JLearn à mauvais escient ==> il vaudrait peut-être mieux poursuivre cette discussion dans un espace de discussion ?
Au besoin, je peux me libérer quelques minutes pour échanger de vive voix à ce sujet si vous le souhaitez.
Bonjour,
je trouve la proposition présentée par @Olivier Dedieu plutôt pas mal dans un premier temps en attendant dans une SP1 des options supplémentaires pour répondre à des besoins plus spécifiques.
Personnellement je simplifierai encore un peu la politique de partage inter-espace :
- En tant que : membre de l'espace E2 avec des droits de contribution sur cet espace
- je peux : partager un contenu C1 appartenant à l'espace E1
- afin de : partager un contenu dans mon espace E2 sans dupliquer le contenu de référence
- En tant que : Auteur du contenu C1 ou Admin de l'espace E1
- je vais : recevoir une notification lorsque mon contenu ou un contenu de mon espace est partagé par un contributeur dans un autre espace
- afin de : d'être informer du partage de mon contenu et éventuellement arbitrer sur ce partage au besoin
- En tant que : Auteur du contenu C1 ou Admin Central ou Admin de l'espace E1
- je peux : arrêter/annuler le partage
- afin de: garder la main sur les contenus dont j'ai la responsabilité
Il me semble que la philosophie du partage ressemble un peu comme évoqué à la Curation : Une personne veut partager un contenu qui n'est pas à lui avec d'autres personnes.
C'est le cas le plus général qui doit être adressé il me semble.
Dans ce cadre là si le propriétaire du contenu et le responsable de l'espace d'origine du contenu sont notifiés et ont la main pour arrêter le partage, il me semble que cela permet de maîtriser suffisament le processus.
Une option supplémentaire sera peut être d'avoir, comme pour les commentaires, la possibilité de désactiver le partage au niveau du contenu lui même...
En tout cas c'est une fonctionnalité intéressante. bravo
Bonjour fabrice mathieu,
La politique de partage inter-espace dont vous faites état me parait similaire à celle que j'évoquais.
En revanche, la partie que je trouve intéressante réside dans les notions de notification et d'arrêt / annulation de partage.
Je nuancerais toutefois l'arrêt / annulation de partage, en essayant de se raccrocher au maximum à la philosophie Jalios, via l'usage d'un workflow. Ainsi, lorsqu'un partage est initié, une population aurait la possibilité d'accepter / refuser le partage.
2 votes :
Bonjour @cyril.david,
le problème du workflow c'est que cela complexifie l'usage de la fonctionnalité et freine les utilisateurs.
Cela créer potentiellement un goulot d'étranglement au niveau de la validation.
Rien de plus frustrant que d'attendre la validation d'un partage si on sait que dans 99% des cas, le partage sera validé.
Est ce que ce sont les 1% de cas à arbitrer qui doivent driver la fonctionnalité ?
C'est un peu "control freak" versus "control social"
2 votes :
fabrice mathieu Chez mes clients, c'est plutôt l'inverse : l'absence de processus de validation empêche la fonctionnalité ;-(
1 vote :
Hello @Benoît Dissert, c'est l'absence de processus de validation qui empêche la mise en place de la fonctionnalité ou l'usage de la fonctionnalité par les utilisateurs (qui ont alors peur de l'utiliser en leur nom propre) ?
1 vote :
fabrice mathieu La mise en place. C'est au niveau des DSI (cellules habilitations et RSSI) que ça bloque.
1 vote :
Je partage le retour d'expériences de @Benoît Dissert.
2 votes :
C'est ce que j'appelle le "control freak". Les utilisateurs ne sont pas les payeurs 
Le contenu d'un espace A est partagé dans un espace B. Vous confirmez qu'il reste stocké dans l'espace A ?
@pgrange Oui, je vous confirme que lorsqu'un contenu de l'espace E1 est partagé dans l'Espace E2, ce contenu reste un contenu de l'espace E1 rattaché à l'espace E2.
1 vote :
@Olivier Dedieu : Votre proposition en commentaire #13 me plait bien. Sera t'il possible d'ajouter ce droit également via des ACL ? (Pour les animateurs de l'espace par exemple ?).
En tout cas, merci pour la prise en compte de notre demande.
Une question concernant cette information : "Oui, je vous confirme que lorsqu'un contenu de l'espace E1 est partagé dans l'Espace E2, ce contenu reste un contenu de l'espace E1 rattaché à l'espace E2."
Mes portlets explorer sont configurées pour filtrer l'affichage des documents SEULEMENT sur l'espace en cours d'utilisation. Le comportement prévu pour le partage d'une publication dans plusieurs espaces permettra de la rendre "visible" avec notre configuration de portlet ou bien faudra t'il effectuer des modifications sur ces dernières ? [nous sommes exclusivement en DBDocs].
Merci
L'approche par l'envoi d'une alerte proposée par @fabrice mathieu (le control social vs control freak) me plait bien car elle permet le partage tout en ayant un contrôle, a posteriori, par ceux (l'auteur et l'admin de l'espace d'origine) qui connaisse le contexte d'usage (et donc de confidentialité) du contenu
Par contre, je pense qu'il y a un soucis avec l'annulation du partage. Il faut que celui qui vient de faire le partage puisse aussi annuler ce partage. Or nous n'avons pas actuellement accès à l'information de qui est à l'origine du partage (en tout cas pas de façon performante).
Ceci implique donc que n'importe qui ayant les droits de contribution dans= E2= puisse arrêter le partage de n'importe quel C dans E2
En résumé :
Soit C un contenu appartenant à l'espace E1
Le contenu C peut être partagé vers l'espace E2 par le membre M si la condition suivante est vrai : M est admin central OU (M a accès à C ET M est contributeur dans E2)
Une alerte est envoyée à l'auteur de C et à l'ensemble des admin de l'espace de C dès qu'un partage a lieu indiquant qui a déclenché le partage (M) et dans quel espace (E2)
Un membre M peut arrêter le partage du contenu C dans l'espace E2 si la condition suivante est vraie : M est admin central OU M est l'auteur de C OU M est admin de E1 OU M est admin de E2 OU M est contributeur dans E2
@Cédric BERGOUGNOUX L'ajout d'une ACL est effectivement prévu mais ca sera pour la SP1.
Je confirme que si un contenu C est partagé dans l'espace E2 alors il sera visible dans l'explortateur de E2 si celui-ci est configuré en mode "affinement sur l'espace courant". Ce comportement est illustré à l'étape 7 de ce guide.
@Olivier Dedieu J'ai quelques difficultés à identifier le cas où l'auteur du contenu voudrait arrêter le partage vers un espace E2. Idem pour l'administrateur de E1
Pour moi, cette logique va à l'inverse de la logique de partage.
Qu'un administrateur central, ou bien un administrateur de E2, ou bien la personne ayant initiée le partage puisse arrêter le partage cela me semble en revanche légitime.
D'ailleurs, cela m'amène à poser une seconde question : comment avez-vous envisagé la gestion de cette fonctionnalité dans chaque espace ?
Un écran listant les partages dans l'espace cible (E2) est-il prévu ?
1 vote :
@cyril.david L'administrateur de l'espace E1 ou l'auteur de C peut estimé qu'il ne faut pas partager ce contenu dans E2 car il contient des informations confidentielles et donc arrêter le partage.
Concernant la gestion de la fonctionnalité, il est prévu, pour la SP1, d'avoir dans les tableaux de bord de chaque espace 2 listes :
- la liste des contenus de l'espace qui sont partagés dans un autre espace (et l'espace cible)
- la liste des contenus externes à l'espace qui sont partagé dans cet espace (avec leur espace d'origine)
1 vote :
Comme le dit @Olivier Dedieu c'est il me semble légitime que ce soit l'auteur de C ou l'admin de E1 qui puissent avoir le dernier mot sur le partage : fonctionnellement ce sont les plus à même de connaitre la portée de leur document et de l'espace auquel il appartient et de juger si il y a un problème à partager le contenu de référence.
La version alternative, peut être plus simple à mettre en oeuvre, c'est d'avoir un attribut partage oui/non au niveau du contenu comme pour les commentaires :
- Si l'auteur positionne à non, il n'y a pas de discussion ni de problème de sécurité puisque la fonction de partage n'est alors pas disponible. C'est l'auteur qui maîtrise alors le partage de ces contenus...
Concernant la faculté des administrateurs et auteur de l'espace E1 d'arrêter le partage, je reste persuadé que cette solution n'est pas viable, étant donné qu'ils pourront intervenir a posteriori, ce qui peut poser des soucis :
- notamment une incompréhension des utilisateurs qui vont voir apparaître / disparaitre un contenu
- dans le pire des cas, un utilisateur un peu borné qui pourrait refaire un partage de contenu après que ce partage ait été arrêté
La version alternative proposée par fabrice mathieu me semble en revanche très intéressante.
Cyril DAVID Tout simplement si l'auteur à partagé le contenu par erreur (mauvais contenu par exemple), ou s'il vient de se rendre compte que des contraintes qu'il ignorait dans un premier temps lui impose de ne pas partager.
2 votes :
@fabrice mathieu Concernant l'attribut sur les contenu pour autoriser / interdire le partage, c'est effectivement quelque chose que j'ai dans le backlog de ce chantier et qu'on peut envisager pour la SP1.
Cool
2 votes :
Plusieurs clients vont être ravis : merci.
2 votes :
le partage d'espace est-il disponible dans la gestion du panier ?
1 vote :
Non.
On est parti du principe que le partage d'espace était une action assez occasionnelle et s'appliquant à chaque contenu au cas par cas. On verra à l'usage si le besoin de faire du partage en masse par le panier s'avère nécessaire.
Lorsqu'un document est partagé sur plusieurs espaces, la modification de ce document peut-elle se faire sur l'ensemble des espaces ou seulement sur l'espace d'origine ?
Je n'ai pas ce bouton. Je suis en version 9.0. y a t-il une méthode en attendant de migrer vers celle ci ?
@claire.daval Un contributeur peut éditer un contenu sur lequel il a les droits quelque soit l'espace ou ce contenu apparait.
@lpeschet Cette fonction n'est disponible qu'à partir de JPlatform 10. Il est tout à fait possible de migrer de JCMS 9 à JPlatform 10. Je vous invite à vous rapprocher de votre intégrateur ou de l'équipe Services Professionnels de Jalios (@Xavier Masia).
1 vote :
Bonjour,
Puis-je récupérer ce savoir et l'intégrer sur notre plateforme OSMOSE ?
Si oui, pouvez-vous m'indiquer comment ?
Merci par avance
2 votes :
Olivier Szendy Nous n'avons pas actuellement de fonction d'import/export sur les savoirs JLearn. Mais c'est dans le backlog de JLearn.
Nous avons par contre une procédure pour faire de l'import / export de JGuide en utilisant la fonction standard d'import/export de JPlatform : Faire de l'import / export de JGuide
Cependant cette procédure nécessite d'avoir des droits administrateur sur la platforme sur laquelle se trouve le guide à exporter.
Je vous propose de vous rapprocher de votre consultant Jalios ( Alex Rameaux Wafo Defo je crois) pour obtenir l'URL à importer.
2 votes :
Merci pour cette indication. Cependant je ne vais pas solliciter @Alex Rameaux Wafo Defo car le process est assez complexe et il est plus rapide finalement de recréer un savoir.
Dommage cependant que cette fonction n'existe pas (on pourrait l'autoriser par guide et faire un système de référence pour la partie "droits d'auteur").
1 vote :
Bonjour Olivier Dedieu , dans le commentaire #36, vous indiquiez la mise en place de tableau de bord listant les contenus partagés. Ce type de reporting me parait intéressant. Toutefois, je ne l'ai pas trouvé en SP1, dans l'administration d'un espace. Cela a-t-il été mis en place ? Est-ce toujours dans la roadmap ?
Merci pour votre retour.
2 votes :
Magali Mengual L'évolution a été faite 10 SP2 : https://issues.jalios.com/browse/JCMS-6963
Super guide ; néanmoins j'ai un soucis avec le partage entre espace :
Un contenu partagé peut-être départagé par tout le monde (même un membre ne pouvant pas le modifier peut quand même le départager)
Est-ce le comportement souhaité ? (je ne pense pas)
J'ai reproduit ce fonctionnement sur la démonstration en ligne demo.jalios.com
1 vote :
Sébastien Raphel Je suis preneur d'une petite vidéo qui me montre comment tu fais.
Olivier Dedieu Sur cette fonctionnalité, je rencontre un cas jugé bloquant par l'un de nos clients et je n'ai pas l'impression d'avoir trouvé ma réponse dans tous ces commentaires.
Soit C un contenu appartenant à l'espace E1
Le contenu C est partagé vers l'espace E2 par le membre M car il est contributeur de l'espace E1 et E2
Cependant, au moment du partage, il ne catégorise pas le contenu "proprement" dans l'espace E2
Soit A le membre administrateur de l'espace E2 mais qui n'est pas contributeur dans l'espace E1
A est bien notifié du partage dans son espace, mais n'a pas la main pour recatégorisé comme il le souhaite (ou comme cela est attendu...) le contenu parmi les catégories de son espace.
Pourrait-on imaginer (ou peut-être est-ce déjà possible) que A puisse avoir la main sur la catégorisation du contenu partagé dans le périmètre de ses droits d'usage de catégorie (donc uniquement les catégories de son espace E2dans mon exemple) ?
En l'état, il est soumis au bon vouloir (et à la dispo) du contributeur M pour catégoriser correctement son contenu partagé.
5 votes :
cedric tremintin Le partage inter-espace a pour objet de rendre visible (et non éditable) un contenu d'un espace E1 dans un espace E2. Pour ce qui est de la modification du contenu (donc notamment la catégorisation) alors il faut avoir le droit de modification dans l'espace d'origine (E1).
Lors du partage, et uniquement lors du partage, on lève partiellement cette contrainte en permettant au membre qui partage d'ajouter des catégories de l'espace cible (E2) même s’il n'a pas le droit de modifier le contenu dans l'espace d'origine.
On ne peut donc pas utiliser les interfaces d'édition standard de JPlatform pour permettre à l'administrateur de l'espace E2 de recatégoriser les contenus externes partagés dans son espace.
Pour répondre à la demande, il faudrait développer une interface spécifique de re-catégorisation (partielle, limités aux catégories de l'espace) des contenus partagés. Rien d'impossible techniquement et faisable en développement spécifique. Ca n'est pas actuellement dans la roadmap produit.
Merci Olivier Dedieu pour ton retour.
Bonjour Olivier Dedieu ,
Est-ce que cette fonctionnalité est disponible pour le JReady? Car on ne trouve pas les options de partage entre espaces sur cette version.
Merci.
Cordialement.
2 votes :
François-Xavier Trolliard
Oui cette fonctionnalité est présente dans JReady si vous êtes sur un JReady 4 (basé sur JPlatform 10).
A noter qu'il est possible de désactiver cette fonctionnalité avec la propriété publication.attach-ws.enabled. Aussi, vérifiez si cette propriété est bien à true (via l'éditeur avancé des propriétés).
Si le problème persiste, je vous invite à créer un ticket depuis votre espace support.
Cordialement
Bonjour Olivier Dedieu ,
merci de votre retour. Effectivement, une fois la clé passée à true, cela fonctionne bien, on peut partager les documents entre espaces.
Par contre, on a un souci, si on partage un doc dans un espace co, un membre de cet espace co qui n'y avait pas accès dans l'espace d'origine, ne peut pas le consulter. On a un message d'erreur indiquant que c'est dû au categoryrightpolicyfilter. Effectivement, nous avons activé cette clé pour que dans notre espace documentaire, les membres héritent des droits sur les documents dans les sous-catégories...
Est-ce qu'il y aurait donc une incompatibilité de fonctionnement sur le partage inter espace si cette clé de categoryright est activée?
Merci.
Cordialement.
Bonjour François-Xavier Trolliard ,
Le module CategoryRight contrôle l'accès à un contenu en fonction des droits sur ses catégories.
Il n'est pas incompatible avec le partage inter-espace mais ce combine avec.
Si vous faites un partage d'espace sur un contenu qui est contrôlé par le CategoryRight, il reste quand même controlé par le CategoryRight.
Olivier Dedieu
J'ai effectué des tests plus poussés: l'utilisateur a accès à une catégorie dans l'espace co et peut y déposer des documents.
Par contre, il ne voit toujours pas le doc qui vient d'un autre espace et qui a été mis dans la catégorie de l'espace co qui lui est accessible.
Si je décatégorise le document de ses catégories d'origine dans l'espace de travail d'origine et que je ne laisse que la catégorie de l'espace co (mais je laisse les deux espace de travail) , alors, là, l'utilisateur voit le document dans la catégorie de l'espace co.
Il semble donc y avoir un souci avec les catégories d'origine qui semble empêcher l'utilisateur d'accéder au document et ce, même si on ajoute une catégorie au document dans le nouvel espace de travail.
Merci.
Cordialement.
3 votes :
Merci François-Xavier Trolliard pour votre analyse. Pour vous apporter une réponse, une correction ou une amélioration de la solution, merci de créer une nouvelle requête dans votre espace support dédié. Ce ticket permettra d'échanger de manière plus personnalisée vis à vis de votre paramétrage, peut être vos données de manière plus sécurisée. A très bientôt
3 votes :
Bonjour à tous,
Pour continuer cette discussion sur la combinaison entre ces 2 fonctionnalités (module categoryRight et le Partage avec un autre espace), nous sommes tombés sur 2 cas de figure qui nous ont étonné et sur lesquels, je trouverais intéressant de trouver une explication (ou justification ?) collectivement.
je vous partage ces 2 scenario avec le comportement observé et celui que nous aurions spontanément attendu.
Scenario 1
Un espace A privé auquel accèdent les utilisateurs U1 et U2
Un espace B privé auquel accèdent les utilisateurs U1 et U3
Le module categoryRight est paramétré sur la racine de tous les espaces collaboratifs.
Dans l'espace A, on met des droits de consultation sur une catégorie "A - catégorie confidentielle" pour ne permettre la consultation qu'à U1.
Un document est déposé dans l'espace A dans une catégorie quelconque (sans droit de consultation dessus).
A ce stade, U1 et U2 peuvent le consulter. U3 ne peut pas car il n'accède pas à l'espace A.
Je rajoute à ce document la catégorie "A - catégorie confidentielle".
A ce stade, il n'y a plus que U1 qui peut le consulter car U2 n'a pas accès à la catégorie qui est de fait incluse dans l'arborescence soumise au module categoryRight.
Si U1 partage le document dans l'espace B (avec la fonction "partager dans un autre espace") et qu'il catégorise le document dans une catégorie quelconque (sans droits de consultation) de l'espace B, alors :
- U1, U2 ET U3 accèdent au document.
- U1 car il a les droits partout.
- U2 et U3 car le blocage lié aux droits de consultation sur la catégorie "A - catégorie confidentielle" + le module categoryRight sautent du fait que le contenu est également catégorisé dans une catégorie non protégée (cf. le comportement du module categoryRight.
Je comprends que U3 accèdent au document, il me semble que c'est bien le principe attendu pour la fonctionnalité de partage avec un autre espace.
Cependant, je ne comprends pas pourquoi U2 récupère ce droit car il n'accède pas à la catégorie associée au document dans l'espace B (car il n'accède pas à l'espace B).
Scenario 2 (à dérouler sans lien avec le scenario 1) :
Un espace A privé auquel accèdent les utilisateurs U1 et U2
Un espace B privé auquel accèdent les utilisateurs U1 et U3
Le module categoryRight est paramétré sur la racine de tous les espaces collaboratifs.
Un document est déposé dans l'espace A dans une catégorie quelconque (sans droit de consultation dessus).
A ce stade, U1 et U2 peuvent le consulter. U3 ne peut pas car il n'accède pas à l'espace A.
Dans l'espace B, on met des droits de consultation sur une catégorie "B - catégorie confidentielle" pour ne permettre la consultation qu'à U1.
Si U1 partage le document dans l'espace B (avec la fonction "partager dans un autre espace") et qu'il catégorise le document dans la catégorie "B - catégorie confidentielle", alors :
- U1, U2 ET U3 accèdent au document.
- U1 car il a les droits partout.
- U2 et U3 car le blocage lié aux droits de consultation sur la catégorie "B - catégorie confidentielle" + le module categoryRight sautent du fait que le contenu est également catégorisé dans une catégorie non protégée (cf. le comportement du module categoryRight).
Alors que U1 doit sans doute s'attendre que le document ne soit pas partagé aux autres utilisateurs de l'espace B (car il a mis des droits sur la catégorie dans laquelle il a catégorisé le contenu).
Je comprends que U2 accèdent au document car dans son périmètre d'accès (espace A), il n'y a pas de droits de consultation qui s'appliquent.
Cependant, je ne comprends pas pourquoi U3 accède au document car il n'accède pas à la catégorie associée au document dans l'espace B (car il y a des droits de consultation dessus).
En espérant que certains parmi vous auront la force de se plonger dans ces 2 situations, notamment Olivier Dedieu .
1 vote :
cedric tremintin Bravo pour vos scénarios très clairs.
J'avoue que de prime abord, je partage vos attentes et votre étonnement. J'ai peu de piste à proposer malheureusement.
J'irais dans un premier temps étudier la configuration des groupes d'espace dans lesquels se trouvent vos utilisateurs.
Si rien n'est défini comme catégorie dans "droits d'usages", est-ce que cela changerait quelque chose de cocher par ex. la racine des documents de l'espace pour tenter de limiter explicitement le périmètre des droits d'usage des catégories ?
3 votes :
Bonjour cedric tremintin ,
J'ai eu le même questionnement chez mon client.
Voici la réponse du support :
Il faut bien prendre en considération qu'une catégorie est un objet transverse et elle n'appartient pas à un Espace, par contre un Espace peut appartenir à une catégorie, pour résumer, ce n'est pas parce qu'un Espace est privé que la catégorie l'est, par contre une catégorie qui est paramétrée avec une visibilité restreinte via CategoryRigth alors tout ce qui sera contenu dans cette catégorie sera régi par la règle imposée.
Bonjour,
Pour info, le scénario qu'a déroulé cedric tremintin dans le commentaire 64 fait désormais l'objet d'un ticket de support.
La réponse qu'a apportée Sébastien Thorel est la bonne explication : les catégories "n'appartiennent" pas aux espaces, elles sont transversales. Dans le cadre du Module CategoryRights (CR), les droits de consultation affectés aux catégories (régies par ce module) s'appliquent partout, dans tous les espaces, indépendamment des (droits relatifs aux) espaces concernés. De même, la "subtilité" de CR face aux catégories régies mais n'ayant pas de droits de consultation (cf. la KB Pourquoi certaines publications ne sont pas protégées par le Module Category Rights ?), s'applique partout.
Pour certains scénarios cependant (empêcher une publication de devenir invisible aux membres de son espace d'origine E1, parce qu'elle a été partagée dans un espace E2 et une catégorie C2 de E2, régie par CR), une amélioration est prévue : CRP-20 - Do not control publications shared from another workspace.
Merci à tous pour vos réactions.
Frédéric Touitou, par rapport à ton commentaire, j'ai 2 questions :
- ok pour le traitement du cas que tu cites "empêcher une publication de devenir invisible aux membres de son espace d'origine E1, parce qu'elle a été partagée dans un espace E2 et une catégorie C2 de E2, régie par CR". Mais est-ce que ce contournement permettra aussi de traiter le cas suivant :
- empêcher que le partage d'une publication dans un nouvel espace E2 et dans une catégorie "confidentielle" (= avec droits de consultation + soumis au module CR) rende le contenu visible aux membres de son espace partagé E2, parce qu'elle est déjà publiée dans un espace E1 et une catégorie C1 de E1, régie par CR
- le ticket que tu pointes date déjà d'Aout 2020. A quelle échéance peut-on espérer avoir ce correctif déployable chez nos clients ?
- Sur certains des projets que je suis, ce sujet est assez critique car ces 2 situations portent atteinte à la confiance des utilisateurs sur la gestion de la confidentialités de leurs contenus.
Quoi qu'il en soit, encore merci pour votre réactivité !
2 votes :
cedric tremintin : de rien. 😀
Le "cas suivant" que tu as décrit dans le commentaire précédent n'entre pas dans le cadre de l'amélioration CRP-20 - Do not control publications shared from another workspace : si C1, régie par CR, ne possède pas de droit de consultation, tous les membres de E2 auront accès à la publication partagée.
Concernant la date d'implémentation de CRP-20, il n'y a pas encore d'infos précises.
Cependant, indépendamment de CRP-20, le mieux si possible (et notamment si C1 n'est utilisée que dans E1) est de placer le groupe des participants à E1 dans les droits de consultation de C1. A ce moment-là, en supposant que les droits de consultation de la catégorie "confidentielle" ne s'appliquent qu'à des membres de E2 :
- Les membres appartenant à "E1 seulement" auront toujours accès à la publication partagée ;
- Les membres appartenant "à la fois à E1 et E2" pourront accéder à la publication depuis n'importe lequel de ces deux espaces, indépendamment des droits associés à la catégorie "confidentielle".
- Les membres appartenant à "E2 seulement" auront accès la publication partagée s'ils satisfont aux droits de consultation de la catégorie "confidentielle".
J'avoue cependant qu'à force de réfléchir à ces scénarios, mes yeux commencent à se méler un peu les cils, et que je peux me tromper. 😉
Qu'en penses-tu ?
2 votes :
Je crois comprendre en lisant ce dernier commentaire qu'il y a donc une solution de contournement aux difficultés rencontrées en termes d'usages (et de simple compréhension du fonctionnement de JPlatform) du fait de la conception des catégories qui "n'appartiennent" pas aux espaces.
La solution de contournement revient à mettre des droits sur la catégorie à partir d'un groupe de l'espace E1 qui contient tous ses membres : cela n'apporte pas de droits supplémentaires aux membres de E1 car par défaut les catégories sans droits leur étaient visibles, mais cela permet que les partages ne viennent pas remettre en cause cette visibilité.
C'est ça ?
2 votes :
Mickaël POIROUX : Oui, c'est bien ça.
2 votes :
Merci pour vos retours.
Mon point n'est pas tant de trouver une solution à un cas particulier (celui que j'identifie et pour lequel j'ai les droits) que de trouver une solution auto-portante qui s'appliquerait sans trop d'efforts à toutes les situations et qui surtout serait lisible (et donc facteur de confiance) par tous les utilisateurs de la plateforme.
Oui, une solution partielle serait bien de positionner des droits de consultation sur la catégorie racine de l'espace collaboratif avec le groupe incluant tous les membres de l'espace (encore faut-il qu'il y en ait un, certaines situations / plateformes clientes n'en prévoient pas).
Cependant,
- Cette solution devient complexe et lourde à mettre en oeuvre pour les plateformes ayant un passif important.
- Pour les espaces futurs, cela peut être implémentés dans les modèles d'espace collaboratif, sauf dans le cas où ceux-ci inclueraient des catégories communes (justement le cas qui m'a permis de détecter le soucis décrit dans mon message d'hier). Dans ce cas, il faudrait reprendre manuellement les droits appliqués à la catégorie commune à chaque instanciation d'espace.
- Solution de contournement : mettre un groupe parent transverse et commun à tous les groupes incluant tous les participants des espaces collaboratifs concernés et l'inclure dans les droits de consultation de la catégorie. Mais on commence à s'approcher d'une usine à gaz...
Bref, à lire la réactivité des commentaires ci-dessus + les réactions chez certains de mes clients à l'annonce de ce point dont je viens de me rendre compte, je trouve que cela mériterait d'apporter une solution de contournement en standard sans impliquer une grosse dose de paramétrage.
1 vote :
cedric tremintin Je partage totalement vos attentes quant aux scénarios exposés, d'autant que nous n'utilisons pas de catégories transversales entre espaces co dans notre contexte. En étant une évolution de JPlatform, je souhaitai m'assurer de l'existence de cette solution de contournement, pas pleinement satisfaisante, mais qui peut dépanner.
1 vote :
Pardon Mickaël POIROUX , je ne voulais pas porter un jugement sur votre commentaire en disant cela. Toute contribution est bonne et fais avancer la réflexion bien évidemment.
Je voulais avant tout partager le fait que certains contexte méritaient certainement une adaptation structurelle du comportement natif de ces fonctionnalités.
3 votes :
Bonjour,
Pourquoi n'est -il pas possible de partager dans un autre espace, des documents en masse via le panier ? Le champ Espace de rattachement n'apparait pas dans l'onglet Avancé, m^me pour l'admin central de la plateforme
Bonjour Hélène Haddad, notre vision du partage de contenu inter-espaces est qu'il s'agit d'une manipulation unitaire, c'est la raison pour laquelle cette option n'a pas été implémentée dans la gestion du panier. N'hésitez cependant pas à proposer cette idée d'évolution du fonctionnement du panier dans notre boîte à idées dédiée à l'innovation participative : Idées & Questions
1 vote :
Je partage le poind de vue Hélène Haddad
Par exemple, nous nous en servons pour les commissaires aux comptes, on partage de nombreux document dans un espace dédié au controle.
L'aspect unitaire peut être génant.
Bonjour Hélène Haddad,
Notre société Wisen a développé un module rajoutant plusieurs fonctionnalités au panier standard JPlatform, dont le partage dans d'autres espaces.
Si vous êtes intéressée, vous pouvez nous contacter à l'adresse contact@wisen.fr.
Bonjour Florian Dall'Agnese
Peux-tu revenir vers moi sur ce topic, j'ai des besoins de partage de document entre espace n'ayant pas les mêmes membres (CSE)
Merci de ton retour,
Charlie Delanneau bonjour, pour info.
Bonne journée
