Voici ce que nous obtenons lorsque nous essayons de créer une sous-catégorie pour les administrateurs (même problème pour les modérateurs) au sein de la catégorie Personnel :
« Tout groupe autorisé à accéder à une sous-catégorie doit également être autorisé à accéder à la catégorie parente. Les groupes suivants ont accès à l’une des sous-catégories, mais pas à la catégorie parente : administrateurs. »
Pourtant :
Les modérateurs ont bien accès à la catégorie Personnel, tout comme les administrateurs. Nous devrions donc pouvoir le faire.
Je suis administrateur d’un autre forum existant depuis plusieurs années, où nous avons des sous-catégories sous Personnel réservées uniquement aux administrateurs ou uniquement aux modérateurs.
Avis ?
[EDIT : juste pour le plaisir, voici une capture d’écran de l’étiquette réelle qui s’affiche lorsque vous essayez de créer une catégorie réservée aux administrateurs :
C’est assez drôle car (a) les administrateurs ont bien accès à la sous-catégorie Personnel, mais aussi (b) les administrateurs peuvent aller partout… Donc, par défaut, ils ont accès à n’importe quelle catégorie.
Et, bien sûr, vous ne pouvez pas modifier la section de sécurité de Personnel pour ajouter spécifiquement les modérateurs et les administrateurs à la catégorie globale.]
Vous devez vous assurer que les sous-catégories que vous créez sont accessibles uniquement au personnel. Vous avez essayé d’en créer une accessible à tous, mais vous n’avez pas remarqué les permissions lors de la création, alors vous ne pensez pas que cela soit vrai.
C’est ce que je pensais, d’où mon message supprimé, mais relisez le message d’erreur :
« Tout groupe autorisé à accéder à une sous-catégorie doit également être autorisé à accéder à la catégorie parente. Les groupes suivants ont accès à l’une des sous-catégories, mais pas à la catégorie parente : modérateurs. »
J’ai donc essayé et rencontré le même problème.
J’essaie de créer une sous-catégorie avec les paramètres de sécurité définis sur « modérateurs : peut voir/publier/créer », mais j’obtiens le même message d’erreur, alors que les modérateurs devraient être inclus dans « personnel » et que la sécurité de la catégorie parente est définie sur « personnel : peut lire/publier/créer ».
Je pense que ce qui se passe est dû au fait que la sécurité est définie par groupes et non par capacités.
Un modérateur appartient à la fois aux groupes staff et modérateurs.
Mais s’il existait une catégorie staff et une sous-catégorie modérateurs, que se passerait-il pour quelqu’un n’appartenant qu’au groupe modérateurs ? Il pourrait accéder à la sous-catégorie mais pas à la catégorie parente, et Discourse ne le permet pas.
En théorie, si vous vouliez rendre une sous-catégorie accessible aux modérateurs, vous auriez ajouté « modérateurs : voir/publier/créer » à la sécurité de la catégorie parente, mais ce n’est pas possible sur la sous-catégorie staff par défaut.
De plus, cela serait inutile, car staff signifie modérateur et administrateur, et les administrateurs ont accès à toutes les catégories.
Quelqu’un devrait vérifier. Mais à mon avis, il serait peut-être possible d’ajouter un utilisateur au groupe de modération sans qu’il possède la classe modérateur.
En revanche, pour le personnel, il faut avoir les droits de modérateur ou d’administrateur.
Oui, mais c’est exactement ce que nous avons fait. Nous avons supprimé les permissions pour « tout le monde », etc., et ne laissons que les administrateurs ou les modérateurs comme groupe autorisé à accéder à la sous-catégorie. Mais cela ne fonctionne pas.
Bien que cela ait été possible auparavant. Et, selon les règles de permissions, cela devrait être possible.
Je pense que c’est peut-être le cas.
Il y a des sujets que seuls les administrateurs peuvent lire en raison de la confidentialité et d’autres contraintes. Nous avons donc besoin de sous-catégories réservées aux administrateurs.
Les sous-catégories pour les modérateurs sont là pour plus de commodité : elles regroupent les discussions sur des sujets liés à la modération dans un espace spécifique. Comme les administrateurs peuvent tout voir de toute façon, nous pourrions les étiqueter pour les modérateurs tout en les rendant accessibles au personnel, et cela fonctionnerait. Cela résoudrait la moitié du problème, bien que, bien sûr, uniquement en trichant.
Mais nous ne pouvons pas résoudre l’autre moitié. Je vais modifier le message initial pour le refléter en ce qui concerne les administrateurs.
C’est incorrect. Les modérateurs peuvent accéder à la catégorie du personnel. Ainsi, avoir une sous-catégorie pour les modérateurs (ou les administrateurs) est (ou devrait être) autorisé par Discourse. La règle est que tout groupe pouvant accéder à une sous-catégorie doit également pouvoir accéder à la catégorie parente.
Mais ce ne serait absolument pas inutile d’avoir une sous-catégorie réservée aux administrateurs, car les modérateurs ne voient pas tout ce que voient les administrateurs.
Lisez attentivement mon message : tel que le système est conçu, il fonctionne correctement et l’erreur que vous avez rencontrée est normale. L’accessibilité du forum dépend uniquement des groupes.
La catégorie « Staff » par défaut, créée automatiquement par Discourse, n’est accessible qu’au groupe Staff.
Si vous souhaitez créer une sous-catégorie pour le groupe Modérateurs, cela ne fonctionnera pas, car la catégorie parente n’est accessible qu’au groupe Staff, et non au groupe Modérateurs.
La seule raison pour laquelle les modérateurs ont accès à la catégorie parente est qu’ils appartiennent également au groupe Staff.
Vous pouvez toujours créer une sous-catégorie nommée « modération » et définir les permissions sur « le personnel peut lire/publier/répondre », cela fonctionnera.
Si, ce le serait, et vous pouvez créer une catégorie ou une sous-catégorie accessible uniquement au groupe Administrateurs sans aucun problème.
Pour être clair : je pense que c’est bien la raison du problème. J’avais initialement pensé à le mentionner comme explication, mais j’ai décidé de poster sans…
Mais, dans ce cas, c’est l’un de ces bugs insidieux où les règles que vous élaborez ne reflètent pas les raisons qui les ont créées. Il est très clair que les modérateurs font partie du personnel, tout comme les administrateurs, et cette raison voudrait qu’ils puissent avoir des sous-catégories au sein de Staff.
Et, en fait, il y a quelques années, il était possible de créer des sous-catégories dans Staff uniquement pour les administrateurs ou « seulement » pour les modérateurs : c’était clairement approprié.
Pourquoi serait-il inutile d’avoir une sous-catégorie uniquement pour les administrateurs ?
Pas dans la catégorie Staff. Regardez la capture d’écran ci-dessus.
Je voulais dire que ce n’est pas inutile, comme tu l’as dit.
Oui, tu as raison.
Si tu veux créer ces sous-catégories, tu devrais créer une catégorie parente « Personnel des actualités » avec les paramètres de sécurité suivants : Administrateurs, Personnel et Modérateurs peuvent lire/publier/créer, je suppose.
Pourquoi ne pas simplement créer une nouvelle catégorie comme mentionné ? Le personnel est un groupe spécialisé.
Je peux ajouter des utilisateurs à plusieurs groupes. Le fait que certains utilisateurs appartiennent au groupe B et fassent peut-être aussi partie du groupe A ne signifie pas que l’accès du groupe A à une catégorie qualifie automatiquement le groupe B pour y accéder. Les permissions de catégorie basées sur les niveaux de confiance fonctionnent, en revanche, à un niveau minimal.
Je ne sais pas, mais imaginez que vous puissiez probablement modifier les permissions du personnel pour permettre au groupe des modérateurs d’avoir un accès direct.
Il n’existe pas de permissions hiérarchiques dans Discourse. Staff est une collection spéciale d’administrateurs et de modérateurs. Les sous-catégories ne peuvent pas spécifier de groupes qui ne sont pas présents sur la catégorie parente, et le groupe Staff possède des ACL fixes. Comme indiqué sur la catégorie Personnel :
Avertissement : Cette catégorie est une catégorie pré-initialisée et les paramètres de sécurité ne peuvent pas être modifiés. Si vous ne souhaitez pas utiliser cette catégorie, supprimez-la plutôt que de la réaffecter.
Ce n’est pas un bug ; vous avez simplement un cas d’usage qui ne correspond pas à la catégorie par défaut de Personnel. Il n’y a rien de mal à vouloir faire quelque chose de différent, mais il serait erroné d’insister sur le fait que, parce que vous ne pouvez pas utiliser une catégorie intégrée à une autre fin, cela constitue en soi un bug.
Il est assez clair que vous ne souhaitez pas l’utiliser tel quel. Rien ne vous empêche de créer une nouvelle catégorie parente accessible aux administrateurs et aux modérateurs, puis des sous-catégories séparées pour chacune en dessous.
C’est un bug extrêmement mineur dans le système d’avertissement des permissions de catégorie, car il ne sait pas que staff équivaut à admins + modérateurs.
Ce n’est pas la peine de perdre 12 posts en débats.
Vous pouvez contourner ce problème en ajoutant explicitement admins et modérateurs en tant que groupes autorisés dans la catégorie parente. Gardez à l’esprit que les administrateurs auront toujours accès à la sous-catégorie modérateurs.
Oui. Mais les modérateurs n’auront pas accès aux sous-catégories administratives.
Oui dans le cas général, mais cela n’est pas possible dans la catégorie Staff qui est créée automatiquement et où les privilèges ne peuvent pas être modifiés, ce qui était le sujet de la question. Puisque (a) la catégorie Staff est automatiquement peuplée dans chaque installation, (b) il est important pour des raisons d’utilisabilité de limiter le nombre de catégories, et (c) la catégorie Staff fonctionnait correctement auparavant, je ne considère pas cela comme une demande déraisonnable.
Ma suggestion est une solution simple. Actuellement, lors de la création automatique de la catégorie Staff, les permissions suivantes sont configurées (et il n’est pas possible de les modifier) :
staff peut créer/répondre/voir
Au lieu de cela, lors de la création automatique de Staff, Discourse devrait avoir les permissions suivantes configurées :
staff peut créer/répondre/voir
admins peuvent créer/répondre/voir
moderators peuvent créer/répondre/voir
Avec cette simple correction, ce bug serait résolu, nous n’aurions pas besoin de créer des catégories supplémentaires et inutiles, et la catégorie Staff fonctionnerait comme elle le faisait auparavant.
Je pense que vos arguments sont inversés : créer une catégorie conçue à cet effet pour vos besoins est beaucoup plus simple que de modifier une catégorie intégrée, surtout lorsque des milliers d’autres installations fonctionnent déjà avec les permissions existantes.
En réalité, si vous lisez attentivement ma solution, vous réaliserez qu’elle est rétrocompatible et permet aux installations précédentes de continuer à fonctionner comme auparavant.
Mais cela n’a rien à voir avec la rétrocompatibilité. Dans ce sujet, vous êtes la seule personne à plaider pour un changement. Ce que vous proposez nécessite toujours du temps de développement, des tests et une maintenance. Le fait que des milliers d’installations fonctionnent avec la configuration actuelle signifie qu’il existe également des milliers d’équipes d’administration et de modération qui n’ont aucun problème avec le statu quo.
Ce sujet a plusieurs mois. Vous auriez pu mettre en œuvre la bonne méthode dès avril. Pourquoi s’attendre à ce que CDCK finance une modification de leur logiciel, qui fonctionne ainsi depuis sept ans, pour un seul site ? Pourquoi devrait-on faire quoi que ce soit si vous n’êtes pas disposé à apporter le changement le plus simple à votre propre configuration ? Votre refus de suivre les recommandations n’incite personne d’autre à agir.
Il n’y a rien de spécial dans la catégorie du personnel. Comme suggéré il y a plusieurs mois, vous pourriez créer une autre catégorie avec les permissions appropriées. Problème résolu.
Il est beaucoup plus simple pour vous d’apporter une petite modification à votre communauté que de faire l’une des options mentionnées ci-dessus.
Ce n’est pas la bonne façon de le faire, mais je l’ai bien implémenté en avril. Nous n’attendons généralement pas que des bogues soient corrigés ou que des fonctionnalités soient mises en œuvre pour mettre nos propres choses en ordre.
Oui, oui et non. J’ai passé de nombreuses années en tant que développeur logiciel et manager, et je suis parfaitement conscient de ce qu’il faut pour corriger un bogue. Cette correction ne prendrait que quelques minutes de développement, quelques heures de test, et ne nécessiterait aucune maintenance supplémentaire par rapport à la version actuelle.
Votre argument signifie qu’il n’y a absolument aucun intérêt à développer quoi que ce soit de nouveau. Il y a des milliers d’équipes utilisant Discourse tel quel — pourquoi passer ne serait-ce qu’une heure de plus à développer ? Utilisons la logique lors de nos débats, s’il vous plaît.
C’était une supposition inutilement grossière, qui est évidemment infondée compte tenu de mes remarques ci-dessus.
En fait, vous avez tort. Cela a fonctionné différemment, et mieux, pendant longtemps. Voici un exemple d’un système Discourse hébergé existant, âgé de 4 à 5 ans, avec une catégorie d’équipe native permettant des sous-catégories pour les modérateurs :
La question n’a rien à voir avec mon système. Je n’ai pas besoin de ce changement pour que cela fonctionne. Le point est que chaque système Discourse est livré avec une catégorie d’équipe qui est inférieure en capacités à ce qu’elle pourrait être, et à ce qu’elle était. Si Discourse prend la peine de créer automatiquement une catégorie d’équipe, pourquoi ne pas la concevoir correctement et proprement ? Je fais une suggestion simple et facile à mettre en œuvre, qui permettra de retrouver des capacités utiles pour ceux d’entre nous qui gèrent plusieurs catégories de personnel. L’équipe est libre de considérer ma suggestion ou non.
Avertissement : Cette catégorie est pré-remplie et les paramètres de sécurité ne peuvent pas être modifiés. Si vous ne souhaitez pas utiliser cette catégorie, supprimez-la plutôt que de la réaffecter.
Il suffit de recréer la catégorie du personnel et de déplacer les sujets vers la nouvelle ?
