We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

Restreindre un billet de blog sur un espace collaboratif

CAROLINE JOLIVET · on 4/21/16 at 10:20 AM

Bonjour,

 

J'ai besoin de restreindre un billet de blog sur un espace collaboratif. Voilà ce qui a donc été fait :

- Création d'une sous catégorie dans "le blog de $NOM DE L ESPACE$

- Droit de consultation renseigné sur la catégorie en question

- ID de la catégorie enregistrée dans le module CATEGORY RIGHT

Le billet de blog demeure visible de tous.

Qu'elle est la marche à suivre?

12 pts
Ronan Kerdudou · on 5/17/16 at 7:04 PM

Au niveau de la configuration du module Category Right, assurez-vous d'avoir renseigné le type BlogPost

ça devrait fonctionner cependant ce n'est pas très recommandé pour des question de performances à long terme que d'utiliser Category Right sur des "UserContent" (surtout si le volume de données du type concerné est important). Notez par ailleurs que le module Blog n'a pas été conçu avec l'idée qu'il soit possible de masquer certains billets par des droits, il est donc possible que vous rencontriez des effets de bord.

0 pts
Jacques SETTON (Cinov Num) · on 7/30/18 at 2:31 PM

Bonjour à tous,

J'ai exactement la même question mais pour une restriction qui serait applicable aux fils de discussion dans un espace de conversations prédéfini (discussions / questions / idées)... En fait, il y a bien une possibilité de masquer certaines des catégories par application de restrictions au niveau des droits de visibilité de celles-ci. Mais les fils de discussions qui s'y trouvent restent toujours visibles, alors que les catégories qui les contiennent sont elles bien masquées...

Faut-il donc, dans ce cas également, bien paramétrer Category Rights comme vous le suggérez pour le billets de Blog ? Dans l'affirmative, sur quel(s) paramètre(s) faut-il agir ?

A noter que si le Blog n'est pas une application qui se prête naturellement à un filtrage de contenus - comme vous l'indiquez justement - il en est tout autre en ce qui concerne les Conversations. En effet, et particulièrement de notre cas de figure, il peut s'avérer nécessaire de faire participer des partenaires externes à des Commissions de Travail conjointes sur une thématique donnée. Dans ce cas, il serait souhaitable de ne pas leur exposer les discussions (internes, externes ou mixtes) sur d'autres sujets (fils) ne concernant pas le thème traité avec tel ou tel partenaire impliqué... 

Merci de votre retour d'information à ce sujet...

Très cordialement,

 Jacques Setton

#1

Les espaces de conversation n'ont pas été conçu pour permettre cet usage, notamment la catégorie positionnée sur une idée, question, ou conversation n'est pas reportée sur les réponses et réactions qui y sont associées.

Il est possible qu'avec CategoryRight le droit de visibilité se propage correctement depuis une catégorie vers l'idée/question/conversation, puis vers les réponses et réactions associées mais je ne garantie rien.

Le mieux serait peut être de créer des espaces de conversations distinct par groupe de personnes sencées échanger ensemble. Le principe de ce composant est la collaboration et les échanges, si on ajoute trop de complexité avec des droits de visibilité sur chaque idée/question/discussion on risque de s'y perdre.

De manière générale, en dehors des informations confidentielles, il est préférable d'avoir accès à plus d'informations même sortant un peu du contexte, et d'impliquer des personnes qui ne soient pas forcement directement impliquée, ainsi on favorise l'émergences de bonnes idées parfois inatendues et profitables à tous.

Ronan Kerdudou · on 7/31/18 at 2:08 PM
0 pts
Jacques SETTON (Cinov Num) · on 7/31/18 at 4:28 PM

@Ronan Kerdudou 

Merci de votre réponse très étayée, suite à laquelle je réagis au sujet de quelques-uns de vos arguments repris ci-dessous...

Les espaces de conversation n'ont pas été conçu pour permettre cet usage, ...

Je le conçois mais, dans ce cas, pourquoi JCMS 10 permet-il de disposer d'une gestion des droits d'accès aux catégories ('fils') de conversations ? Si c'est pour juste masquer certaines catégories mais sans masquer pour autant les 'fils de discussion' qui y sont rattachés, cela ne présente pas beaucoup d'intérêt...

