Cependant, il existe des cas d’utilisation pour les grandes communautés comme la mienne, où nous avons littéralement de plus petits forums existant à l’intérieur du forum principal. Pensez aux clans dans la culture du jeu.
Ces sous-communautés adoptent les règles principales du forum, mais ont également des règles supplémentaires spécifiques et une équipe dédiée qui est censée modérer la section ainsi que les diriger, mais c’est hors sujet.
Les modérateurs de catégorie ne peuvent pas agir sur les utilisateurs eux-mêmes, seulement sur la catégorie, cependant, ils devraient, dans mon cas d’utilisation, être capables d’empêcher certains utilisateurs de participer s’ils enfreignent certaines de leurs règles de sous-forum.
Tout ce dont j’ai vraiment besoin, c’est de savoir s’il pourrait y avoir suffisamment de granularité dans les fonctions de base pour permettre aux modérateurs de catégorie de bloquer des utilisateurs spécifiques de l’accès à leur catégorie.
La façon dont je peux l’imaginer, c’est qu’une table personnalisée est générée qui ajoute à la fois l’category_id et l’user_id et lorsqu’un utilisateur tente d’accéder à un sujet ou une catégorie spécifique, il suffit de vérifier également cette table.
Suis-je complètement à côté de la plaque ? Serait-ce faisable ? J’ai beaucoup d’expérience en développement logiciel mais presque rien en Ruby, donc je ne sais pas vraiment par où commencer à chercher dans le code source de Discourse pour comprendre où je devrais regarder
Vous pourriez autoriser uniquement les membres de la catégorie du clan à publier et supprimer les utilisateurs que vous ne souhaitez pas voir dans la catégorie. Cela nécessiterait que toutes les personnes que vous souhaitez dans la catégorie soient membres de ce groupe.
J’ai fait la même chose. Et comme je ne laisse personne dépasser automatiquement TL2, c’était une solution mentalement et administrativement très facile et simple. Il y avait aussi une touche d’élégance
J’ai fait cela pour un client il y a quelque temps. Les niveaux de confiance n’allaient pas fonctionner pour nous, alors nous avons plutôt créé des groupes privés par catégorie dans lesquels chaque utilisateur était automatiquement provisionné, et les modérateurs de catégorie en étaient les propriétaires.
Les « bannissements » consistaient simplement à supprimer ces adhésions, ce qui signifiait zéro travail de la part de l’administration.
Un peu plus d’efforts pour commencer, mais pratiquement zéro par la suite.
Exemple : un de mes clients a un forum avec une catégorie « À Vendre », accessible à partir du niveau TL2.
Ils veulent interdire à certains membres de créer des sujets là-bas, mais ils devraient copier et maintenir un groupe contenant les mêmes personnes que le niveau TL2 moins 5 utilisateurs spécifiques.
Probablement de la même manière, provisionner des utilisateurs dans des groupes en fonction d’un critère (détection de promotion vers TL2 ?) puis les supprimer si nécessaire ? Ce n’est pas parce que TL2 est le critère d’entrée que vous devez vous fier à ce statut TL2 pour déterminer l’appartenance, n’est-ce pas ? Cela dépend aussi si vous avez le temps et les ressources pour concevoir quelque chose sur/autour de votre instance.
Je n’ai pas suggéré que c’était une solution miracle pour tous. Cela peut ne pas fonctionner pour leur cas d’utilisation s’ils ne veulent pas faire le travail supplémentaire, mais pour l’exemple avec mon client et le scénario où une instance est partitionnée en guildes/clans/autre, cela pourrait être une bonne solution.
Mais si nous concevons quelque chose sur l’instance de toute façon, alors je préférerais avoir une fonctionnalité de bannissement de catégorie
Cela rend également les choses plus maintenables. Si j’ai 50 000 utilisateurs et que je veux que tous puissent accéder à la catégorie sauf quelques-uns, alors il est difficile d’obtenir une liste de ces quelques-uns.
Je veux dire, bannir n’est qu’un autre mot pour exclusion, et Discourse n’a pas vraiment de permission d’exclure. Faut-il qu’elle existe quand « ne pas inclure » est effectivement la même chose ? J’aime le modèle de permis explicite, il rend le dépannage sans douleur.
J’ai encore des cauchemars occasionnels à essayer de résoudre le modèle permis/refus de vBulletin il y a toutes ces années. La seule chose que j’ai expérimentée avec plus de douleur et de dettes associées est RSOP.
J’apprécie toutes les suggestions de solutions alternatives, mais j’ai posé une question technique spécifique, pas des alternatives qui sont des compromis par rapport à ce que j’essaie de comprendre
@crius ce serait faisable avec un plugin, je pense que vous pouvez aller assez loin côté client en remplaçant les permissions dans le sérialiseur de catégorie, et côté serveur en ajoutant une vérification supplémentaire en utilisant NewPostManager.add_handler.
Avez-vous envisagé d’utiliser des groupes ? Créez une catégorie avec 2 groupes pour l’accès. 1 groupe est vos modérateurs de catégorie. L’autre est vos participants au sous-forum. Le groupe de participants est tenu de demander l’accès à la zone du sous-forum. Vos modérateurs de catégorie, en tout ou en partie, sont propriétaires de ce groupe. Si un membre enfreint les règles nécessitant de le bannir du sous-forum. Bannissez-le du groupe de participants et communiquez avec les autres modérateurs de catégorie sur la durée.
Eh bien, malheureusement, vous devrez peut-être envisager de parrainer un plugin. C’est là que le financement participatif de plugins serait un excellent concept. L’équipe principale pourrait éventuellement ajouter quelque chose comme ce que vous demandez, mais cela pourrait prendre du temps en raison des priorités de la liste de développement.
D’un autre côté, avec la suggestion de groupe, il serait peut-être possible d’ajouter une option de bannissement de groupe avec un composant de thème.
Es-tu absolument sûr d’avoir posé la bonne question
Je veux dire que ton objectif principal est de résoudre un problème, et la catégorie d’interdiction n’est qu’une réponse non résolue pour cela. La bonne question serait comment résoudre le problème X et quelles sont mes options.
J’ai évalué la possibilité de gérer cela avec des groupes TL ou des groupes d’utilisateurs, mais cela augmentera la charge de travail des modérateurs, ce qui n’est tout simplement pas réalisable dans les grandes communautés.
Les groupes d’utilisateurs sont particulièrement préjudiciables à une expérience utilisateur allégée.
Je n’ai pas besoin de demander un parrainage car j’ai beaucoup d’expérience en tant qu’ingénieur logiciel et d’autres personnes qui ont également beaucoup d’expérience. Nous n’utilisons tout simplement pas Ruby, ce sera donc le seul ralentissement.
Merci pour vos commentaires de toute façon. J’apprécie que ce forum ait tendance à être très dogmatique, mais en ce qui concerne le logiciel lui-même, il serait préférable de simplement suivre une approche qui consiste davantage à « donner l’option », avec bien sûr une complexité de code supplémentaire étant de l’autre côté de la balance.
Beaucoup d’amour à @RGJ pour avoir apporté un éclairage
