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

Nouvelles et événements Annonces
1

Il existe dans notre base de code un pseudo-groupe historiquement déroutant appelé @everyone, qui peut être utilisé pour :

  • Les paramètres du site de type group_list
  • Les permissions des catégories
  • Les groupes d’étiquettes

Dans certains cas, les personnes interprètent @everyone comme signifiant « tous les utilisateurs anonymes et tous les utilisateurs connectés », tandis que d’autres le comprennent comme signifiant uniquement « tous les utilisateurs connectés ». En réalité, pour les paramètres du site, cela signifie généralement « tous les utilisateurs connectés ».

La situation est encore plus confuse du fait que ce groupe @everyone peut être utilisé sur des paramètres du site où il n’a aucun sens d’accorder l’accès à « tous les anonymes et tous les connectés », comme c’est le cas pour pm_tags_allowed_for_groups.

Cela crée également de la confusion du point de vue de la gestion des fonctionnalités (feature flagging) et de l’expérience développeur, car pour certaines modifications à venir ou d’autres paramètres, nous pourrions réellement souhaiter les activer pour « tous les anonymes et tous les connectés ».

Solution

Nous introduisons deux pseudo-groupes automatiques distincts :

  • anonymous_users (ID 4) – Représente les utilisateurs anonymes visitant votre site sans compte
  • logged_in_users (ID 5) – Représente tous les utilisateurs connectés à votre site, avec un effet similaire au groupe automatique trust_level_0, mais plus spécifique

Ces groupes ont déjà été introduits, mais ne prendront effet que lorsque la modification à venir granular_anonymous_and_logged_in_groups_permissions sera activée sur votre site.

Lorsque cette modification à venir sera activée, tout paramètre ayant everyone comme groupe sélectionné sera automatiquement traduit vers l’ID logged_in_users. Ainsi, aucune donnée dans la table des paramètres du site ne sera modifiée lors de l’activation de cette modification. Lorsque celle-ci deviendra permanente, nous effectuerons une migration des données pour tous les paramètres de groupe afin d’appliquer ce changement.

De plus, nous avons marqué anonymous_users comme disallowed_group pour plusieurs paramètres du site où cela n’a pas de sens, par exemple personal_message_enabled_groups.

image
image1217×205 51.6 KB

Les conflits avec des noms de groupes existants sont gérés automatiquement, en renommant les groupes existants et en mettant à jour les mentions de groupes dans les publications.

Qu’en est-il des permissions des étiquettes et des catégories ?

Ces permissions resteront inchangées, car leur notion de « everyone » diffère à plusieurs égards et ne repose pas sur le groupe automatique sous-jacent.

9 « J'aime »
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Attends… quoi :flushed_face: Cela signifie-t-il que toutes les catégories actuellement publiques (tout le monde) passeront à des catégories fermées nécessitant une connexion, une fois cette option activée ?

4

Non, car :

Cela affecte uniquement les paramètres du site de type liste de groupes qui permettent actuellement de sélectionner « tout le monde » comme suit :

image
image909×273 54 KB

1 « J'aime »
5

Peut-être que quelqu’un peut m’aider à comprendre comment je dois ajuster les composants de mon thème ?

J’ai essayé d’utiliser le composant copy-post comme exemple, car je me souviens qu’il utilise également un paramètre de groupe qui accorde l’accès à la fonctionnalité. Et qu’il y avait un problème car le pseudo-groupe « everyone » nécessitait une vérification distincte, tout comme dans mon composant, car comparer les IDs des groupes auxquels l’utilisateur appartient ne suffit pas — ces IDs doivent être vérifiés séparément. C’est pourquoi je m’attendais à un changement récent là-bas, car, à ma connaissance, les nouveaux groupes sont aussi des pseudo-groupes et l’ID doit être vérifié séparément. Est-ce que je manque quelque chose qui expliquerait pourquoi ce n’est pas nécessaire ici ?

