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.

3 « 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.

2 « J'aime »