La voie vers une stabilité, puis une pérennité, des permissions pour les groupes granulaires, anonymes et connectés

[martin (Martin Brennan)]

Ceci est un sujet complémentaire à Granular group-based permissions for anonymous and logged in users , et il est en cours de rédaction (WIP).

---

Il reste encore quelques endroits dans diverses bases de code (core, plugins et thèmes) qui référencent directement le groupe everyone (ou l’ID de groupe 0), sans tenir compte de ce changement à venir, ou sans utiliser user.in_any_groups? ou les différentes méthodes de gardien utilisées pour gérer cela.

Pour référence rapide, voici certains IDs de groupes automatiques :

• 0 - everyone
• 1 - admins
• 2 - moderators
• 3 - staff
• 4 - anonymous_users
• 5 - logged_in_users

Ce sujet sert de lieu central pour suivre les correctifs apportés à ce système à mesure que nous approchons de la version stable. Les plugins et thèmes personnalisés pour les clients Discourse ne sont pas suivis ici ; j’aurai une liste interne séparée à cet effet.

Problèmes de haute priorité

Problème soulevé par Moin :

@martin

1. anonymous_users et logged_in_users ne figurent pas du tout dans le sélecteur de groupes. Je pense qu’il est sûr de permettre leur utilisation ici maintenant, ainsi, cela n’aura pas d’importance si vous avez ajouté everyone à disallowed_groups si le changement à venir est désactivé.
2. Corriger Guardian::AnonymousUser#in_any_groups? pour respecter anonymous_users lorsque le changement à venir est désactivé.
3. Ajouter le même alias de temps de lecture pour 0 (everyone) → 5 (logged_in_users) pour les paramètres des thèmes, comme nous le faisons pour les paramètres du site.

• Core
  • À propos - apply_excluded_groups n’est utilisé que pour masquer les modérateurs et administrateurs sélectionnés des groupes dans about_page_hidden_groups. Il n’a pas de sens d’utiliser des groupes pseudo comme 0|4|5 ici ; ils devraient être ajoutés à disallowed_groups. Nous devons également mettre à jour la description du paramètre, car elle est trompeuse.
  • EditCategoryTabsController - Dans _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub , nous ne considérons que les groupes visibles ; cela devrait être une vérification côté serveur, comme evaluate pour les ACL.

Plugins Core

• Discourse Templates
  • • can_use_private_templates? référence toujours directement everyone et n’utilise pas l’abréviation _map sur les paramètres du site.
• Discourse AI
  • • can_see_summary? dans les extensions de gardien n’utilise pas user.in_any_groups?
  • • can_attach? dans AiBot::Playground n’utilise pas user.in_any_groups?
  • • addTopicAdminMenuButton dans ai-translation-topic-admin examine currentUser.groups côté client, ce qui n’est pas fiable ; effectuez plutôt une vérification côté serveur pour content_localization_allowed_groups
• Discourse Assign. Il y a beaucoup de problèmes ici.
  • Plutôt que user_ids_in_groups dans AssignmentPermissions, nous devrions utiliser user_ids_in_groups
  • assign_allowed_on_groups devrait avoir 0|4|5 ajouté à disallowed_groups ; aucun de ces groupes n’a de sens ici, seuls les groupes concrets comptent.

Autres plugins

• Activity Pub
  • Supprimer la vérification côté client de showStatusToUser sur user.groups et la vérification de everyone. Modifier activity_pub_post_status_visibility_groups pour qu’il ait 4|5 par défaut.
• Suggested Edits
  • user_in_suggested_edits_group? doit utiliser user.in_any_groups? dans GuardianExtensions. Ajouter 1 aux mandatory_groups de suggested_edits_review_groups et supprimer le cas particulier administrateur dans can_review_suggested_edits_in_topic_list
  • Ajouter 0|4|5 aux disallowed_groups de suggested_edits_review_groups et suggested_edits_suggest_groups ; ce paramètre n’est pas vraiment destiné à être utilisé avec ces groupes pseudo
• Resenha
  • Supprimer le contournement untargetable_group_ids dans public_room_message_bus_targets car cela a été traité dans FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub
  • Modifier la valeur par défaut de resenha_allowed_groups de 0 à 4|5

Thèmes

Composants

Problèmes de basse priorité

• Core
  • is_in_edit_topic_groups dans TopicGuardian devrait utiliser l’extension _map pour le paramètre du site
  • Roleable#whisperer? devrait utiliser user.in_any_groups? et se débarrasser de la vérification administrateur ; ajouter 1 au paramètre whispers_allowed_groups en tant que mandatory_values
  • Ajouter 0|4 aux disallowed_groups du paramètre du site allow_solved_in_groups ; cela ne concerne que les MP
  • Ajouter 0|4|5 aux disallowed_groups de about_page_extra_groups ; cela est censé ne traiter que des groupes concrets sur la page À propos
  • Note dans can_view? pour PresenceChannel indiquant que nous devons supprimer la vérification Group::AUTO_GROUPS[:everyone] lorsque ce changement à venir passera à Permanent

Plugins Core

• Chat
  • Note pour everyone_allowed dans divers endroits de la logique d’auto-connexion/auto-déconnexion du chat et de users_with_unreads pour supprimer la vérification :everyone lorsque ce changement à venir passera à Permanent
  • Mettre à jour chat_allowed_group_ids dans Chat::Publisher pour supprimer le groupe pseudo spécial, car, comme indiqué dans FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub , MessageBus peut désormais gérer correctement les groupes pseudo
• Assign
  • Supprimer add_model_callback(Group) dans plugin.rb, c’est du code mort/irrélevant qui examine les noms de groupes au lieu des IDs

Autres plugins

• Code Review
  • La vérification can_review_code? sur code_review_allowed_groups n’utilise pas l’extension _map et n’utilise pas user.in_any_groups?. Ajouter 1 aux mandatory_groups du paramètre et supprimer la vérification administrateur spéciale dans le gardien. Ajouter 0|4|5 aux disallowed_groups.
• Needs Love
  • La vérification can_needs_love? sur needs_love_allowed_groups n’utilise pas l’extension _map et n’utilise pas user.in_any_groups?. Ajouter 1 aux mandatory_groups du paramètre et supprimer la vérification administrateur spéciale dans le gardien. Ajouter 0|4|5 aux disallowed_groups.
• Staff Alias
  • La vérification can_post_as_staff_alias sur staff_alias_allowed_groups n’utilise pas l’extension _map et n’utilise pas user.in_any_groups?. Ajouter 0|4|5 aux disallowed_groups

Thèmes

Composants

Prochaines étapes pour la migration

• Migrer le modèle AiAgent allowed_group_ids