Mon composant favorite filters dispose de deux paramètres de groupe : l’un permet aux groupes d’enregistrer leurs propres filtres, et l’autre propose des filtres standard.
Par défaut, seuls les membres du groupe trust_level_0 peuvent utiliser des filtres personnalisés, car seuls les utilisateurs enregistrés peuvent avoir des données stockées dans un champ utilisateur personnalisé. Donc, ici, il serait logique que je n’autorise pas anonymous_users comme sélection. Comment puis-je faire cela dans un composant de thème ? Existe-t-il déjà un exemple pour cela ?

Le paramètre par défaut pour les filtres par défaut est « everyone », car je trouve utile que même les utilisateurs non enregistrés puissent voir et utiliser les filtres par défaut. Le problème est que everyone change en « logged_in_users » même si je l’ai spécifiquement sélectionné. Dois-je créer une migration personnalisée pour cela afin que les administrateurs utilisant actuellement everyone continuent d’avoir des filtres pour les utilisateurs non enregistrés à l’avenir ? Quand cette migration doit-elle avoir lieu ? Ou chaque administrateur doit-il modifier cela individuellement après que vous ayez exécuté la migration ?

Tout ce dont je m’inquiète est-il réellement inutile ? Si des ajustements sont nécessaires, moins de quatre semaines semblent être un délai assez court compte tenu du nombre de composants maintenus par la communauté qui pourraient potentiellement être affectés.
En plus de « copy-post », j’ai également examiné le composant unanswered filter, mais je n’ai trouvé aucun changement là non plus. J’ai l’impression d’oublier quelque chose d’important. Après tout, le changement est activé par défaut depuis presque une semaine maintenant. C’est pourquoi je suppose que les composants officiels auraient déjà été mis à jour si des ajustements étaient nécessaires.

1 « J'aime »
6

3 messages ont été fusionnés dans un sujet existant : Modernisation du thème Foundation

7

En examinant ces composants, currentUser?.groups n’est pas fiable de toute façon, car il ne comprend que les groupes visibles pour l’utilisateur, et les groupes dans lesquels il se trouve et qui influencent les autorisations peuvent ne pas être sérialisés ici :

Nous contournons cela dans le noyau et les plugins en procédant comme ceci dans le sérialiseur de l’utilisateur actuel :

Mais évidemment, cela n’est pas disponible pour les composants de thème et les thèmes, ni pour leurs paramètres.

Hmm, je ne suis pas sûr, je devrai y réfléchir. Si vous vouliez vraiment dire everyone, alors cela devrait changer à la fois en logged_in_users ET en anonymous_users. C’était le principal problème avec everyone tel que mentionné dans le message original — certaines personnes l’ont interprété comme signifiant uniquement les utilisateurs connectés, d’autres comme signifiant les utilisateurs connectés + anonymes, et cela dépendait beaucoup de la situation.

J’ai choisi l’interprétation « uniquement les utilisateurs connectés » car elle était plus sûre d’un point de vue sécurité.

Non, j’ai simplement oublié les composants de thème et les thèmes, ainsi que leurs paramètres et la façon dont ils seraient affectés par ce changement. J’étais surtout concentré sur les paramètres du site. Des choses comme celle-ci seront particulièrement difficiles à trouver, car elles n’utilisent même pas la constante AUTO_GROUPS :

image

Quoi qu’il en soit, je vais réfléchir à des solutions à ces problèmes, et je ne passerai pas ce changement à la version Stable tant que je n’aurai pas trouvé de solutions.

3 « J'aime »
Introducing Upcoming Changes, a system to manage new features and changes to existing functionality in your community
9

Petit update, j’ai une idée sur la manière de gérer ça, et nous en discutons en interne. J’espère que ça ne prendra pas trop de temps :crossed_fingers:

1 « J'aime »
10

