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 comptelogged_in_users (ID 5)– Représente tous les utilisateurs connectés à votre site, avec un effet similaire au groupe automatiquetrust_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.

