# Permissions granulaires basées sur les groupes pour les utilisateurs anonymes et connectés
**URL:** https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273
**Category:** Announcements
**Tags:** groups
**Created:** [Mai 13, 2026, 1:18 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273 "2026-05-13T01:18:57Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Mai 13, 2026, 1:18 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/1 "2026-05-13T01:18:57Z")
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`.
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.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [Mai 13, 2026, 6:42 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/3 "2026-05-13T06:42:14Z")
Attends… quoi 😳 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 ?
> [@martin](#):
>
> Toute option ayant `everyone` comme groupe sélectionné sera automatiquement convertie en l’ID `logged_in_users`.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Mai 13, 2026, 6:45 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/4 "2026-05-13T06:45:09Z")
> [@Jagster](#):
>
> Attends… quoi 😳 Cela signifie-t-il que toutes les catégories qui sont maintenant publiques (tout le monde)
Non, car :
> [@martin](#):
>
> ### Qu’en est-il des permissions des tags et des catégories ?
>
> Ces permissions resteront inchangées, car leur notion de « tout le monde » diffère à plusieurs égards et ne repose pas sur le groupe automatique sous-jacent.
Cela affecte uniquement les paramètres du site de type liste de groupes qui permettent actuellement de sélectionner « tout le monde » comme suit :
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [Juin 7, 2026, 8:59 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/5 "2026-06-07T20:59:52Z")
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](https://github.com/discourse/discourse-copy-post/blob/6f165b284974967743ec8d2e043b483018e59ace/javascripts/discourse/api-initializers/discourse-copy-post.js#L13) 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](https://github.com/discourse/discourse-copy-post/pull/5#pullrequestreview-2551490016), 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](https://meta.discourse.org/t/filter-favorites/386594) 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](https://github.com/discourse/discourse-unanswered-filter/blob/4ed3ba8896e54376bf30b4b1ddbd452f89a88981/javascripts/discourse/initializers/unanswered-filter.js#L19), 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.
---
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [Juin 7, 2026, 10:28 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/6 "2026-06-07T22:28:28Z")
3 messages ont été fusionnés dans un sujet existant : [Modernisation du thème Foundation](https://meta.discourse.org/t/modernizing-the-foundation-theme/395331/99)
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juin 8, 2026, 5:23 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/7 "2026-06-08T05:23:46Z")
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.
> [@Moin](#):
>
> 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 ?
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é.
> [@Moin](#):
>
> J’ai l’impression de manquer 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.
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` :
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.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juin 26, 2026, 1:46 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/9 "2026-06-26T01:46:21Z")
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 🤞
---
### Author:  [@Noble\_Fish](https://meta.discourse.org/u/Noble_Fish)
#### Post date: [Juillet 5, 2026, 8:02 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/10 "2026-07-05T08:02:43Z")
> [@martin](#):
>
> Dans certains cas, les gens considèrent que `@everyone` signifie « tous les utilisateurs anonymes et tous les utilisateurs connectés »
C’est exactement mon cas 🙃 ; 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.
> [@martin](#):
>
> la plupart du temps, cela ne signifie que « tous les utilisateurs connectés ».
> [@martin](#):
>
> Ces permissions resteront inchangées, car leur concept de « tout le monde » diffère à plusieurs égards
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.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 6, 2026, 1:59 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/11 "2026-07-06T01:59:03Z")
> [@Noble\_Fish](#):
>
> Je me demande s’il existe un tableau pour distinguer le sens de ce terme dans différents contextes. Ces différences sont à la fois déroutantes et inquiétantes — car 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 granulaire — ce qui ressemble à tâtonner dans le noir.
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.
> [@martin](#):
>
> Mise à jour rapide, j’ai une idée sur la manière de gérer cela, et nous en discutons en interne. J’espère que cela ne prendra pas trop de temps 🤞
J’ai des PR pour cela sur lesquels je travaille maintenant :
>
>
> Currently, theme settings with \`type: list\` and \`list\_type: group\`
> require clie…nt-side permission checks, but \`currentUser.groups\` only
> includes visible groups, not all groups the user belongs to. This makes
> permission checks unreliable and can leak hidden group membership.
>
> To address this, this commit adds an opt-in \`resolve\_group\_membership:
> true\` option that replaces the group ID list with a user\_in\_SETTING\_NAME
> boolean resolved server-side via \`guardian.in\_any\_groups?\`. The original
> group list is removed from the frontend payload to prevent leaking group
> IDs.
>
> Since theme settings are cached per-theme (not per-user), the resolution
> happens after the cache lookup during per-request serialization in
> \`ApplicationLayoutPreloader#activated\_themes\_json\`.
>
> Example YAML:
>
> \`\`\`yaml
> copy\_button\_allowed\_groups:
> type: list
> list\_type: group
> resolve\_group\_membership: true
> default: "1|3"
> \`\`\`
>
> Frontend usage:
>
> \`\`\`javascript
> if (!settings.user\_in\_copy\_button\_allowed\_groups) return;
> \`\`\`
Il y aura des PR de suivi et des modifications de documentation très bientôt.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 6, 2026, 5:54 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/12 "2026-07-06T05:54:07Z")
@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. |
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 6, 2026, 6:40 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/13 "2026-07-06T06:40:08Z")
> [@martin](#):
>
> Comme vous pouvez le voir, il n’y en a que quelques-uns, donc ce sont les seuls pour lesquels un administrateur devrait explicitement ajouter `anonymous_users` dans les paramètres du site :
Séparez ces ajustements dans une nouvelle PR :
>
>
> Some minor changes based on findings in https://meta.discourse.org/t/granular-gr…oup-based-permissions-for-anonymous-and-logged-in-users/402273/12?u=martin , see individual commits for details.
>
> \- \*\*DEV: Cleanup hidden\_post\_visible\_groups usage\*\*
> \- \*\*DEV: Cleanup can\_lazy\_load\_categories?\*\*
> \- \*\*FIX: Access check for styleguide\_allowed\_groups in styleguide\*\*
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 8, 2026, 6:36 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/14 "2026-07-08T06:36:10Z")
@moin cette PR [DEV: Add resolve\_group\_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub](https://github.com/discourse/discourse/pull/41360) 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](https://github.com/discourse/discourse/pull/41537) . J’ai corrigé discourse-copy-post avec [DEV: Use resolve\_group\_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub](https://github.com/discourse/discourse-copy-post/pull/37) 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](https://github.com/discourse/discourse-unanswered-filter) )
Pour votre propre [Filter Favorites](https://meta.discourse.org/t/filter-favorites/386594) , 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.
> [@Moin](#):
>
> Le paramètre par défaut pour les filtres par défaut est « everyone » (tout le monde), 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 pour ‘logged\_in\_users’ (utilisateurs connectés) même si je l’ai spécifiquement sélectionné. Ai-je besoin de 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 changer cela individuellement après que vous ayez exécuté la migration ?
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`).
> [@Moin](#):
>
> Donc ici, il serait logique que je n’autorise pas `anonymous_users` en tant que sélection. Comment puis-je faire cela dans un composant de thème ? Y a-t-il déjà un exemple pour cela ?
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.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [Juillet 8, 2026, 6:44 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/15 "2026-07-08T18:44:19Z")
Fonctionne-t-il également pour le type `groups` dans les paramètres d’objet ?
> [@Discourse](#):
>
> - `groups` : La valeur de la propriété est un tableau d’identifiants de groupe valides.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 9, 2026, 12:57 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/16 "2026-07-09T00:57:35Z")
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.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [Juillet 9, 2026, 5:18 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/17 "2026-07-09T05:18:00Z")
Je pense qu’il est utilisé, par exemple, dans [Discourse Group Sidebar Menus](https://meta.discourse.org/t/discourse-group-sidebar-menus/394653) 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](https://meta.discourse.org/t/notification-banners/325279) pour configurer la visibilité de chaque bannière.
J’ai supposé que vous l’utiliseriez également dans votre [composant publicitaire](https://github.com/discourse/discourse-custom-topic-list-ads-component/). 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.
> [@martin](#):
>
> 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 j’ajouterai cela à l’avenir s’il y a plus de besoin.
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.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 9, 2026, 11:42 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/18 "2026-07-09T23:42:45Z")
> [@Moin](#):
>
> Je pense qu’il est utilisé, par exemple, dans les menus latéraux des groupes de Discourse, afin que les administrateurs puissent configurer quels groupes doivent pouvoir voir chaque section de la barre latérale, et il est utilisé dans les bannières de notification 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 sur une chaîne de noms de groupes à la place.
> Je préfère utiliser 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 par rapport aux noms. Et je pense que c’est confus si la liste des groupes dans un paramètre objet et le type de liste ne fonctionnent pas de la même manière.
D’accord, merci d’avoir trouvé des exemples, il faudra intégrer ce changement dans les objets de paramètres de thème avec le type groupe. Celui-ci, par exemple, issu des menus latéraux des groupes, je pense que je le ferai fonctionner de la même manière, de sorte que vous ayez ceci dans la configuration :
```yaml
groups:
type: groups
required: true
resolve_group_memberships: true
validations:
max: 20
```
Ensuite, côté client, `groups` deviendrait `user_in_groups` en tant que booléen.
La fonctionnalité `disallowed_groups` (groupes interdits) n’est peut-être pas si difficile en réalité… en reprenant l’exemple ci-dessus, vous obtiendriez ceci pour éliminer les `anonymous_users` (utilisateurs anonymes) :
```yaml
groups:
type: groups
required: true
resolve_group_memberships: true
disallowed_groups: "4"
validations:
max: 20
```
Et pour les paramètres de thème de type groupe standard :
```yaml
copy_button_allowed_groups:
type: list
list_type: group
default: "11" # trust_level_1
disallowed_groups: "4" # anonymous_users
description: "Sélectionnez les groupes autorisés à utiliser le bouton copier."
resolve_group_membership: true
```
Je verrai ce que je peux faire pour ajouter cette fonctionnalité.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 16, 2026, 3:48 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/19 "2026-07-16T03:48:29Z")
> [@martin](#):
>
> Par exemple, celui-ci provenant des menus latéraux des groupes, je pense que je le ferais fonctionner de la même manière, donc vous auriez ceci dans la configuration :
>
> ```plaintext
> groups:
> type: groups
> required: true
> resolve_group_memberships: true
> validations:
> max: 20
>
> ```
>
> Ensuite, côté client, `groups` deviendrait `user_in_groups` en tant que booléen.
J’ai implémenté cela dans la PR ci-dessous :
>
>
> Followup 7e77ce4bd3889820d67b52a5788357ac6f7b2f58
>
> We need to automatically re…solve group membership into a boolean
> for theme object type settings which are of the group type, similar
> to what we did in the original commit above for group list type
> settings.
>
> This behaves in the same way -- for an object setting schema like this:
>
> \`\`\`
> menu\_sections:
> type: objects
> default:
> - name: section 1
> groups:
> - 1
> - 3
> schema:
> name: menu section
> properties:
> name:
> type: string
> groups:
> type: groups
> resolve\_group\_membership: true
> \`\`\`
>
> We replace \`groups\` with a boolean \`user\_in\_groups\` (groups is just
> the property name, it could be foo\_bar etc.) and then you can
> do this on the client:
>
> \`\`\`
> for (const section of settings.menu\_sections) {
> if (section.user\_in\_groups) {
> // User is in at least one selected group for this section.
> }
> }
> \`\`\`
>
> Rather than inspecting the \`currentUser.groups\`, which only includes
> visible groups, not all groups the user is a member of. This allows
> for more accurate permission checks for theme settings that are group
> based.
>
> Also c.f. https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/18?u=martin
Et @Lilly, j’ai créé une PR pour ton composant de thème group-sidebar-menus à partir d’un fork, qui applique cette fonctionnalité de manière rétrocompatible :
>
>
> See https://github.com/discourse/discourse/pull/41756, which must
> be merged fir…st
>
> \`resolve\_group\_membership\` can now be used on group type of theme setting object settings, so instead of relying on currentUser.groups which only has visible groups in the client, we can use \`user\_in\_groups\` which is automatically resolved from the server side
>
> This is backwards-compatible with sites that don't yet have the
> core functionality deployed
Je vais travailler sur la partie `disallowed_groups` ensuite.
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [Juillet 16, 2026, 4:04 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/20 "2026-07-16T04:04:28Z")
merci ! je jeterai un oeil demain quand j’aurai un peu de temps :chefs_kiss:
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juillet 17, 2026, 4:11 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/21 "2026-07-17T04:11:50Z")
> [@martin](#):
>
> Je vais travailler sur la partie `disallowed_groups` ensuite.
C’est fait dans cette PR 🙂
>
>
> Further following on from bee1be8599c977f286a248e6d89fd5b73f398b42,
> this brings… greater parity between theme settings and site settings.
>
> This commit adds a new \`disallowed\_groups\` field to theme and component
> settings, which allows theme authors to specify groups that cannot be selected
> by admins for a particular list type or object group type setting.
>
> This is useful for cases where the group-based setting isn't usable
> for a group like e.g. anonymous\_users, no point allowing them for
> a setting that requires a user to be logged in to take effect.
>
> c.f. https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/18?u=martin
>
> \### List groups
>
> With \`disallowed\_groups: "4|5"\` specified (\`logged\_in\_users\` & \`anonymous\_users\`)
>
> \
>
> \### Object groups
>
> With \`disallowed\_groups: "4|5"\` specified (\`logged\_in\_users\` & \`anonymous\_users\`)
>
> \
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [Juillet 18, 2026, 12:31 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/22 "2026-07-18T00:31:05Z")
encore merci pour ta PR sur mon composant de thème, ainsi que pour les corrections de code (j’ai remarqué que tu avais aussi un peu nettoyé ma syntaxe). 🤗
> [@martin](#):
>
> Je vais travailler sur la partie `disallowed_groups` ensuite.
j’ai jeté un œil à cette PR — c’est une excellente amélioration. Il sera utile de pouvoir cibler avec précision certains groupes en empêchant d’autres d’apparaître dans les paramètres de listes de groupes.
[Next page](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273.md?page=2)