C’est exactement mon cas :upside_down_face: ; donc, pour créer une catégorie réservée aux utilisateurs enregistrés, j’ai défini sa permission d’accès uniquement pour TL0, en m’appuyant sur le groupe d’utilisateurs automatique TL0 pour distinguer les utilisateurs connectés des invités.

Je me demande s’il existe un tableau pour distinguer la signification de ce terme dans différents contextes. Ces différences sont à la fois déroutantes et inquiétantes — parce que lorsque les gens ont initialement choisi ce paramètre, ils ne connaissaient probablement pas sa signification réelle, donc ils voudraient vérifier les paramètres associés. Actuellement, je ne peux que vérifier individuellement chaque endroit où les groupes sont définis, et confirmer ce qu’il signifiait auparavant en voyant à quoi il a été modifié après l’activation de la fonctionnalité de groupe Granular — ce qui donne l’impression de tâtonner dans le noir.

2 « J'aime »
11

C’est une bonne idée… Je pourrais peut-être bidouiller quelque chose avec l’IA pour aller chercher dans tous les endroits où les paramètres basés sur les groupes sont utilisés et sortir s’il est même possible pour anonymous d’accéder à ces éléments.

Il y a un tas de paramètres qui interdisent déjà la sélection du groupe anonymous_users, donc ce sont probablement un bon point de départ… je reviendrai ici avec les résultats.

J’ai des PR pour cela sur lesquels je travaille maintenant :

Il y aura des PR de suivi et des modifications de documentation très bientôt.

3 « J'aime »
12

@Noble_Fish, voici la liste générée par IA des paramètres basés sur les groupes, à quoi sert chaque paramètre et comment les utilisateurs anonymes/connectés s’appliquent à ce paramètre. Sachez que je suis assez confiant quant à son exactitude, mais comme pour tout contenu généré par IA, il est bon de vérifier les faits vous-même.

Je pense que la colonne la plus intéressante est « everyone incluait également anonymous_users avant le changement ? ». Si c’est « Oui », cela signifie que everyone (tout le monde) désignait à la fois les utilisateurs connectés et anonymes avant l’application de ce changement à venir.

Comme vous pouvez le voir, il n’y en a que quelques-uns, donc ce sont les seuls pour lesquels un administrateur devra explicitement ajouter anonymous_users dans les paramètres du site :

  • hidden_post_visible_groups - Je dois en fait modifier celui-ci pour permettre l’inclusion de anonymous_users, le code n’est pas tout à fait adapté à ce changement à venir.
  • lazy_load_categories_groups - Je dois corriger celui-ci aussi, il effectue une vérification redondante de everyone qui est déjà faite dans user.in_any_groups?
  • styleguide_allowed_groups - Cela fonctionne tel quel, mais je vais aussi l’ajuster un peu

Lorsque ce changement à venir deviendra permanent, les groupes logged_in_users (utilisateurs connectés) et anonymous_users (utilisateurs anonymes) seront utilisés exclusivement, et everyone (tout le monde) sera supprimé.

