Der Weg zu stabilen und dann permanenten Berechtigungen für granulare anonyme und angemeldete Gruppen

[martin (Martin Brennan)]

Dies 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 noch einige Stellen, die sich direkt auf die everyone- oder (0) Gruppen-ID beziehen, ohne diese anstehende Änderung zu berücksichtigen oder ohne die Verwendung von user.in_any_groups? oder der verschiedenen Guardian-Methoden, die zur Behandlung dieses Themas 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 zusteueren. Eigene Plugins und Themes für Discourse-Kunden werden hier nicht erfasst; ich habe intern eine separate Liste dafür.

Hochprioritäre Probleme

Problem, das von Moin angesprochen wurde:

@martin

1. anonymous_users und logged_in_users fehlen im Gruppenauswahlmenü vollständig. Ich denke, es ist sicher, diese hier jetzt zuzulassen, 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? so korrigieren, dass anonymous_users respektiert wird, wenn die anstehende Änderung deaktiviert ist.
3. Dieselbe Alias-Zuweisung für Lesezeit von 0 (everyone) → 5 (logged_in_users) für Theme-Einstellungen hinzufügen, wie wir es für Site-Einstellungen tun.

• Core
  • Über uns - apply_excluded_groups wird nur verwendet, um ausgewählte Moderatoren und Admins in about_page_hidden_groups vor den Gruppen zu verbergen. Es macht keinen Sinn, Pseudogruppen wie 0|4|5 hier zu verwenden; 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 https://github.com/discourse/discourse/blob/86552acfbaf816db3b9db5f761f5e9f2bd221c21/frontend/discourse/admin/controllers/edit-category/tabs.js#L382-L388 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? verweist weiterhin direkt auf everyone und verwendet die _map-Kurzschreibweise für Site-Einstellungen nicht.
• Discourse AI
  • • can_see_summary? in 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 schaut sich currentUser.groups auf der Client-Seite an, 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.
  • assign_allowed_on_groups sollte 0|4|5 zu disallowed_groups hinzufügen; keine dieser Gruppen macht hier Sinn, es kommen nur konkrete Gruppen infrage.

Andere Plugins

• Activity Pub
  • Clientseitige Prüfung von user.groups und everyone in showStatusToUser entfernen. activity_pub_post_status_visibility_groups auf Standardwert 4|5 ändern.
• Suggested Edits
  • user_in_suggested_edits_group? muss user.in_any_groups? in GuardianExtensions verwenden. 1 zu mandatory_groups für suggested_edits_review_groups hinzufügen und den Admin-Sonderfall in can_review_suggested_edits_in_topic_list entfernen.
  • 0|4|5 zu disallowed_groups für suggested_edits_review_groups und suggested_edits_suggest_groups hinzufügen; diese Einstellung ist nicht wirklich für die Verwendung mit diesen Pseudogruppen gedacht.
• Resenha
  • Den Workaround untargetable_group_ids in public_room_message_bus_targets entfernen, da dies in FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub behandelt wurde.
  • Standardwert für resenha_allowed_groups von 0 auf 4|5 ändern.

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; 1 zur Einstellung whispers_allowed_groups als mandatory_values hinzufügen.
  • 0|4 zu disallowed_groups für die Site-Einstellung allow_solved_in_groups hinzufügen; dies betrifft nur PN (Private Messages).
  • 0|4|5 zu disallowed_groups für about_page_extra_groups hinzufügen; dies soll nur mit konkreten Gruppen auf der Über-uns-Seite umgehen.
  • Hinweis in can_view? für PresenceChannel, dass wir den Group::AUTO_GROUPS[:everyone]-Check entfernen müssen, wenn diese anstehende Änderung zu Permanent wechselt.

Core-Plugins

• Chat
  • Hinweis für everyone_allowed an verschiedenen Stellen in der Chat-Auto-Beitritt/Auto-Austritts-Logik und users_with_unreads, den :everyone-Check zu entfernen, wenn diese anstehende Änderung zu Permanent wechselt.
  • chat_allowed_group_ids in Chat::Publisher aktualisieren, um die spezielle Pseudogruppe zu entfernen, da MessageBus laut FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub jetzt korrekt mit Pseudogruppen umgehen kann.
• Assign
  • add_model_callback(Group) in plugin.rb entfernen; es ist irrelevanter/toter Code, der sich auf Gruppennamen anstatt auf IDs bezieht.

Andere Plugins

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

Themes

Komponenten

Nächste Schritte für die Migration

TBA (Noch nicht bekannt)