Gestion des identités. Lorsque vous utilisez un système externe pour provisionner les utilisateurs et leurs appartenances à des groupes.
@Iceman pourquoi ne pas nous parler du résultat que vous visez, plutôt que de votre solution supposée ?
Gestion des identités. Lorsque vous utilisez un système externe pour provisionner les utilisateurs et leurs appartenances à des groupes.
@Iceman pourquoi ne pas nous parler du résultat que vous visez, plutôt que de votre solution supposée ?
Salut ! Merci de ta réponse.
Bien sûr, la dernière fois j’ai commenté ceci mais je peux ajouter plus de contexte, bien sûr, la situation est la suivante :
Contexte :
Par conséquent :
Problèmes :
Mises à jour
J’espère que mon explication a du sens. ![]()
Merci !
C’est le cas, bien que je me demande si vous ne créez pas simplement des problèmes pour les gens, ce qui entraîne une charge technique considérable. Cacher des catégories par CSS peut les faire disparaître de certaines parties de l’interface utilisateur, mais cela ne les empêchera pas d’ouvrir les pages de catégorie par d’autres moyens.
N’avez-vous pas de CM ou de modération active dans cette communauté ? C’est précisément le genre de scénario où l’élément humain joue un rôle essentiel, et le logiciel doit probablement passer au second plan.
À moins que votre communauté ne soit derrière un paywall, cacher une catégorie publique (qui est probablement visible anonymement) obligera soit ledit utilisateur à créer un faux compte, soit même à outrepasser localement les modifications CSS et à continuer de mal se comporter. Les utilisateurs doivent voir que ce type de comportement inapproprié est abordé de front, d’abord par des demandes polies qui réitèrent vos politiques, puis par des suspensions temporaires (suspension de compte) et enfin par l’élimination complète de leur accès.
Un excellent logiciel ne peut pas combler les lacunes de votre culture. En renforçant les limites et en dénonçant les comportements inappropriés, ces utilisateurs ont une chance de corriger leurs erreurs, les futurs fauteurs de troubles sont dissuadés, et le reste de vos utilisateurs sait que la façon dont ils ont été traités n’est pas acceptable.
Ce n’est pas parce que quelqu’un fait beaucoup de bonnes choses qu’il ne doit pas être puni pour les mauvaises choses qu’il fait, même si cela signifie qu’il ne peut plus faire les bonnes.
Suspendez la personne et si elle continue d’être une mauvaise personne par la suite, expulsez-la.
Non, car, comme l’ont dit Iceman et Gunnar, ces personnes sont « idéales » et « valorisées » dans d’autres catégories.
S’ils étaient prêts à les virer sans cérémonie, ils ne seraient pas ici à chercher des moyens de les accommoder.
J’ai une situation similaire/différente ; nous avons un Discourse qui appartient à un club dont les règles exigent qu’ils aient accès à au moins certaines des Catégories (légalement requis pour pouvoir y accéder.) Mais nous voulons toujours pouvoir exclure les individus problématiques de certaines Catégories.
J’ai ouvert ceci :
… mais je suis toujours ouvert à d’autres solutions possibles.
Alors créez un groupe pour ACCESS_TO_REQUIRED_GROUPS et un autre pour ACCESS_TO_GROUPS_NOT_FOR_JERKS et définissez les autorisations de catégorie en conséquence. Ensuite, ne laissez pas les imbéciles rejoindre l’autre groupe.
Comment cette partie est-elle réalisée ?
Comment configurons-nous des groupes auxquels tout le monde peut adhérer, mais que certaines personnes peuvent être exclues ?
Une solution avec les limitations actuelles de Discourse. Il pourrait être possible de masquer la catégorie dans les profils des utilisateurs.
Créez un composant de thème et masquez le groupe que vous ne voulez pas que les connards voient. Toute personne ajoutée à la liste des connards dans le composant ne verra pas le groupe à rejoindre. Masquez avec CSS. Pour la plupart, cela fonctionnera.
Je pense que pour que cela fonctionne, les membres du groupe de rythme seront accessibles au public.