Paramètre Description S’applique à logged_in_users ? S’applique à anonymous_users ? everyone incluait également anonymous_users avant le changement ? Résultat du code
whispers_allowed_groups Autoriser la communication privée dans les sujets pour les membres des groupes spécifiés. Non Non Non everyone, logged_in_users et anonymous_users sont interdits ; le code en temps d’exécution s’attend également à des groupes concrets ou à une appartenance à un groupe.
hidden_post_visible_groups Autoriser les membres de ces groupes à voir les messages masqués. Les utilisateurs du personnel peuvent toujours voir les messages masqués. Oui Non Oui Vérifie everyone avant de rejeter les utilisateurs anonymes ; utilise sinon in_any_groups?.
about_page_hidden_groups Ne pas afficher les membres de groupes spécifiques sur la page /about. Non Non Non Utilise group_users ; les pseudogroupes n’ont pas de lignes de membres.
about_page_extra_groups Groupes à afficher sur la page « À propos » en dessous des modérateurs. Non Non Non Charge les groupes concrets et les membres pour l’affichage.
anonymous_posting_allowed_groups Groupes autorisés à activer la publication anonyme. Oui Non Non Verrouillage pour utilisateur connecté via in_any_groups? ; anonymous_users est interdit.
personal_message_enabled_groups Autoriser les utilisateurs de ces groupes à créer des messages personnels. Oui Non Non Verrouillage pour utilisateur connecté via in_any_groups? ; anonymous_users est interdit.
shared_drafts_allowed_groups Autoriser les utilisateurs de ces groupes à voir et modifier les brouillons partagés. Oui Non Non Verrouillage du gardien pour utilisateur ; anonymous_users est interdit.
here_mention_allowed_groups Groupes autorisés à mentionner @here. Oui Non Non Requiert un utilisateur authentifié ; anonymous_users est interdit.
approve_unless_allowed_groups Les messages des utilisateurs ne faisant pas partie de ces groupes doivent être approuvés. Oui Non Non Verrouillage utilisateur via in_any_groups? ; anonymous_users est interdit.
approve_new_topics_unless_allowed_groups Les nouveaux sujets créés par des utilisateurs ne faisant pas partie de ces groupes doivent être approuvés. Oui Non Non Verrouillage utilisateur via in_any_groups? ; anonymous_users est interdit.
skip_review_media_groups Les utilisateurs en dehors de ces groupes ont leurs messages contenant des médias intégrés envoyés pour révision. Oui Non Non Verrouillage utilisateur via in_any_groups? ; anonymous_users est interdit.
content_localization_allowed_groups Groupes autorisés à mettre à jour le contenu localisé. Oui Non Non Verrouillage du gardien/utilisateur ; anonymous_users est interdit.
email_in_allowed_groups Groupes autorisés à publier de nouveaux sujets via e-mail. Oui Non Non Verrouillage de l’utilisateur expéditeur d’e-mail ; anonymous_users est interdit.
view_raw_email_allowed_groups Groupes pouvant voir le contenu brut des e-mails entrants. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
uploaded_avatars_allowed_groups Spécifie les groupes autorisés à télécharger des photos de profil personnalisées. Oui Non Non Verrouillage utilisateur actuel/cible ; anonymous_users est interdit.
create_topic_allowed_groups Groupes autorisés à créer de nouveaux sujets. Oui Non Non Requiert un utilisateur et utilise in_any_groups? ; anonymous_users est interdit.
topic_timers_allowed_groups Groupes autorisés à définir des compteurs pour les sujets. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
edit_wiki_post_allowed_groups Groupes autorisés à modifier les messages marqués comme wiki. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
edit_post_allowed_groups Groupes autorisés à modifier les messages. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
self_wiki_allowed_groups Autoriser les utilisateurs de ces groupes à transformer leurs propres messages en wiki. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
send_email_messages_allowed_groups Groupes autorisés à envoyer des messages personnels par e-mail. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
flag_post_allowed_groups Groupes autorisés à signaler des messages. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
post_links_allowed_groups Groupes autorisés à inclure des liens dans les messages. Oui Non Non Requiert un utilisateur authentifié ; anonymous_users est interdit.
embedded_media_post_allowed_groups Les utilisateurs de ces groupes sont autorisés à intégrer des éléments multimédias dans un message. Oui Non Non Verrouillage de l’utilisateur actif ; anonymous_users est interdit.
profile_background_allowed_groups Groupes autorisés à télécharger une image de fond de profil. Oui Non Non Verrouillage utilisateur ; anonymous_users est interdit.
user_card_background_allowed_groups Groupes autorisés à télécharger une image de fond pour la fiche utilisateur. Oui Non Non Verrouillage utilisateur ; anonymous_users est interdit.
invite_allowed_groups Groupes autorisés à inviter des utilisateurs. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
ignore_allowed_groups Groupes autorisés à ignorer d’autres utilisateurs. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
delete_all_posts_and_topics_allowed_groups Groupes autorisés à supprimer des messages et des sujets créés par d’autres utilisateurs et à voir le contenu supprimé. Oui Non Non Verrouillage du gardien/utilisateur actuel ; anonymous_users est interdit.
edit_all_topic_groups Autoriser les utilisateurs de ce groupe à modifier les titres, les balises et les catégories des sujets d’autres utilisateurs. Oui Non Non Séparation brute puis in_any_groups? ; anonymous_users est interdit.
edit_all_post_groups Autoriser les utilisateurs de ce groupe à modifier les messages d’autres utilisateurs. Oui Non Non Verrouillage utilisateur via in_any_groups? ; anonymous_users est interdit.
change_post_ownership_allowed_groups Autoriser les utilisateurs de ces groupes à modifier la propriété des messages. Oui Non Non Verrouillage de l’utilisateur actuel ; anonymous_users est interdit.
cross_origin_opener_unsafe_none_groups Groupes de remplacement COOP masqués ; les utilisateurs correspondants obtiennent Cross-Origin-Opener-Policy: unsafe-none. Oui Non Non Requiert current_user.present? ; la sélection anonyme n’a aucun effet en temps d’exécution.
user_api_key_allowed_groups L’appartenance à un groupe est requise pour la génération de clés API utilisateur. Oui Non Non Verrouillage de l’utilisateur actuel ; anonymous_users est interdit.
create_tag_allowed_groups Groupes autorisés à créer des balises. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
edit_tags_allowed_groups Groupes autorisés à modifier les balises, les descriptions de balises et les synonymes de balises. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
tag_topic_allowed_groups Groupes autorisés à ajouter des balises aux sujets. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
pm_tags_allowed_for_groups Autoriser les membres des groupes inclus à baliser n’importe quel message personnel. Oui Non Non Verrouillage du gardien utilisateur ; anonymous_users est interdit.
lazy_load_categories_groups Charger les informations de catégorie paresseusement uniquement pour les utilisateurs de ces groupes. Oui Oui Oui Vérification explicite de everyone plus in_any_groups? du gardien ; anonymous_users est significatif.
chat_allowed_groups Les utilisateurs de ces groupes peuvent discuter, à l’exception des utilisateurs anonymes qui ne peuvent que voir le chat lorsqu’ils sont ajoutés à ce paramètre. Oui Oui Non Le chat des utilisateurs connectés utilise in_any_groups? ; le chat public anonyme vérifie explicitement anonymous_users.
direct_message_enabled_groups Autoriser les utilisateurs de ces groupes à créer des discussions personnelles utilisateur à utilisateur. Oui Non Non Verrouillage du gardien de chat pour utilisateur connecté ; aucun chemin de discussion privée anonyme significatif.
chat_pinning_messages_allowed_groups Les utilisateurs de ces groupes sont autorisés à épingler des messages de discussion. Oui Non Non Requiert un accès au chat/utilisateur actuel ; aucun chemin d’épinglage anonyme.
chat_message_flag_allowed_groups Les utilisateurs de ces groupes sont autorisés à signaler des messages de discussion. Oui Non Non Verrouillage utilisateur ; le chemin anonyme est bloqué par les permissions de chat environnantes.
no_ads_for_groups Ne pas afficher de publicités aux utilisateurs de ces groupes. Oui Non Non Ajouté uniquement au sérialiseur current_user ; aucune charge utile d’utilisateur actuel anonyme.
adsense_exclude_groups Les publicités ne seront pas affichées aux membres de ces groupes. Oui Non Non Indicateur de publicité utilisateur actuel via in_any_groups? ; aucune charge utile d’utilisateur actuel anonyme.
dfp_exclude_groups Les publicités ne seront pas affichées aux membres de ces groupes. Oui Non Non Indicateur de publicité utilisateur actuel via in_any_groups?.
amazon_exclude_groups Les publicités ne seront pas affichées aux membres de ces groupes. Oui Non Non Indicateur de publicité utilisateur actuel via in_any_groups?.
carbonads_exclude_groups Les publicités ne seront pas affichées aux membres de ces groupes. Oui Non Non Indicateur de publicité utilisateur actuel via in_any_groups?.
adbutler_exclude_groups Les publicités ne seront pas affichées aux membres de ces groupes. Oui Non Non Indicateur de publicité utilisateur actuel via in_any_groups?.
composer_ai_helper_allowed_groups Les utilisateurs de ces groupes verront le bouton d’assistant IA dans le composeur. Oui Non Non Verrouillage de l’assistant IA pour utilisateur connecté via in_any_groups?.
post_ai_helper_allowed_groups Groupes d’utilisateurs autorisés à accéder aux fonctionnalités de l’assistant IA dans les messages. Oui Non Non Verrouillage de l’assistant IA pour utilisateur connecté via in_any_groups?.
ai_pm_summarization_allowed_groups Groupes autorisés à créer et voir des résumés dans les messages personnels. Non Non Non Utilise les user.group_ids bruts, donc les pseudogroupes ne correspondent pas.
ai_bot_debugging_allowed_groups Autoriser ces groupes à voir un bouton de débogage affichant la requête et la réponse brutes de l’IA. Oui Non Non Retourne explicitement faux pour les anonymes, puis utilise in_any_groups?.
ai_bot_allowed_groups Lorsque le bot GPT a accès au message personnel, il répondra aux membres de ces groupes. Oui Non Non Les verrous principaux utilisent in_any_groups? ; un chemin de terrain de jeu utilise les group_ids bruts.
ai_bot_public_sharing_allowed_groups Autoriser ces groupes à partager des messages personnels IA avec le public via un lien unique. Oui Non Non Retourne explicitement faux pour les anonymes, puis utilise in_any_groups?.
assign_allowed_on_groups Les utilisateurs de ces groupes sont autorisés à assigner des sujets. Non Non Non Utilise les user.group_ids/GroupUser bruts ; les pseudogroupes n’ont pas de lignes.
discourse_post_event_allowed_on_groups Groupes autorisés à créer des événements. Non Non Non groups.where(id: ...) brut ; everyone est traité comme un cas spécial, mais logged_in_users ne l’est pas.
discourse_kanban_manage_board_allowed_groups Groupes autorisés à créer et configurer des tableaux kanban. Oui Non Non Le gardien utilise in_any_groups?, mais les contrôleurs d’écriture requièrent une connexion.
create_policy_allowed_groups L’appartenance à un groupe est requise pour ajouter des règles aux messages. Oui Non Non Verrouillage message/utilisateur via in_any_groups?.
flag_posts_voting_comments_allowed_groups Groupes autorisés à signaler un commentaire de vote sur un message. Oui Non Non Verrouillage utilisateur via in_any_groups?.
allow_solved_in_groups Autoriser le marquage des solutions dans les messages de groupe pour ces groupes. Aucun verrouillage utilisateur Aucun verrouillage utilisateur Aucun verrouillage utilisateur Correspond à topic.allowed_groups du message personnel, pas à l’appartenance de l’utilisateur actuel.
accept_all_solutions_allowed_groups Groupes autorisés à accepter des solutions sur n’importe quel sujet. Oui Non Non Verrouillage utilisateur authentifié/actuel via in_any_groups?.
discourse_templates_groups_allowed_private_templates Groupes autorisés à utiliser des modèles privés. Non Non Non GroupUser.exists? brut ; seul everyone est traité comme un cas spécial.
poll_create_allowed_groups Les groupes autorisés à créer des sondages. Oui Non Non Verrouillage utilisateur actif/actuel via in_any_groups?.
styleguide_allowed_groups Limite la visibilité du guide de style aux membres des groupes fournis. Oui Oui Oui Le contrôleur gère explicitement anonymous_users ; il autorisait également les anonymes via everyone avant le changement.
2 « J'aime »
13

