Permissions granulaires basées sur les groupes pour les utilisateurs anonymes et connectés

Nouvelles et événements Annonces
44

Non, ce n’était pas le cas, et nous avons vu ce problème se poser à maintes reprises, tant en interne qu’en externe, ainsi que partout dans la base de code.

Nous n’avons pas encore abordé les catégories, rien n’a changé à cet égard.

Les gens utilisaient massivement TL0 pour signifier « tous les utilisateurs connectés » parce que nous n’avions pas de meilleure façon de représenter cela. Le groupe logged_in_users est au moins parfaitement clair sur ce qu’il implique, et rien ne vous empêche d’utiliser toujours TL0/TL1, etc. Le seul groupe qui est supprimé est everyone.

Oui, bien sûr, je fais tout cela juste pour le « plaisir de changer » :+1: Veuillez réfléchir un instant à votre formulation, nous n’avons pas l’habitude de faire des choses totalement inutiles sans raison ici. Ce travail est en cours depuis des mois et sa direction ne change pas.

4 « J'aime »
45

D’accord, je comprends peut-être mal ce changement ?

Si la proposition est d’introduire :

  • anon
  • connecté

en tant que groupes automatisés

cela me semble correct et ces noms sont explicites.

(D’ailleurs, j’aime beaucoup cette idée ! :+1:)

En revanche, si la proposition est de finalement supprimer :

  • everyone

cela ne me semble pas logique, car « everyone » fait partie d’un ensemble de groupes automatisés qui représentent des seuils d’accès et qui incluent également :

  • trust_level_0
  • trust_leve_1

etc.

ils représentent tous des seuils d’accès, y compris « everyone ».

le groupe « everyone » est aussi appelé « trust_level_none »

c’est une manière concise de désigner l’accès public.

Je comprends que vous ne proposez pas de le supprimer pour les permissions des catégories pour le moment (:+1:), mais personnellement, j’aimerais voir un engagement à conserver ce groupe automatisé, car pour moi, au moins, cela a du sens.

Et pourquoi ne pas permettre son utilisation ailleurs, tout comme vous le feriez pour n’importe quel groupe de niveau de confiance automatisé ?

Sinon, partout où vous devez exprimer qu’il faut un « accès public », vous allez devoir ajouter deux groupes, ce qui semble être une complexité inutile ?

Pourquoi se donner la peine d’ajouter une logique pour « masquer » « everyone » ?

Peut-être qu’une autre approche alternative serait de reconsidérer le nom « everyone » si un meilleur nom existe, mais de conserver sa signification, sa fonctionnalité et sa disponibilité sur toute la plateforme, et alors tout le monde (tousse) sera content ?

46

Je pense que la distinction ici porte sur le maintien d’un moyen pratique de sélectionner « accès public » et le maintien du groupe existant everyone. Je suis d’accord que devoir sélectionner deux groupes à chaque fois que l’on veut un accès public est plus contraignant, et nous pouvons améliorer cela via l’interface utilisateur.

Par exemple, nous pourrions ajouter un raccourci « Public » au sélecteur de groupes qui sélectionne à la fois anonymous_users et logged_in_users en une seule action. Vous verriez alors les deux groupes sélectionnés, et pourriez en retirer un. Cela vous offrirait la praticité que vous décrivez, tout en gardant les autorisations sous-jacentes explicites. Nous ne proposerions ce raccourci que là où les deux groupes sont autorisés.

Le problème avec le maintien du groupe everyone existant est qu’il n’a pas toujours signifié « accès public ». Pour la visibilité des catégories, c’est le cas, mais pour la plupart des paramètres de site basés sur les groupes, il a effectivement signifié « tous les utilisateurs connectés ». Il y a aussi des thèmes et des plugins qui l’interprètent différemment, comme l’a montré la discussion ci-dessus.

Nous ne pouvons donc pas simplement le conserver et dire qu’il inclut les utilisateurs anonymes partout, sans risquer d’accorder un accès qui n’existait pas auparavant. Conserver son comportement existant préserverait l’incohérence, et le renommer ne résoudrait pas non plus ce problème.

