Améliorateur de modérateurs de catégorie

|||
-|-|-|
:information_source: | Résumé | Permettre la plupart des actions de niveau modérateur pour les modérateurs de catégorie
:hammer_and_wrench: | Lien du dépôt | Github
:open_book: | Guide d’installation | Comment installer des plugins dans Discourse


Mise à jour - 6 mai 2024

Le plugin a été mis à jour et testé pour fonctionner avec Discourse v3.2.1, qui est actuellement la dernière version stable (non bêta). Nous visons à ne prendre en charge que les futures versions stables, ce qui signifie que si vous utilisez une version bêta, il y a de fortes chances que ce plugin ne fonctionne pas.

Sur le lien GitHub du plugin, le fichier README explique comment s’assurer d’être sur la version v3.2.1.
Nous venons de rétrograder de la dernière version bêta à la v3.2.1 et le seul problème que nous avons rencontré est que la barre latérale devient un peu folle. Pour résoudre ce problème, il suffit de se déconnecter et de se reconnecter.

Avec cette mise à jour, nous avons également inclus le « changement de propriétaire » aux actions disponibles pour les modérateurs de catégorie, comme cela avait été demandé il y a quelque temps.

Version de Discourse prise en charge

v3.2.1

Demande de fonctionnalité pour Discourse

Une demande de fonctionnalité pour intégrer ces fonctions est ouverte ici. N’hésitez pas à la soutenir si vous pensez qu’il serait utile d’inclure ces changements dans les fonctionnalités de base de Discourse.

Fonctionnalités

Depuis que nous avons commencé à utiliser Discourse, nous avons trouvé que les actions disponibles pour les modérateurs de catégorie étaient décevantes. La plupart des actions de base sur le contenu sont limitées (définir le mode lent, ajouter une couleur/une notice pour le personnel, etc.) alors qu’il n’y a vraiment aucune raison à notre avis.

Nous avons donc décidé de tenter notre chance et de créer un plugin qui accorderait la plupart des pouvoirs de modération liés au contenu aux modérateurs de catégorie, lorsqu’ils se trouvent dans la catégorie à laquelle ils ont été assignés.

Ce sont les seules exclusions :

  • Les modérateurs de catégorie ne peuvent pas agir sur les utilisateurs - La suspension, le silence, le changement de niveau d’utilisateur (TL), l’accès à la vue d’administration sur les utilisateurs sont toujours réservés aux modérateurs réguliers.
  • Accorder des badges - nécessite certaines permissions d’administrateur avec lesquelles nous avons préféré ne pas interférer.
  • Afficher l’historique de modération - nécessite certaines permissions d’administrateur avec lesquelles nous avons préféré ne pas interférer.
  • Convertir les sujets en messages privés et vice versa - Nous avons considéré cette action comme un cas de niche et avons préféré la laisser aux modérateurs réguliers du forum.

Configuration

Installez simplement le plugin comme vous le feriez pour n’importe quel autre et cochez la case dans les paramètres pour l’activer.

CHANGELOG

  • Version Bêta initiale
  • Version mise à jour fonctionnant avec Discourse v3.2.1

À FAIRE

  • Vue détaillée des paramètres permettant de choisir les actions à activer pour les modérateurs de catégorie
16 « J'aime »

Vous n’en voyez aucune raison, ou pour votre cas ?

Nous l’utilisons parfois sur meta. Par exemple, si un plugin ou un thème/composant initialement développé par quelqu’un qui n’y travaille plus est transféré à quelqu’un d’autre, nous changeons l’auteur pour le nouveau mainteneur, ou pour @system, selon le contexte.

2 « J'aime »

Je me suis mal exprimé, c’est corrigé. Dans la TODO, il y a d’ailleurs la possibilité d’activer cette fonctionnalité en option.

Dans notre communauté, cela deviendrait simplement un post wiki afin que tout le monde puisse y contribuer. Cela a du sens dans l’exemple que vous spécifiez, mais pour notre forum, le seul cas similaire serait un guide pour quelque chose (auto-hébergement de quelque chose avec un raspberry-pi, un guide de jeu, une liste d’événements pour un groupe, etc. etc.).

3 « J'aime »

Voici un exemple d’utilisation : avec le plugin WordPress, les utilisateurs doivent être configurés individuellement avec un nom d’utilisateur Discourse — même si l’authentification unique garantit qu’ils sont 1:1. Si quelqu’un oublie ou configure mal le côté WordPress, la publication finit par être détenue par « system ».

