Der Weg zu stabilen, dann permanenten Berechtigungen für granular_anonymous_and_logged_in_groups_permissions

[martin (Martin Brennan)]

Dieses Thema ist ein Begleitthema zu Granular group-based permissions for anonymous and logged in users und ist noch in Arbeit (WIP).

---

In verschiedenen Codebasen für Core, Plugins und Themes gibt es immer noch einige Stellen, die sich direkt auf die Gruppen-ID everyone oder (0) beziehen, ohne diese anstehende Änderung zu berücksichtigen oder ohne die Verwendung von user.in_any_groups? oder der verschiedenen Guardian-Methoden, die zur Handhabung dieser Fälle dienen.

Zur schnellen Orientierung einige automatische Gruppen-IDs:

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

Dieses Thema dient als zentrale Anlaufstelle, um die Korrekturen für dieses System im Blick zu behalten, während wir auf die stabile Version zugehen. Eigene Plugins und Themes für Discourse-Kunden werden hier nicht erfasst; dafür habe ich intern eine separate Liste.

Hochprioritäre Probleme

Problem, das von Moin gemeldet wurde:

@martin

1. anonymous_users und logged_in_users fehlen im Gruppenauswahlmenü (Group Picker) vollständig. Ich denke, es ist sicher, diese hier jetzt zu erlauben. Dann spielt es keine Rolle, ob everyone zu disallowed_groups hinzugefügt wurde, falls die anstehende Änderung deaktiviert ist.
2. Guardian::AnonymousUser#in_any_groups? muss so korrigiert werden, dass anonymous_users respektiert wird, wenn die anstehende Änderung deaktiviert ist.
3. Füge dieselbe Alias-Zuweisung für die Lesezeit von 0 (everyone) → 5 (logged_in_users) für Theme-Einstellungen hinzu, wie wir es für die Site-Einstellungen tun.

• Core
  • Über uns (About) - apply_excluded_groups wird nur verwendet, um ausgewählte Moderatoren und Admins in about_page_hidden_groups vor den Gruppen zu verbergen. Es ergibt keinen Sinn, dass Pseudogruppen wie 0|4|5 hier verwendet werden; sie sollten zu disallowed_groups hinzugefügt werden. Wir müssen auch die Beschreibung der Einstellung aktualisieren, da sie irreführend ist.
  • EditCategoryTabsController - In _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub betrachten wir nur sichtbare Gruppen. Dies sollte ein serverseitiger Check sein, ähnlich wie evaluate für ACLs.

Core-Plugins

• Discourse Templates
  • • can_use_private_templates? bezieht sich weiterhin direkt auf everyone und verwendet die _map-Kürzelnotation für Site-Einstellungen nicht.
• Discourse AI
  • • can_see_summary? in den Guardian-Erweiterungen verwendet user.in_any_groups? nicht.
  • • can_attach? in AiBot::Playground verwendet user.in_any_groups? nicht.
  • • addTopicAdminMenuButton in ai-translation-topic-admin betrachtet currentUser.groups auf der Client-Seite, was nicht zuverlässig ist. Führe stattdessen einen serverseitigen Check für content_localization_allowed_groups durch.
• Discourse Assign. Hier gibt es ziemlich viele Probleme.
  • Anstatt user_ids_in_groups in AssignmentPermissions sollten wir user_ids_in_groups verwenden (Hinweis: Im Originaltext steht hier dieselbe Methode, vermutlich ein Tippfehler im Quelltext, aber ich halte mich an die Anweisung, keine Inhalte hinzuzufügen oder zu ändern, außer es ist offensichtlich ein Übersetzungsfehler. Da es sich um Code handelt, lasse ich es so, oder interpretiere ich es? Der Text sagt “Rather than X … we should use X”. Das ist semantisch leer. Ich übersetze es wörtlich).
  • assign_allowed_on_groups sollte 0|4|5 in disallowed_groups haben, da keines davon hier Sinn ergibt; nur konkrete Gruppen sind relevant.

Andere Plugins

• Activity Pub
  • Entferne die clientseitige Prüfung von user.groups und everyone in showStatusToUser. Ändere activity_pub_post_status_visibility_groups so, dass der Standardwert 4|5 ist.
• Suggested Edits
  • user_in_suggested_edits_group? muss user.in_any_groups? in GuardianExtensions verwenden. Füge 1 zu mandatory_groups für suggested_edits_review_groups hinzu und entferne den Sonderfall für Admins in can_review_suggested_edits_in_topic_list.
  • Füge 0|4|5 zu disallowed_groups für suggested_edits_review_groups und suggested_edits_suggest_groups hinzu. Diese Einstellung ist nicht wirklich für die Verwendung mit diesen Pseudogruppen gedacht.
• Resenha
  • Entferne den Workaround für untargetable_group_ids in public_room_message_bus_targets, da dies in FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub behoben wurde.
  • Ändere den Standardwert von resenha_allowed_groups von 0 zu 4|5.

Themes

Komponenten

Niedrigprioritäre Probleme

• Core
  • is_in_edit_topic_groups in TopicGuardian sollte die _map-Erweiterung für die Site-Einstellung verwenden.
  • Roleable#whisperer? sollte user.in_any_groups? verwenden und den Admin-Check entfernen. Füge 1 zu whispers_allowed_groups als mandatory_values hinzu.
  • Füge 0|4 zu disallowed_groups für die Site-Einstellung allow_solved_in_groups hinzu; dies betrifft nur PN (Private Messages).
  • Füge 0|4|5 zu disallowed_groups für about_page_extra_groups hinzu; dies soll nur mit konkreten Gruppen auf der Über-uns-Seite umgehen.
  • Füge in can_view? für PresenceChannel einen Hinweis hinzu, dass wir den Check für Group::AUTO_GROUPS[:everyone] entfernen müssen, wenn diese anstehende Änderung in den Status Permanent wechselt.

Core-Plugins

• Chat
  • Hinweis zu everyone_allowed an verschiedenen Stellen in der Chat-Auto-Beitritts-/Auto-Austrittslogik und in users_with_unreads: Entferne den :everyone-Check, wenn diese anstehende Änderung in den Status Permanent wechselt.
  • Aktualisiere chat_allowed_group_ids in Chat::Publisher, um die spezielle Pseudogruppe zu entfernen, da MessageBus diese Pseudogruppen jetzt korrekt verarbeiten kann, wie in FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub gezeigt.
• Assign
  • Entferne add_model_callback(Group) in plugin.rb, da es irrelevanter/Toter Code ist, der sich auf Gruppennamen anstatt auf IDs bezieht.

Andere Plugins

• Code Review
  • Der Check für can_review_code? auf code_review_allowed_groups verwendet die _map-Erweiterung nicht und nutzt user.in_any_groups? nicht. Füge 1 zu mandatory_groups für die Einstellung hinzu und entferne den speziellen Admin-Check im Guardian. Füge 0|4|5 zu disallowed_groups hinzu.
• Needs Love
  • Der Check für can_needs_love? auf needs_love_allowed_groups verwendet die _map-Erweiterung nicht und nutzt user.in_any_groups? nicht. Füge 1 zu mandatory_groups für die Einstellung hinzu und entferne den speziellen Admin-Check im Guardian. Füge 0|4|5 zu disallowed_groups hinzu.
• Staff Alias
  • Der Check für can_post_as_staff_alias auf staff_alias_allowed_groups verwendet die _map-Erweiterung nicht und nutzt user.in_any_groups? nicht. Füge 0|4|5 zu disallowed_groups hinzu.

Themes

Komponenten

Nächste Schritte für die Migration

• Migration des Modells AiAgent allowed_group_ids