Un groupe universel défini de manière cohérente serait possible, mais cela nécessiterait toujours la migration et l’audit que nous réalisons actuellement. Il devrait également être interdit partout où l’accès anonyme n’est pas pris en charge, sinon nous reviendrions à la situation où « everyone » signifie « uniquement les utilisateurs connectés » dans ces endroits. Il y a une multitude de paramètres pour lesquels j’ai dû ajouter anonymous_users comme valeur de disallowed_groups là où ce n’était pas le cas auparavant, et avant que everyone ne soit autorisé sur ces paramètres. Par exemple :

Je préférerais offrir cette praticité dans l’interface utilisateur, en utilisant les deux groupes explicites en dessous, afin d’avoir de la cohérence partout pour les administrateurs et les développeurs.

3 « J'aime »
47

tout le monde est très explicite - cela me semble être une lourdeur inutile - mais j’apprécie la commodité conservée.

à mon avis, c’est là que se situe le problème (actuel et passé), et non pas avec le concept original de la catégorie « everyone ».

le groupe « everyone » et son utilisation dans le système fondamental des catégories existent depuis… 2013 ?

Si le système de paramètres s’est divergé et a rompu ce contrat, n’est-ce pas un problème lié au travail effectué sur le système de paramètres ?

À mon avis, il aurait été agréable de disposer d’un RFC pour que la communauté puisse contribuer à des idées à ce sujet avant ce qui semble aller droit vers l’implémentation.

Mes excuses si j’ai raté quelque chose…

48

Oui, je suis d’accord que l’incohérence dans les paramètres du site fait partie du problème. Mais corriger cela ne signifie pas nécessairement qu’il faut continuer à utiliser le groupe existant everyone pour les paramètres du site.

Je ne pense pas que l’argument de 2013 nous en apprenne beaucoup au-delà de la durée d’existence de everyone pour les permissions de catégorie. Beaucoup de choses ont changé dans Discourse depuis 2013 ; par exemple, de nombreux paramètres du site étaient basés sur le niveau de confiance, tandis qu’ils sont maintenant basés sur les groupes. Personne ne remet en question le fait que cela ait du sens dans ce contexte, et les permissions de catégorie ne sont pas modifiées par ce travail (du moins, pour le moment). Son ancienneté n’établit pas qu’il a un sens cohérent dans le reste de Discourse, ou que nous devrions le conserver indéfiniment.

Même si nous étions d’accord que chaque divergence par rapport au sens d’origine était une erreur, nous devrions toujours gérer le comportement réel de ces paramètres sur les sites existants. Nous ne pouvons pas changer en toute sécurité leur interprétation pour inclure les utilisateurs anonymes simplement parce que cela correspondrait mieux au comportement original des catégories. Comme je l’ai expliqué ci-dessus, maintenir un groupe universel avec un sens cohérent nécessiterait toujours d’auditer et de migrer ces utilisations. C’est une conception alternative, mais elle n’évite pas la partie la plus difficile de ce travail.

Concernant le point sur la RFC, avoir une RFC communautaire avant d’apporter des modifications de ce type serait lent et prohibitif, bien que les commentaires soient les bienvenus, c’est à cela que sert le système de changements à venir. Ce sujet a déjà conduit à plusieurs améliorations à partir des exemples de Moin, et j’ai reconnu les cas de thème/composant que j’avais manqués initialement et je les ai corrigés également.

Je suis heureux de continuer à travailler sur des problèmes concrets liés au changement, mais je vais quand même de l’avant avec les deux groupes explicites. Rendre l’accès public facile à sélectionner dans l’interface utilisateur semble une manière raisonnable de répondre au problème des clics supplémentaires, mais je ne pense pas que ce soit nécessaire à implémenter immédiatement.

De toute façon, j’ai encore beaucoup de travail suivi dans The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions pour cela, donc cela prendra encore un moment, tout comme les modifications liées au système de catégories, qui conserve everyone pour le moment. Les catégories sont susceptibles de passer à un système que nous appelons ACL, que kanban utilise déjà :

image
image663×244 40.1 KB

4 « J'aime »