Séparez ces ajustements dans une nouvelle PR :

2 « J'aime »
14

@moin cette PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub est maintenant fusionnée et j’ajoute de la documentation dans DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub . J’ai corrigé discourse-copy-post avec DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub et maintenant je passe en revue nos autres plugins officiels pour voir si d’autres ont besoin du même traitement (par exemple, vous avez déjà pointé vers GitHub - discourse/discourse-unanswered-filter · GitHub )

Pour votre propre Filter Favorites , vous pouvez voir l’exemple de copy-post que j’ai fait, mais en gros vous devez ajouter resolve_group_membership: true à la fois à default_favorite_filters_groups et à custom_favorite_filters_allowed_groups , alors ils seront disponibles en tant que booléens selon les appartenances aux groupes de l’utilisateur sur settings en tant que settings.user_in_default_favorite_filters_groups et settings.user_in_custom_favorite_filters_allowed_groups respectivement, et vous n’avez plus besoin de vérifier manuellement les identifiants de groupe des utilisateurs sur le frontend.

Je changerais la valeur par défaut de default_favorite_filters_groups en 4|5 dans votre composant de thème, qui correspond aux utilisateurs connectés et anonymes, plutôt qu’à 0 (everyone) qui sera bientôt supprimé.

Je ferai une note pour exécuter une migration de la base de données sur les paramètres de thème lorsque je me débarrasserai du groupe everyone, j’en ai besoin pour les paramètres du site aussi, cela se produira lorsque le changement à venir deviendra permanent dans les prochaines semaines (selon si d’autres problèmes surgissent et à quelle vitesse je parviens à corriger d’autres thèmes/composants qui nécessitent l’ajout de resolve_group_membership).