Permettre aux modérateurs WordPress d’être des modérateurs de catégorie pour la catégorie des commentaires de blog leur permettrait de s’en occuper (et, bien sûr, de modérer les commentaires).

Est-ce que ce cas d’utilisation majeur est que vous ne voulez pas que les modérateurs de catégorie soient tl4 ?

Je suis très ouvert à simplement améliorer le cœur ici.

9 « J'aime »

Pour ma part, j’aimerais faire une distinction entre :

  • être reconnu par une communauté de discussion comme un participant responsable, productif et constructif, et
  • avoir la responsabilité et le pouvoir sur un certain domaine en vertu d’un rôle (un rôle éventuellement sans rapport avec la participation générale à la discussion)

Le TL3 est une version automatisée du premier, et le TL4 me semble être une sorte de version « vous avez obtenu la permanence ! » de celui-ci.

Le modérateur de catégorie est (ou devrait l’être !) parfait pour le second.

3 « J'aime »

Les TL4 s’appliquent à l’ensemble du forum. Dans notre esprit, un modérateur de catégorie devrait avoir accès à tous les outils d’un modérateur, mais être limité uniquement par la catégorie elle-même.

C’est une opinion personnelle, mais il ne nous semble pas logique que les utilisateurs ayant un TL élevé aient plus de pouvoir que les modérateurs de catégorie lorsqu’il s’agit de modérer une catégorie.

Les TL4, à mon avis, sont bien tels qu’ils sont, car ils peuvent effectivement modérer l’ensemble du forum mais pas agir sur les utilisateurs.
Ce sont essentiellement des utilisateurs de confiance, reconnus par la communauté pour la protéger et la favoriser, sans le risque qu’ils deviennent fous un jour en agissant sur les comptes d’autres utilisateurs.

Les modérateurs de catégorie, encore une fois, selon notre point de vue, devraient être capables de faire ce que fait un modérateur, mais dans leur propre catégorie. Cela inclut même l’interdiction de personnes, mais cela relève d’un tout autre niveau de complexité.

Ce à quoi je pensais, c’est de créer un groupe d’utilisateurs comme « banned_from_categoryslug », auquel la catégorie serait attribuée en lecture seule, ainsi qu’aux utilisateurs qui y sont ajoutés.

Alternativement, il suffirait d’étendre les utilisateurs en utilisant la table dédiée dans la base de données dans laquelle vous ajoutez un user_id, un category_id et un datetime. Chaque fois qu’un utilisateur accède à un sujet, une vérification est effectuée pour voir s’il peut réellement interagir avec celui-ci ou non.

L’avantage de passer par une approche basée sur les groupes est qu’il existe une forme d’interface utilisateur déjà implémentée pour les administrateurs et les modérateurs du forum afin de éventuellement lever une interdiction. L’autre approche nécessiterait également de développer une vue dédiée, mais offrirait plus de flexibilité (voir les expirations d’interdiction, etc.).

8 « J'aime »

Alors, quels sont les avantages ajoutés ?

Déplacer des sujets vers d’autres catégories contrôlées par le groupe ?
Examiner la file d’attente des drapeaux ?

1 « J'aime »

Je ne suis pas sûr que ce soit une direction que Discourse veuille prendre, mais si les modérateurs de catégorie avaient ce genre de pouvoir, cela ouvrirait la possibilité d’utiliser les catégories comme des forums dans un forum. Ce serait formidable de mon point de vue.

7 « J'aime »

Je pense que les propriétaires de groupe peuvent supprimer des personnes du groupe, ce qui leur retirerait alors l’accès à la catégorie (si elle est restreinte au groupe). Donc, peut-être qu’une combinaison de propriétaire de groupe + modérateur de catégorie fonctionnerait pour cela ?

3 « J'aime »

Pourriez-vous s’il vous plaît clarifier exactement ce que cela change pour les modérateurs de catégorie. Merci beaucoup.

Étant donné l’affirmation « ce sont les seules exclusions », tout ce qui se trouve sur Trust Level Permissions Reference où la colonne Modérateur de catégorie indique « TL » ou est vide deviendrait :white_check_mark:, à l’exception de l’attribution de badges, du changement de propriétaire et des actions sur le compte utilisateur.

J’aimerais vraiment voir un contrôle plus granulaire — ou mieux encore, que ce contrôle granulaire ne soit pas un plugin mais intégré. Pour moi, le manque de capacité à changer de propriétaire (ironiquement l’une des exclusions, je sais) est le point important — mais évidemment pas pour tout le monde.

3 « J'aime »

100% d’accord. :heart:

