通往 granular_anonymous_and_logged_in_groups_permissions 稳定版，进而永久版的道路

[martin (Martin Brennan)]

这是 Granular group-based permissions for anonymous and logged in users 的配套主题，目前仍在完善中（WIP）。

---

在核心、插件和主题的各个代码库中，仍有一些地方直接引用了 everyone 或组 ID（0），而没有考虑到即将进行的这项更改，也没有使用 user.in_any_groups? 或用于处理此问题的各种 guardian 方法。

供快速参考，以下是一些自动组 ID：

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

该主题旨在作为一个中心位置，用于在系统趋于稳定时跟踪此系统的修复情况。Discourse 客户的自定义插件和主题不在此处跟踪，我将为此维护一个内部列表。

高优先级问题

Moin 提出的问题：

@martin

1. anonymous_users 和 logged_in_users 完全不在组选择器中。我认为现在允许在这里使用这些组是安全的，这样即使即将进行的更改被禁用，如果已将 everyone 添加到 disallowed_groups 中，也不会产生影响。
2. 修复 Guardian::AnonymousUser#in_any_groups?，以便在即将进行的更改被禁用时也能尊重 anonymous_users。
3. 为主题设置添加与站点设置相同的读取时间别名映射，即 0 (everyone) → 5 (logged_in_users)。

• 核心
  • About - apply_excluded_groups 仅用于从 about_page_hidden_groups 中的组中隐藏选定的版主和管理员。像 0|4|5 这样的伪组在这里没有意义，它们应该被添加到 disallowed_groups 中。我们还需要更新设置描述，因为目前的描述具有误导性。
  • EditCategoryTabsController - 在 _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub 中，我们只查看了可见组，这应该像 ACL 的 evaluate 一样进行服务器端检查

核心插件

• Discourse Templates
  • • can_use_private_templates? 仍然直接引用 everyone，并且没有使用站点设置的 _map 简写。
• Discourse AI
  • • guardian 扩展中的 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（注：原文此处重复，可能意指应使用特定的组用户 ID 方法）
  • assign_allowed_on_groups 应将 0|4|5 添加到 disallowed_groups，这些组在这里没有意义，只有具体组才重要。

其他插件

• Activity Pub
  • 移除 showStatusToUser 中对 user.groups 和 everyone 的客户端检查。将 activity_pub_post_status_visibility_groups 的默认值更改为 4|5。
• Suggested Edits
  • user_in_suggested_edits_group? 需要在 GuardianExtensions 中使用 user.in_any_groups?。将 1 添加到 suggested_edits_review_groups 的 mandatory_groups 中，并移除 can_review_suggested_edits_in_topic_list 中的管理员特殊情况。
  • 将 0|4|5 添加到 suggested_edits_review_groups 和 suggested_edits_suggest_groups 的 disallowed_groups 中，该设置并不旨在与这些伪组一起使用
• Resenha
  • 移除 public_room_message_bus_targets 中的 untargetable_group_ids 变通方法，因为此问题已在 FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub 中解决
  • 将 resenha_allowed_groups 的默认值从 0 更改为 4|5

主题

组件

低优先级问题

• 核心
  • TopicGuardian 中的 is_in_edit_topic_groups 应使用站点设置的 _map 扩展
  • Roleable#whisperer? 应使用 user.in_any_groups? 并移除管理员检查，将 1 添加到 whispers_allowed_groups 设置中作为 mandatory_values
  • 将 0|4 添加到 allow_solved_in_groups 站点设置的 disallowed_groups 中，此设置仅处理私信
  • 将 0|4|5 添加到 about_page_extra_groups 的 disallowed_groups 中，此设置旨在仅处理关于页面中的具体组
  • 在 PresenceChannel 的 can_view? 中添加注释，指出当即将进行的更改移至 Permanent 时，我们需要移除 Group::AUTO_GROUPS[:everyone] 检查

核心插件

• Chat
  • 在聊天自动加入/自动离开逻辑和 users_with_unreads 中的 everyone_allowed 各处添加注释，指出当即将进行的更改移至 Permanent 时，需要移除 :everyone 检查
  • 更新 Chat::Publisher 中的 chat_allowed_group_ids 以移除特殊的伪组，因为在 FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub 中，MessageBus 现在可以正确处理伪组
• Assign
  • 移除 plugin.rb 中的 add_model_callback(Group)，这是无关/死代码，它查看的是组名而不是 ID

其他插件

• Code Review
  • 对 code_review_allowed_groups 的 can_review_code? 检查没有使用 _map 扩展，也没有使用 user.in_any_groups?。将 1 添加到该设置的 mandatory_groups 中，并移除 guardian 中的特殊管理员检查。将 0|4|5 添加到 disallowed_groups。
• Needs Love
  • 对 needs_love_allowed_groups 的 can_needs_love? 检查没有使用 _map 扩展，也没有使用 user.in_any_groups?。将 1 添加到该设置的 mandatory_groups 中，并移除 guardian 中的特殊管理员检查。将 0|4|5 添加到 disallowed_groups。
• Staff Alias
  • 对 staff_alias_allowed_groups 的 can_post_as_staff_alias 检查没有使用 _map 扩展，也没有使用 user.in_any_groups?。将 0|4|5 添加到 disallowed_groups

主题

组件

迁移的后续步骤

• 迁移 AiAgent 模型的 allowed_group_ids