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

Entwickler
1

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

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 user.in_any_groups? oder die verschiedenen Guardian-Methoden zu verwenden, die zur Handhabung dieses Themas dienen.

Zur schnellen Orientierung einige Auto-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 Hinblick auf die stabile Version im Blick zu behalten. Custom-Plugins und Themes für Discourse-Kunden werden hier nicht erfasst; ich habe dafür intern eine separate Liste.

Hochprioritäre Probleme

Problem, das von Moin angesprochen wurde:

Core-Plugins

  • Discourse Templates
      • can_use_private_templates? bezieht sich weiterhin direkt auf everyone und verwendet die _map-Kurzschreibweise 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 eine serverseitige Prüfung 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 in disallowed_groups haben, da hier nur konkrete Gruppen relevant sind.

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 in 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, da diese Einstellung nicht wirklich für diese Pseudogruppen gedacht ist.
  • Resenha

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.
    • Füge 0|4|5 zu disallowed_groups für about_page_extra_groups hinzu; dies soll nur mit konkreten Gruppen auf der About-Seite umgehen.
    • Füge einen Hinweis in can_view? für PresenceChannel ein, dass wir die Prüfung Group::AUTO_GROUPS[:everyone] entfernen müssen, wenn diese anstehende Änderung in den Status Permanent übergeht.

Core-Plugins

  • Chat
    • Füge einen Hinweis für everyone_allowed an verschiedenen Stellen in der Auto-Beitritts-/Auto-Austrittslogik von Chat und users_with_unreads ein, um die :everyone-Prüfung zu entfernen, wenn diese anstehende Änderung in den Status Permanent übergeht.
    • 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 dies irrelevant ist / toter Code, der sich auf Gruppennamen statt auf IDs bezieht.

Andere Plugins

  • Code Review
    • Die Prüfung can_review_code? für code_review_allowed_groups verwendet die _map-Erweiterung nicht und verwendet 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? für needs_love_allowed_groups verwendet die _map-Erweiterung nicht und verwendet 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 für staff_alias_allowed_groups verwendet die _map-Erweiterung nicht und verwendet user.in_any_groups? nicht. Füge 0|4|5 zu disallowed_groups hinzu.

Themes

Komponenten

Nächste Schritte für die Migration

TBA

2 „Gefällt mir“
Granular group-based permissions for anonymous and logged in users
Deprecating the user of `user.groups` in the `User` model in JavaScript