Pas de problème ! Ravi que disallowed_groups vous soit utile. J’ai fusionné cette PR maintenant.
Je dois maintenant passer en revue tous nos thèmes et composants officiels maintenant que disallowed_groups et resolve_group_memberships sont disponibles. Je vous suggère, ainsi qu’à @moin, de faire de même pour vos propres thèmes et composants dès que possible, car une fois que j’aurai apporté des modifications à nos dépôts officiels, je tiens vraiment à avancer vers la stabilisation du changement annoncé dans le message initial.
Il y a beaucoup d’autres travaux de base qui dépendent maintenant ou utilisent anonymous_users et logged_in_users, et j’aimerais vraiment supprimer le groupe everyone.
je viens de faire une mise à jour complète de mon instance, et j’ajoute maintenant le paramètre objet disallowed_groups à mon composant pour everyone et anonymous_users en me basant sur les identifiants de groupe automatique ici :
qu’est-ce que je fais mal dans le paramètre objet ? je remarque que même sans disallowed_groups dans les objets, le groupe anonymous_users ne s’affiche pas non plus (donc pour l’instant, il n’y a aucune différence dans la liste de mon composant, que je définisse disallowed_groups ou non). j’ai testé avec d’autres identifiants de groupe et je dois faire une erreur dans la façon dont j’utilise disallowed_groups (ou la syntaxe), car cela ne semble avoir aucun effet, quel que soit ceux que j’utilise.
Il y a eu quelques problèmes sur GitHub plus tôt dans la journée, donc le changement de disallowed_groups n’a été intégré que tout juste dans la dernière version de Commits · discourse/discourse · GitHub
Je ne suis pas tout à fait certain que ce soit la cause du problème, mais peux-tu essayer de mettre à jour à nouveau et voir si le problème persiste ? Sinon, fais-le-moi savoir et indique-moi ton composant de thème (ou est-ce juste celui de la barre latérale de ton groupe ?) pour que je puisse déboguer
Je pense que cela était dû au fait que la modification à venir était désactivée sur le forum que vous avez utilisé pour les tests. Je l’ai activée et maintenant elle est visible.
Puis-je connaître les classes CSS pour les utilisateurs anonymes et enregistrés ? Je n’utilise pas leurs identifiants internes car je travaille avec du CSS pur.
J’ai ouvert une petite PR pour ajouter ces deux classes (anonymous_users et logged_in_users).
Je ne l’ai pas vraiment testée (lol) mais je pense que c’est assez simple. Le code vérifie juste si l’utilisateur actuel existe, et si c’est le cas, il fait partie de logged_in_users, sinon c’est anonymous_users.
note : je suis presque certain que Discourse ajoute automatiquement .anon de toute façon, donc le CSS pour les utilisateurs anonymes vs connectés peut être réalisé sans le composant, mais cela utilise simplement les nouvelles conventions de groupe.
Pour information, je n’avais pas encore posté ici, mais j’ai fusionné ces PR pour que les composants officiels utilisent resolve_group_membership et disallowed_groups :
Je travaille actuellement sur un plan pour les prochaines étapes de ce changement à venir. Je pense qu’il reste encore quelques endroits dans les bases de code du cœur/du plugin qui vérifient directement everyone ou n’utilisent pas user.in_any_groups? côté serveur.
Y a-t-il une raison pour laquelle cela n’a pas encore été fusionné ?
La raison pour laquelle j’ai ouvert ce sujet est que j’ai enfin mis à jour mon composant
J’ai fait cela. Mais j’ai toujours l’impression que cela ne sert que pour les forums ajoutant le composant après que j’ai effectué ce changement. Pour ceux qui l’utilisent déjà, la nouvelle valeur par défaut n’est pas appliquée (ce qui est généralement une bonne chose !). Je vois donc toujours le problème qu’il y a un changement de comportement inattendu pour ceux qui utilisent déjà le composant.
Sais-tu également ce qui se passe si un administrateur a configuré un paramètre avec un groupe que j’ajoute en tant que groupe non autorisé dans ma mise à jour ?
Comme je ne pense pas que le composant soit utilisé sur beaucoup de forums, je n’étais pas trop inquiet et j’ai fusionné quand même, mais à la fois la migration et la définition des groupes non autorisés pourraient également être pertinentes pour d’autres développeurs de thèmes.
Non, pour une raison que j’ignore, j’ai cru que ce n’était pas une PR sur l’org Discourse Je fusionnerai dès que les vérifications CI seront terminées.
Pour ce genre de cas et d’autres à l’avenir, je pense que la meilleure solution est probablement d’écrire une migration spécifique à chaque thème/composant Migrate Discourse theme settings
J’ai demandé dans mon message ci-dessus quand cela devrait se produire. Migrer sans être certain que les nouveaux groupes fonctionnent sur tous les forums pourrait également causer des problèmes, et les administrateurs peuvent activer ou désactiver le changement. Donc, il semble impossible de migrer au bon moment.
Veuillez m’excuser si cela a déjà été mentionné et que je l’ai manqué…
Je me suis rendu compte que, si resolve_group_membership est inclus dans les paramètres, je ne peux accéder à la valeur booléenne que via le préfixe user_in_, mais je ne peux plus accéder à la valeur brute du champ de paramètre.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true ou false
Je pense que oui. Sinon, la solution à ce bug aurait pu être différente.
Cela me semble également logique. user_in_x vérifie également les groupes que le frontend ne connaît pas, car le groupe n’est visible que par les administrateurs ou sa visibilité est limitée par défaut, comme pour everyone. Vous obtenez donc des résultats différents selon ce que vous utilisez, et combiner les deux pourrait avoir des conséquences inattendues.
Merci Moin, c’est exactement ça. @gormus, le seul endroit où les vrais IDs de groupe passent encore est dans l’interface d’administration pour les paramètres du thème.
Je ne suis pas sûr que ce soit clair d’après ce que j’ai posté précédemment, mais les groupes anonymous_users et logged_in_users sont utilisables à tout moment sans que ce changement à venir soit activé ; je les ai ajoutés de manière indépendante il y a plusieurs mois. Voici ce que fait principalement ce changement à venir :
Dans tous les cas, vous êtes en sécurité si vous vous débarrassez de everyone partout où il est utilisé et n’utilisez que anonymous_users et logged_in_users à partir de maintenant.
Aujourd’hui, je prévois de définir un plan pour le travail restant que je dois faire pour me débarrasser vraiment de everyone pour les paramètres du site (en laissant les paramètres de catégorie de côté pour le moment), et je le posterai ici, afin d’aider à rester sur la même page à l’avenir, et je pourrai continuer à mettre à jour ce plan au fur et à mesure.
Mais les groupes ne sont pas visibles dans l’interface si le changement est désactivé. Les administrateurs ne peuvent pas modifier un paramètre pour ces groupes. Donc, lorsque j’ajoute « everyone » en tant que disallowed_group, ils ne voient plus aucun groupe qui leur permette de configurer un composant pour qu’il soit visible par les visiteurs. Pour moi, « utilisable » implique non seulement de fonctionner, mais aussi d’être visible. Comme il est toujours possible de désactiver le changement, je ne qualifierais pas le fait de compter uniquement sur les nouveaux groupes de « sûr ».
Hmm, tu as raison. Il y a quelques autres choses que je dois corriger pour que ce problème de disallowed_group disparaisse lorsque le changement à venir est désactivé :
anonymous_users et logged_in_users ne figurent pas du tout dans le sélecteur de groupes. Je pense qu’il est désormais sans risque de les autoriser ici, auquel cas il n’importera plus que tu aies ajouté everyone à disallowed_groups si le changement à venir est désactivé.
Corriger Guardian::AnonymousUser#in_any_groups? pour qu’il tienne compte de anonymous_users lorsque le changement à venir est désactivé.
Ajouter la même aliase de temps de lecture 0 (everyone) → 5 (logged_in_users) pour les paramètres de thème, comme nous le faisons pour les paramètres du site.
Je pense également que je pourrais marquer everyone avec (legacy) dans le(s) sélecteur(s) de groupes tant que le changement à venir reste optionnel et désactivé.
Je vais donner la priorité à ces points et les ajouter au plan global sur lequel je travaille.
J’ai créé un sujet dédié ici @moinThe road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . Le message initial est incomplet, je suis encore en train d’analyser tous les cas localement, je continuerai à le mettre à jour. Je ne vois aucun inconvénient à ce que vous continuiez à poster dans ce sujet, mais je préférerais que nous menions les discussions ultérieures dans le nouveau, afin que je puisse citer des parties du message initial ou y ajouter des éléments selon les besoins.
merci Moin ! j’avais en fait oublié que le nouveau paramètre de groupe granulaire faisait de toute façon partie des changements à venir.
Je fusionnerai dès que les vérifications CI seront terminées.