granular_anonymous_and_logged_in_groups_permissions の安定版、そして正式版への道

開発
1

これは Granular group-based permissions for anonymous and logged in users に関連するトピックであり、現在作業中です（WIP）。

コア、プラグイン、テーマの各種コードベースには、この forthcoming な変更を考慮していない、または user.in_any_groups? やこの問題に対処するために使用される各種ガードイアン（Guardian）メソッドを使用せずに、everyone またはグループ ID 0 を直接参照している箇所がまだいくつかあります。

参考までに、いくつかの自動グループ ID を以下に示します。

  • 0 - everyone（全員）
  • 1 - admins（管理者）
  • 2 - moderators（モデレーター）
  • 3 - staff（スタッフ）
  • 4 - anonymous_users（匿名ユーザー）
  • 5 - logged_in_users（ログイン済みユーザー）

このトピックは、安定版リリースに近づきながら、このシステムの修正を追跡するための中央集約場所として機能します。Discourse ユーザー向けのカスタムプラグインやテーマはここで追跡されません。これらについては内部で別のリストを作成します。

高優先度の課題

Moin によって提起された問題:

  • コア
    • About - apply_excluded_groups は、about_page_hidden_groups のグループから選択されたモデレーターと管理者を隠すためにのみ使用されます。0|4|5 のような擬似グループをここで使用することは意味を成しません。これらは disallowed_groups に追加されるべきです。誤解を招くため、設定の説明も更新する必要があります。

コアプラグイン

  • Discourse Templates
      • can_use_private_templates? は依然として everyone を直接参照しており、サイト設定で _map ショートハンドを使用していません。
  • Discourse AI
      • ガードイアン拡張機能の can_see_summary? が user.in_any_groups? を使用していません。
      • AiBot::Playground の can_attach? が user.in_any_groups? を使用していません。
      • ai-translation-topic-admin の addTopicAdminMenuButton がクライアント側の currentUser.groups を参照していますが、これは信頼できません。代わりにサーバー側で content_localization_allowed_groups のチェックを行う必要があります。
  • Discourse Assign。ここに多くの問題があります。
    • AssignmentPermissions で user_ids_in_groups を使用するのではなく、user_ids_in_groups を使用するべきです（原文のままですが、文脈上同じメソッド名への言及と思われますが、意図は「適切なメソッドを使用する」ことです）。
    • assign_allowed_on_groups に 0|4|5 を disallowed_groups に追加する必要があります。これらはここで意味を成しません。重要なのは具体的なグループのみです。

その他のプラグイン

  • Activity Pub
    • user.groups と everyone のチェックを行うクライアント側の showStatusToUser を削除します。activity_pub_post_status_visibility_groups のデフォルト値を 4|5 に変更します。
  • Suggested Edits
    • GuardianExtensions の user_in_suggested_edits_group? が user.in_any_groups? を使用する必要があります。suggested_edits_review_groups の mandatory_groups に 1 を追加し、can_review_suggested_edits_in_topic_list 内の管理者の特別ケースを削除します。
    • suggested_edits_review_groups と suggested_edits_suggest_groups の disallowed_groups に 0|4|5 を追加します。この設定はこれらの擬似グループで使用することを意図していません。
  • Resenha

テーマ

コンポーネント

低優先度の課題

  • コア
    • TopicGuardian の is_in_edit_topic_groups は、サイト設定に対して _map 拡張機能を使用する必要があります。
    • Roleable#whisperer? は user.in_any_groups? を使用し、管理者チェックを削除する必要があります。whispers_allowed_groups 設定の mandatory_values に 1 を追加します。
    • allow_solved_in_groups サイト設定の disallowed_groups に 0|4 を追加します。これは PM（プライベートメッセージ）のみを処理します。
    • about_page_extra_groups の disallowed_groups に 0|4|5 を追加します。これは about ページで具体的なグループのみを処理するよう意図されています。
    • PresenceChannel の can_view? において、forthcoming な変更が Permanent に移行した時点で Group::AUTO_GROUPS[:everyone] のチェックを削除する必要があることを注記します。

コアプラグイン

  • Chat
    • チャットの自動参加/自動退出ロジックおよび users_with_unreads の様々な箇所の everyone_allowed について、forthcoming な変更が Permanent に移行した時点で :everyone のチェックを削除するよう注記します。
    • FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub にあるように、MessageBus が現在擬似グループを正しく処理できるため、Chat::Publisher の chat_allowed_group_ids を更新し、特別な擬似グループを削除します。
  • Assign
    • plugin.rb 内の add_model_callback(Group) を削除します。これはグループ ID ではなくグループ名を参照する無関係/死んだコードです。

その他のプラグイン

  • Code Review
    • code_review_allowed_groups に対する can_review_code? チェックは _map 拡張機能を使用しておらず、user.in_any_groups? も使用していません。設定の mandatory_groups に 1 を追加し、ガードイアン内の特別な管理者チェックを削除します。disallowed_groups に 0|4|5 を追加します。
  • Needs Love
    • needs_love_allowed_groups に対する can_needs_love? チェックは _map 拡張機能を使用しておらず、user.in_any_groups? も使用していません。設定の mandatory_groups に 1 を追加し、ガードイアン内の特別な管理者チェックを削除します。disallowed_groups に 0|4|5 を追加します。
  • Staff Alias
    • staff_alias_allowed_groups に対する can_post_as_staff_alias チェックは _map 拡張機能を使用しておらず、user.in_any_groups? も使用していません。disallowed_groups に 0|4|5 を追加します。

テーマ

コンポーネント

移行の次のステップ

「いいね！」 2
Granular group-based permissions for anonymous and logged in users