Il est possible qu'avec CategoryRight le droit de visibilité se propage correctement depuis une catégorie vers l'idée/question/conversation, puis vers les réponses et réactions associées mais je ne garantie rien.

CategoryRight (CR) est effectivement activé sur notre plateforme, notamment pour bloquer la visibilité des contenus situés dans l'arborescence descendante d'une catégorie dont l'accès est restreint. Mais cela ne semble par fonctionner ainsi pour les 'fils' (billets) de conversation (je l'ai testé). Y'aurait-il donc un paramètre à activer dans CR pour que cela fonctionne avec les conversations et dont l'effet serait similaire au paramètre BlogPost dans le cas du Blog ? 

Le mieux serait peut être de créer des espaces de conversations distinct par groupe de personnes sensées échanger ensemble...

Ce serait, certes, une option alternative à effectivement considérer. Mais cela peut complexifier la représentation visuelle si chaque module de conversation distinct doit figurer dans le menu du bandeau de navigation de l'espace. Le membres qui participent à plusieurs thèmes de discussion, faisant intervenir des partenaires externes distincts, auront autant d'entrées affichées dans ce menu.  La possibilité de filtrer par 'catégorie' (thème) de discussion serait néanmoins une solution un peu plus élégante...

... il est préférable d'avoir accès à plus d'informations même sortant un peu du contexte, ... ainsi on favorise l'émergence de bonnes idées parfois inattendues et profitables à tous.

Vous avez tout à fait raison s'il s'agit de collecter les avis de tout contributeur sur divers sujets (un peu comme un 'brainstorming'). Mais dans le cas de nos commissions, un Groupe de Travail (GT) se réunit pour discuter d'un thème spécifique. Par exemple, on aurait un GT qui traite de la Formation Professionnelle et un autre de l'Assurance Professionnelle avec la contribution d'experts externes, respectivement désignés sur chacun de ces thèmes qui n'ont aucun rapport entre-eux. En les gardant distincts, chaque GT se focaliserait sur le sujet en question, sans risque de dispersion sur d'autres sujets non concernés... 

#1

Merci pour votre retour, je comprend votre position.

Le fait qu'on puisse saisir des droits sur les catégories est global et ne s'applique par défaut qu'à la visibilité de la catégorie. Il n'y a pas de cas particulier en fonction de l'utilisation qui est faite de la catégorie.

Certains types de contenu, notamment contenu utilisateur comme un commentaire/réponse/réaction, ne sont simplement pas catégorisable, ainsi donc il est difficile de leur appliquer des droits à partir des catégories.

De manière plus générale : pour un besoin spécifique on peut réaliser un développement spécifique, et là dessus le service professionnel Jalios peut certainement vous proposer une solution qui répondra à votre besoin.

Ronan Kerdudou · on 7/31/18 at 6:02 PM
#2

@Ronan Kerdudou 

Ok bien reçu merci, je comprends très bien la limitation que vous décrivez.

On aurait pu imaginer qu'il y'ait une relation de 'dépendance hiérarchique' comme suit (similaire à une arborescence descendante de fichiers dans un répertoire) :

Et en invalidant l'accès à une catégorie de conversation, on aurait pu aussi invalider l'accès à la 'chaîne descendante' de billets, réponses et commentaires associées.

Mais je déduis de votre dernière réponse que ce n'est pas ainsi que le traitement s'effectue et que, du coup, il n'y a donc pas de paramètre dans CategoryRight qui permette de le faire 'en standard'.

Est-ce bien cela ? Merci de votre retour de confirmation finale à ce sujet...

Jacques SETTON (Cinov Num) · on 7/31/18 at 7:30 PM
#3

Je vous confirme que ce développement n'est pas actuellement disponible en standard.

Cette relation entre les objets peut aisément être utilisée dans un RightPolicyFilter pour obtenir le résultat souhaité, c'est ce qui est réalisé dans le module DBComment pour (entre-autre) aservir le droit de consulter le commentaire au droit de consulter la publication associée. Plusieurs autres développements de ce type sont présent dans les modules.

Le développement d'un RightPolicyFilter étant un code sensible je recommande de toujours bien le tester pour la performance et pour la sécurité.

Ronan Kerdudou · on 7/31/18 at 10:35 PM
0 pts