Non, il n’y a pas de moyen de faire cela pour le moment comme c’est le cas pour les paramètres du site… Je ne pense pas que ce soit nécessaire d’ajouter cela maintenant, vous pouvez simplement mentionner cela dans la description du paramètre et protéger avec currentUser dans le frontend de toute façon. Peut-être que dans le futur, j’ajouterai cela s’il y a plus besoin.

2 « J'aime »
15

Fonctionne-t-il également pour le type groups dans les paramètres d’objet ?

16

Non, est-ce que c’est nécessaire ? Je n’étais pas au courant de ça, je ne sais pas si c’est utilisé pour les permissions ou non.

17

Je pense qu’il est utilisé, par exemple, dans Discourse Group Sidebar Menus afin que les administrateurs puissent configurer quels groupes doivent pouvoir voir chaque section de la barre latérale, et il est utilisé dans Notification Banners pour configurer la visibilité de chaque bannière.

J’ai supposé que vous l’utiliseriez également dans votre composant publicitaire. Mais il semble que celui-ci repose plutôt sur une chaîne de noms de groupes.

Je préfère généralement les paramètres de type groupe, car ils aident l’administrateur à saisir facilement les groupes via un menu déroulant, tandis qu’ils s’appuient sur des identifiants de groupe, qui sont moins susceptibles de changer que les noms. Et je trouve cela déroutant si la liste des groupes dans un paramètre objet et le type de liste ne fonctionnent pas de la même manière.

Pour moi, écrire "everyone" résultera également de "trust_level_0" car cela ne fonctionne pas pour les visiteurs est différent de la nouvelle version, où le menu déroulant propose explicitement "anonymous_users" - même si je dis que cela ne fonctionnera pas. Si le dire dans la description suffisait, vous auriez pu faire la même chose pour les paramètres du site. Pour l’administrateur utilisant les deux types de paramètres, il sera difficile de comprendre pourquoi, dans certains endroits, les groupes qui ne fonctionnent pas sont masqués, et dans d’autres, ils ne le sont pas - non pas parce que le créateur du composant s’en souciait moins, mais parce que ce n’est pas encore possible à cet endroit.

2 « J'aime »