Cela peut effectivement fonctionner. J’ai mis en place une configuration selon ce modèle et j’ai participé à la discussion sur le HTML/Markdown concernant l’affichage du message si l’utilisateur ne peut pas poster, afin de générer un message avec un lien vers les propriétaires du groupe.

Bien que cela fonctionne, une meilleure option serait d’ajouter une option de liste de bannissement/silencement avec des options de durée pour les propriétaires de groupe. Un utilisateur problématique pourrait alors être banni de l’accès à la catégorie du groupe. Tout en conservant une option pour que le groupe reste non restreint afin de pouvoir rejoindre ou quitter librement. Même dans un groupe restreint, cette liste pourrait peut-être être étendue pour notifier l’utilisateur qu’il a été banni du groupe, avec une note de bannissement.


Note Nous pourrions probablement lancer une demande de fonctionnalité Contribute pour étendre les fonctions de groupe et permettre un système de sous-forum de type Reddit en utilisant les modérateurs de catégorie… car @simon semble également s’y intéresser.

2 « J'aime »

Croyez-moi, j’aimerais beaucoup cela aussi de la part de Discourse. Il a été incroyablement ennuyeux que quelqu’un travaille sur le style du forum mais que je doive tester les changements moi-même car je ne pouvais pas simplement donner un accès COMPLET d’administrateur à une personne qui était censée travailler uniquement sur le CSS et les visuels.

Nous pouvons examiner cela. Il est vrai que nous avons simplement négligé cela parce que nous n’avions pas pensé à une application (les modérateurs réguliers de l’ensemble du forum peuvent le faire éventuellement).

Dans l’ensemble, je retirerais volontiers ce plugin si Discourse implémentait un contrôle plus granulaire et j’aimerais que le modérateur de catégorie puisse interdire des personnes de sa catégorie uniquement, mais malheureusement, cela ne semble pas être une priorité ni quelque chose qui les intéresse pour le moment.

1 « J'aime »

Je ne pense pas pouvoir trouver la section #contribute:demande de fonctionnalité pour ces modifications ? Si vous pouviez la lier dans le premier message, cela pourrait aider à attirer davantage d’attention dessus ?

2 « J'aime »

Ce pourrait être une bonne idée que je lance, ou que quelqu’un d’autre prenne en charge, l’extension des groupes.

Par exemple :

  • Liste de suspension/bannissement pour les propriétaires de groupe. Pratique pour les groupes à adhésion libre et ceux nécessitant une demande d’adhésion. Il faudrait ajouter une option de durée. Cette extension contribuerait à renforcer la parité avec le thème « Reddit ».
  • Customization > Theme avec option pour restreindre le thème et/ou Customization > Theme component

Actuellement, j’utilise l’option « demande d’adhésion » pour les groupes et le plugin de modèles pour disposer d’une liste de bannissement à consulter.

Apparemment, l’un des derniers changements

Nouvelle option Réviser pour les publications mises en file d’attente
Les modérateurs peuvent désormais sélectionner « Réviser… » comme option lors de la révision des publications mises en file d’attente pour approbation. Un message privé sera envoyé à l’utilisateur avec la raison de la demande de révision et des commentaires facultatifs afin qu’il ait la possibilité d’améliorer sa publication lorsqu’il la soumettra à nouveau.

A-t-il fait plus que simplement ajouter une nouvelle option car le plugin a cessé de fonctionner. Cela ne casse pas Discourse, d’après ce que nous pouvons voir, mais les options supplémentaires ne sont plus disponibles. C’est toujours amusant quand quelqu’un décide de refactoriser beaucoup de choses en plus d’ajouter une seule nouvelle fonctionnalité :smiley:

Nous essayons de regarder à nouveau le code pour comprendre ce qui a été modifié.

1 « J'aime »

J’avais compris qu’une personne de l’équipe de développement ou proche d’eux avait indiqué que ce n’était pas une priorité ni une direction dans laquelle ils comptaient s’engager, mais peut-être que je me trompe. Je passe juste par là pour le moment ; si quelqu’un souhaite ouvrir une demande de fonctionnalité, n’hésitez pas à faire un lien croisé vers ce sujet afin qu’il apparaisse dans les liens en haut, ou à me mentionner (@) et je mettrai à jour le premier message.

1 « J'aime »

Tu l’as obtenu du PDG, donc je dirais que c’est encourageant :

Si tu souhaites voir ces fonctionnalités intégrées au noyau, il pourrait être utile de soumettre une ou deux demandes de fonctionnalité via Contribute.

3 « J'aime »