Le chemin vers la stabilité, puis la pérennité, pour granular_anonymous_and_logged_in_groups_permissions

[martin (Martin Brennan)]

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

---

Il reste encore quelques endroits dans les différentes bases de code du cœur (core), des plugins et des 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 diverses méthodes de gardien (guardian) 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 de 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 séparée en interne à cet effet.

Problèmes de haute priorité

Problème soulevé par Moin :

@martin

1. anonymous_users et logged_in_users ne sont pas du tout dans le sélecteur de groupes. Je pense qu’il est sûr d’autoriser ces groupes 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 de 0 (everyone) → 5 (logged_in_users) pour les paramètres de thème, ce que nous faisons pour les paramètres du site.

• Cœur (Core)
  • À propos (About) - apply_excluded_groups est uniquement utilisé pour masquer les modérateurs et administrateurs sélectionnés des groupes dans about_page_hidden_groups. Il n’a pas de sens que des groupes pseudo comme 0|4|5 soient utilisés 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 regardons que les groupes visibles, cela devrait être une vérification côté serveur comme evaluate pour les ACL.

Plugins du cœur (Core plugins)

• Discourse Templates
  • • can_use_private_templates? référence toujours everyone directement et n’utilise pas le raccourci _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 regarde 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. 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 user.groups et de la vérification everyone dans showStatusToUser. Changer 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 de l’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
  • Changer la valeur par défaut de resenha_allowed_groups de 0 à 4|5

Thèmes

Composants

Problèmes de basse priorité

• Cœur (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 de l’administrateur, ajouter 1 au paramètre whispers_allowed_groups en tant que mandatory_values
  • Ajouter 0|4 aux disallowed_groups pour le paramètre du site allow_solved_in_groups, cela ne concerne que les MP (messages privés)
  • Ajouter 0|4|5 aux disallowed_groups pour 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 du cœur (Core plugins)

• Chat
  • Note pour everyone_allowed à divers endroits dans la logique de chat auto-join/auto-leave et 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 dans FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub MessageBus peut maintenant gérer les groupes pseudo correctement
• Assign
  • Se débarrasser de add_model_callback(Group) dans plugin.rb, c’est du code obsolète/irrélevant qui regarde 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 pour le paramètre et se débarrasser de la vérification spéciale de l’administrateur 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 pour le paramètre et se débarrasser de la vérification spéciale de l’administrateur 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

À définir (TBA)