Maintenant que nous pouvons accorder à des groupes spécifiques l’accès aux murmures, nous sommes très proches de pouvoir supprimer l’accès modérateur pour la plupart de nos utilisateurs internes.
Et, lorsque nous avons commencé à supprimer l’accès, nous avons réalisé qu’il nous manquait une dernière pièce et avons dû annuler le changement. Nous utilisons beaucoup les affectations (aux utilisateurs et aux groupes) dans notre organisation.
Tout cela est « caché » à notre communauté d’utilisateurs. Cela nous convient parfaitement, car parfois nous affectons des fils de discussion à un groupe parce que…
nous transmettons simplement des commentaires (pour information)
nous avons besoin qu’une action soit entreprise
nous ne savons pas si une action doit être entreprise (et le groupe le découvrira une fois qu’il l’aura vu)
Les utilisateurs internes sont autorisés à affecter des fils de discussion à d’autres groupes de l’organisation.
Ce que nous avons réalisé, en commençant à révoquer l’accès modérateur, c’est que la visibilité des groupes et la capacité d’affecter aux groupes ne peuvent être ouvertes qu’à « uniquement les membres du groupe, les modérateurs et les administrateurs » avant que nous devions autoriser les utilisateurs non internes à voir et affecter aux groupes.
Ce serait formidable si ces autorisations pouvaient également être définies au niveau du groupe. Pour nous, c’est la dernière pièce manquante.
Ce qui nous motive :
Je pense qu’il est important de mentionner pourquoi nous entreprenons ce voyage.
Nous avons environ 170 modérateurs sur notre instance. Ces utilisateurs n’ont pas besoin d’accéder aux adresses e-mail et aux adresses IP de nos utilisateurs. Surtout à mesure que notre organisation grandit, il semble risqué que ces informations soient disponibles pour tout le monde.
Juste à titre d’information, en dehors de la demande de fonctionnalité principale, le paramètre d’administration les modérateurs voient les e-mails aide-t-il à résoudre ce problème ?
Pour être honnête, je n’avais aucune idée que cette option existait – et en fait, elle est désactivée sur notre instance ! J’ai usurpé l’identité d’un autre modérateur sur notre instance et en effet, il ne peut pas voir les adresses e-mail.
Je jure que j’avais accès pour voir les e-mails quand j’étais « seulement » un modérateur (pas un administrateur) – peut-être avions-nous un réglage différent à l’époque (notre instance a connu un sacré parcours ces 8 derniers mois).
Merci beaucoup de l’avoir signalé.
Cela supprime donc une certaine urgence – et en général, j’aimerais toujours voir la plateforme continuer à évoluer vers des autorisations flexibles basées sur des groupes plutôt que ces options plus rigides.
Nous travaillons également sur un problème similaire chez Discourse, en fait je n’ai pas d’accès admin/modérateur sur notre instance de développement. J’entends tout à fait les avantages considérables de maintenir un faible nombre d’administrateurs/modérateurs.
Pouvez-vous expliquer le problème ?
En gardant à l’esprit qu’il existe quelques éléments de base sur lesquels vous pouvez vous appuyer :
Modération de catégorie, vous pouvez définir la modération sur des catégories spécifiques à des groupes spécifiques. Cela permet aux utilisateurs de confiance d’avoir plus de flexibilité.
Système de niveaux de confiance… à TL4 (manuel) beaucoup de choses se débloquent.
Paramètre du site assign allowed on groups (qui débloque l’attribution pour des groupes spécifiques)
Nous avons un tas d’équipes différentes dans notre entreprise qui contribuent à notre communauté en tant qu’experts pour la partie de notre produit dont elles sont responsables. Un groupe est créé pour chaque équipe, et lorsque l’expertise d’une équipe est requise sur un sujet, le sujet est attribué à l’équipe (et généralement ensuite attribué à un individu, qui se désassigne lorsqu’il a apporté toute sa contribution).
Nous ne voulons pas révéler à nos utilisateurs comment tout cela fonctionne. Nous essayons de maintenir les attentes basses (il s’agit d’un support gratuit que nous offrons à nos utilisateurs open source), nous ne voulons pas que les utilisateurs commencent à demander « Pourquoi ne pouvez-vous pas simplement attribuer cela à l’équipe _____ déjà ?? » – en fait, nous ne voulons pas que nos utilisateurs sachent que ces groupes existent.
Habituellement, je suis tout à fait pour la transparence radicale… mais cela fonctionne très bien pour nous.
Et nous voulons que nos utilisateurs internes puissent voir tous ces groupes, les sujets qui leur sont attribués, et avoir la possibilité de les réattribuer à d’autres groupes.
Mais les autorisations d’interaction au niveau du groupe :
Cela signifie que si nous voulons nous assurer que tous nos utilisateurs internes peuvent voir / interagir avec les groupes comme nous le souhaitons, nous devons leur accorder au moins un accès de modérateur. Ce n’est pas idéal.
J’espère que cela clarifie le problème. Faites-moi savoir si je peux clarifier quoi que ce soit d’autre.
En fait, cela simplifierait probablement l’interface utilisateur et l’implémentation interne qui n’auraient plus à raisonner sur des énumérations, etc.
La chose la plus difficile concernant un portage est que « les propriétaires de groupe » ne sont pas un vrai groupe, nous aurions donc besoin d’une sorte de nouveau primitif pour décrire ce que cela signifie. L’identifiant de groupe ne suffit pas.
Honnêtement, j’ai du mal à imaginer un cas d’utilisation réel où les propriétaires de groupe ne devraient pas être autorisés à tout faire en vertu de leur statut de propriétaires de groupe.
Dans ce cas, vous pourriez peut-être ignorer ce problème et accorder aux propriétaires de groupe des droits d’administrateur. Le reste des autorisations serait alors délégué à des groupes individuels.
Je vous entends, mais je m’inquiète beaucoup de faire des changements majeurs. En prenant en charge un simple groupe fantôme de « propriétaire du groupe », nous pouvons migrer complètement vers une nouvelle interface utilisateur sans rien casser pour les utilisateurs existants de la fonctionnalité.
