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

Entwickler
1

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

Es gibt weiterhin einige Stellen in verschiedenen Codebasen für Core, Plugins und Themes, die direkt auf everyone oder die Gruppen-ID (0) verweisen, ohne diese bevorstehende Änderung zu berücksichtigen oder ohne user.in_any_groups? bzw. verschiedene Guardian-Methoden zu verwenden, die dafür vorgesehen sind.

Zur schnellen Referenz 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 Fixes für dieses System im Blick zu behalten, während wir uns der stabilen Version nähern. Eigene Plugins und Themes für Discourse-Kunden werden hier nicht erfasst; ich habe dafür intern eine separate Liste.

Hochprioritäre Probleme

Von Moin gemeldetes Problem:

Core-Plugins

  • Discourse Templates
      • can_use_private_templates? verweist immer noch direkt auf everyone und verwendet die _map-Kurzschreibweise bei 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 prüft currentUser.groups clientseitig, was nicht zuverlässig ist. Führe stattdessen eine serverseitige Prüfung für content_localization_allowed_groups durch.
  • Discourse Assign. Hier gibt es ziemlich viele Probleme.
    • Statt user_ids_in_groups in AssignmentPermissions sollten wir user_ids_in_groups verwenden (Hinweis: Im Originaltext identisch, vermutlich ein Tippfehler im Quelltext, aber ich bleibe beim Wortlaut, es sei denn, der Kontext deutet stark auf eine andere Methode hin. Da beide Begriffe identisch sind, übersetze ich wörtlich).
    • Zu assign_allowed_on_groups sollten 0|4|5 zu disallowed_groups hinzugefügt werden, da keines davon hier sinnvoll ist; nur konkrete Gruppen sind relevant.

Andere Plugins

  • Activity Pub
    • Entferne die clientseitige Prüfung von user.groups und dem everyone-Check in showStatusToUser. Ändere activity_pub_post_status_visibility_groups so, dass standardmäßig 4|5 gesetzt 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 soll eigentlich nicht mit diesen Pseudogruppen verwendet werden.
  • Live

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 die Admin-Prüfung entfernen. Füge 1 zur Einstellung 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.
    • Notiz in can_view? für PresenceChannel: Wir müssen die Prüfung auf Group::AUTO_GROUPS[:everyone] entfernen, wenn diese bevorstehende Änderung in den Status Permanent wechselt.

Core-Plugins

  • Chat
    • Notiz zu everyone_allowed an verschiedenen Stellen in der Logik für automatischen Beitritt/Automatisches Verlassen im Chat sowie in users_with_unreads: Die :everyone-Prüfung muss entfernt werden, wenn diese bevorstehende Änderung in den Status Permanent wechselt.
    • Aktualisiere chat_allowed_group_ids in Chat::Publisher, um die spezielle Pseudogruppe zu entfernen, da MessageBus gemäß FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub nun korrekt mit Pseudogruppen umgehen kann.
  • Assign
    • Entferne add_model_callback(Group) in plugin.rb. Das ist irrelevanter/Toter Code, der nach Gruppennamen statt IDs sucht.

Andere Plugins

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

Themes

Komponenten

Nächste Schritte für die Migration

  • Migriere allowed_group_ids des Modells AiAgent
3

Hier erledigt: FIX: everyone pseudogroup roadmap part 1 - Pull Request #43798 - discourse/discourse - GitHub