(La demande de fonctionnalité d’une personne est le rapport de bug d’une autre… )
La page d’index des « Groupes » (par exemple, /groups ou /g) doit respecter les paramètres de visibilité des groupes automatiques et les afficher en conséquence. Elle le fait pour le groupe Modérateurs, mais pas pour les autres. Ceci est dû à une exception codée en dur dans GroupsController.index(), qui fait que les autres groupes automatiques n’apparaissent jamais sur la page d’index lorsqu’ils sont consultés par des utilisateurs non membres du personnel, quels que soient les paramètres de visibilité.
Ce comportement exceptionnel est problématique d’au moins deux manières :
Si un administrateur souhaite indexer des groupes automatiques pour les utilisateurs non membres du personnel, cela les en empêche.
La déconnexion entre le paramètre de visibilité et la visibilité réelle est dangereusement confuse. En particulier, elle donne l’impression que le paramètre est ignoré/non pertinent pour les groupes automatiques (par exemple, « Tiens, on dirait que les groupes automatiques sont toujours réservés au personnel, peu importe ce que je règle ici… »), même si le paramètre continue de contrôler l’accès aux pages de groupes spécifiques (par exemple, /g/trust_level_0) et à leurs listes de membres.
Un commentaire dans le code pertinent indique que ce comportement exceptionnel est destiné à « masquer les groupes automatiques à tous les non-membres du personnel pour désencombrer la page » — mais il n’est pas nécessaire d’utiliser ce mécanisme pour y parvenir. Un administrateur qui souhaite désencombrer la page d’index peut simplement définir la visibilité des groupes automatiques comme il l’entend, tout comme il le ferait avec n’importe quel autre groupe.
Je suggère de simplement supprimer les 6 lignes de code de app/controllers/groups_controller.rb qui implémentent ce comportement.
S’il est jugé si important de proposer par défaut un index « désencombré » pour les nouvelles installations de Discourse, un meilleur mécanisme serait de simplement définir par défaut la visibilité réservée au personnel pour les groupes automatiques lorsqu’ils sont créés par le système. de définir le filtre par défaut sur la page d’index sur « non-automatique » pour les utilisateurs non membres du personnel.
(Le paramètre de visibilité est un contrôle d’accès — la valeur par défaut doit être ce qui constitue un niveau d’accès par défaut raisonnable, indépendamment de l’apparence de la page d’index.)
Pour information, ce sujet fait suite à la discussion dans :
En tant qu’utilisateur régulier, je préfère la vue épurée, les groupes de niveaux de confiance ne me semblent pas pertinents. Mais je suis aussi d’accord que la façon dont les choses fonctionnent maintenant semble étrange. Surtout étant donné ceci :
Si les pages de groupes de niveaux de confiance sont utiles, il devrait y avoir un moyen d’y accéder via l’interface utilisateur, sans avoir à connaître l’URL.
Cela me semble logique. Il faudrait peut-être prendre soin de s’assurer que limiter la visibilité d’un groupe de niveaux de confiance ne casse rien. Actuellement, il n’est pas possible de créer des événements publics si le groupe TL0 n’est pas visible par l’utilisateur qui crée l’événement. Je ne suis pas sûr s’il existe d’autres cas similaires.
Alors, cela ne serait-il pas facilement résolu par :
avoir des « Groupes automatiques » disponibles dans la liste déroulante des filtres pour les non-administrateurs ?
rendre le filtre par défaut (pour les administrateurs et les utilisateurs réguliers) excluant les groupes automatiques
s’assurer que /g/trust_level_0?asc=true utilise la même logique d’autorisation que /g?type=automatic (actuellement, le premier fonctionne tandis que le second affiche « Il n’y a pas de groupes visibles »)
Demande supplémentaire : si /g est accédé via /admin, alors les barres de menu d’administration disparaissent soudainement. Je trouve cela ennuyeux. Que diriez-vous d’ajouter ces barres de menu à cette page si /g est accédé par un administrateur ?
Oui, « duh » comme on dit… J’ai modifié ma proposition initiale pour en tenir compte. La « visibilité » est un contrôle d’accès, et doit être traitée comme tel (par exemple, l’interface utilisateur doit refléter de manière transparente l’état du contrôle, au lieu que le contrôle soit tordu pour ajuster l’apparence de l’interface utilisateur).
En effet ! Je n’avais pas remarqué que « automatique » n’était pas disponible dans le menu déroulant du filtre pour les non-employés. (Il est élidé par le même bloc de code de 6 lignes qui masque les groupes automatiques — donc supprimer ce code corrigerait également cela.)
Le code backend définit déjà un filtre « non_automatique », bien qu’il ne semble jamais être proposé à qui que ce soit (employé ou non) dans le menu déroulant du filtre.
Quand vous dites « indexer des groupes automatiques pour les utilisateurs non-membres du personnel », voulez-vous dire permettre aux utilisateurs non-membres du personnel d’accéder au filtre des groupes automatiques et de les voir ?
C’est une préoccupation légitime. Nous essayons de rendre l’expérience d’administration plus simple et cohérente, et cela semble être un domaine qui peut induire les gens en erreur. Je n’ai entendu aucune autre plainte concernant ce cas particulier, mais je vois l’intérêt de le corriger pour que le comportement soit cohérent.
Ces deux points semblent logiques. Cependant, avant de faire cela, y a-t-il des conséquences imprévues à modifier les paramètres de visibilité des groupes automatiques ?
Cela ressemble à une bonne liste de tâches. Merci de l’avoir formulée ainsi.
Dans ce texte cité, j’entends spécifiquement par là « afficher les groupes automatiques sur la page d’index /g lorsqu’elle est consultée par des utilisateurs non-membres du personnel ». Indépendamment du réglage du filtre, les groupes automatiques (à l’exception des « Modérateurs ») ne sont actuellement pas autorisés à être listés sur la page d’index /g pour les utilisateurs non-membres du personnel.
Dans un message ultérieur (celui qui précède celui-ci), je plaide en outre pour que l’option « Groupes automatiques » soit proposée dans le menu déroulant du filtre à tous les utilisateurs, pas seulement aux membres du personnel. Je ne pense pas qu’il y ait de bonne raison de la cacher aux utilisateurs non-membres du personnel. (Notez que, quel que soit ce qui est présenté dans le menu déroulant, le filtre reste accessible à tout utilisateur capable de taper le mot-clé correct dans la barre d’URL.)
Veuillez noter que j’ai modifié ma suggestion de désencombrement par défaut avant votre message ; vous avez cité la version originale. Le texte révisé/actuel de mon premier message est (avec les barres obliques supprimées pour plus de brièveté) :
Actuellement, la liste des utilisateurs ressemble à ce qui suit sur un nouveau site.
Pour résumer avec mes propres mots, la demande est de modifier l’annuaire de groupes à /g comme suit :
afficher également le filtre des groupes automatiques pour les membres
afficher tous les groupes automatiques aux membres lorsque le filtre est sélectionné
exclure les groupes automatiques de la vue par défaut à /g
Mon sentiment est que (3) devrait être pour tout le monde, pas seulement pour les membres. L’un de nos objectifs est de donner aux administrateurs et aux modérateurs une expérience aussi proche que possible de celle des membres, afin de réduire la confusion.
En apportant cette modification, nous rendons simplement explicite dans l’interface utilisateur l’existence de groupes automatiques auxquels les membres ont accès mais dont ils doivent actuellement connaître l’URL.
Je reformulerais, en termes de changements à apporter, et je reprioriserais un peu :
A. arrêter de supprimer les groupes automatiques de l’index pour les utilisateurs non-staff
B. arrêter de supprimer le filtre « Groupes Automatiques » du menu déroulant pour les utilisateurs non-staff
C. proposer le filtre « Groupes Non-Automatiques » dans le menu déroulant, à tous les utilisateurs
D. activer le filtre « Groupes Non-Automatiques » par défaut à /g
Mon choix de formulation pour C et D, par rapport à 3, est intentionnel : je pense que l’interface utilisateur devrait être très transparente sur le filtrage appliqué. Si aucun filtre n’est sélectionné, l’interface utilisateur devrait présenter une vue non filtrée, c’est-à-dire afficher tous les groupes visibles/accessibles à l’utilisateur.
On pourrait interpréter 3 comme « lorsqu’aucun filtre n’est sélectionné, utiliser silencieusement le filtre non_automatic », mais je pense que ce serait toujours confus. Si aucun filtre n’est sélectionné, alors aucun filtre ne devrait être appliqué. Inversement, si un filtre est appliqué, il devrait être nommé et rendu apparent à l’utilisateur.
En approfondissant ici : une partie du problème de sélection du filtre découle de la manière dont l’indication « Filtrer par type de groupe » a été intégrée dans l’étiquette de l’élément de menu « aucun filtre sélectionné ». Je pense qu’il serait finalement plus clair si l’élément « aucun filtre sélectionné » était étiqueté « Tous les groupes ». Ajoutez ensuite un élément supplémentaire « Groupes Non-Automatiques », et vous êtes libre de faire de l’un ou l’autre élément le défaut. De cette façon, (a) il est clair quand l’utilisateur reçoit une vue filtrée, et (b) il est clair comment passer à une vue non filtrée.
Si cela ne tenait qu’à moi, j’étiquetterais les éléments du menu de filtre comme suit :
Tous les groupes
Groupes auxquels j'appartiens(car Mes Groupes est ambigu.)
Groupes que je possède
Groupes Publics
Groupes Privés(car Fermés sonne comme « arrêté » ou « plus utilisé ».)
Groupes Automatiques
Groupes Non-Automatiques
Et je changerais la chaîne d’indication dans la zone de texte, de « Tous les groupes » à « filtrer par nom de groupe ».
Et… j’inverserais l’ordre du menu déroulant et de la zone de texte !
Merci de m’avoir aidé à réfléchir à cela. Je ne pense pas que nous allons apporter de changements majeurs à l’expérience utilisateur de la liste des groupes pour le moment, mais j’aime l’idée de faire fonctionner la liste des groupes de la même manière pour tout le monde.
Ce sont toutes de bonnes suggestions, sauf que je trouve que « Automatique » et « Non automatique » sont des noms maladroits, techniques et peu significatifs. Puisque les groupes automatiques concernent les privilèges que les gens ont obtenus ou qui leur ont été accordés, peut-être pouvons-nous trouver une étiquette qui reflète cela ?
Je suis juste venu avec la même idée, qu’il serait préférable d’avoir la vue par défaut sur ce qu’on appelle aujourd’hui « Groupes publics + fermés », en introduisant une telle option. Et supprimer les ambiguïtés autour de « Mes groupes », qui pourraient être compris comme ce que signifie réellement « Groupe que je possède », et « Groupes fermés », qui pourraient sembler ne plus être actifs, semble également raisonnable.
Cela ressemble beaucoup à :
Groupes système
Groupes d’utilisateurs, « Groupes publics et privés », ou simplement Groupes
Peut-être que l’ordre des groupes proposés dans cet élément de filtre pourrait être configuré, le premier élément étant toujours la vue par défaut, afin que nous puissions le choisir. Sinon, trouver un ordre par défaut approprié qui convienne à tout le monde, en plus de permettre à l’une de ces vues d’être par défaut, serait une autre question.
De plus, pouvoir donner des alias de noms lisibles par l’homme aux « Groupes automatiques/système », par exemple, certaines langues préfèrent les majuscules au début, comme avec le champ Nom complet dans les groupes réguliers et leur fournir des textes de description par défaut facultatifs et sensés pourrait les rendre moins « techniques », si un administrateur de site ne choisit pas de les expliquer dans leur description via leur menu Gérer.
Peut-être qu’il pourrait également y avoir une sorte de distinction visuelle entre les groupes « Automatiques » et « Non automatiques », comme une icône, ou leurs cases étant ombrées en gris clair, ou quelque chose comme ça.
« Automatique » semble faire référence à la façon dont un détail d’implémentation - les utilisateurs sont ajoutés aux groupes automatiquement. Je ne pense pas que cela ait beaucoup de sens du point de vue d’un utilisateur normal. Ce n’est pas non plus strictement exact. Les utilisateurs ne sont pas automatiquement ajoutés aux groupes du personnel. Le nom le plus précis pour les groupes automatiques serait probablement « groupes pré-remplis », mais c’est un nom terrible.
Les groupes « Système » semblent corrects, mais qu’en est-il de la division des groupes automatiques en « Niveaux de confiance » et « Personnel » ? Le filtre de type de groupe serait quelque chose comme :
Mes groupes
Groupes que je possède
Groupes publics
Groupes fermés
Niveaux de confiance
Personnel
Si nécessaire, il pourrait y avoir un paramètre de site comme trust level groups public qui déterminerait si les groupes de niveaux de confiance sont visibles ou non sur la page des groupes.
Séparer le personnel du site est une bonne idée. Les gens pourraient en fait apprécier de découvrir une liste de modérateurs et d’administrateurs ici. Sinon, ils devront savoir qu’il faut aller sur /about.
Je reviens encore… comptez-moi parmi les utilisateurs/administrateurs de Discourse qui n’ont pas vraiment besoin d’un filtre « tout afficher sauf les groupes système/automatiques ». La présence de ces groupes ne semble pas si gênante.
Quoi qu’il en soit, ma priorité est de proposer un véritable filtre « Tous les groupes » sans filtre, et ma préférence personnelle est de rester simple et que ce soit le réglage par défaut pour la page /groups.
)
