This is a companion topic to Granular group-based permissions for anonymous and logged in users , and is a WIP. There are still a few places in various codebases for core, plugins, and themes that directly reference everyone or (0) group ID directly, without taking into account this upcoming change, or without using user.in_any_groups? or various guardian methods used to deal with this. For quick reference, some auto group IDs: 0 - everyone 1 - admins 2 - moderators 3 - staff 4 - anonymous_users 5 - logged_in_users This topic serves as a central place to keep track of fixes for this system as we approach stable. Custom plugins and themes for Discourse customers are not tracked here, I will have a separate list internally for this. High priority issues Issue raised by Moin: [图片]Granular group-based permissions for anonymous and logged in users anonymous_users and logged_in_users aren’t in the group picker at all. I think it’s safe to allow these here now, then it won’t matter if you’ve added everyone to disallowed_groups if the upcoming change is turned off. Fix Guardian::AnonymousUser#in_any_groups? to respect anonymous_users with the upcoming change turned off. Add the same read time aliasing of 0 (everyone) → 5 (logged_in_users) for theme settings, which we do for site settings. Core About - apply_excluded_groups only is used to hide selected moderators & admins from the groups in about_page_hidden_groups. It doesn’t make sense for pseudogroups like 0|4|5 to be used here, they should be added to disallowed_groups. We need to update the setting description too as it’s misleading. EditCategoryTabsController - In _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub we are only looking at visible groups, this should be a server-side check like evaluate for ACLs Core plugins Discourse Templates can_use_private_templates? still references everyone directly and doesn’t use the _map shorthand on site settings. Discourse AI can_see_summary? in guardian extensions not using user.in_any_groups? can_attach? in AiBot::Playground does not use user.in_any_groups? addTopicAdminMenuButton in ai-translation-topic-admin looking at currentUser.groups on client, which is not reliable, do a server-side check for content_localization_allowed_groups instead Discourse Assign. Quite a lot of issues here. Rather than user_ids_in_groups in AssignmentPermissions, we should use user_ids_in_groups assign_allowed_on_groups should have 0|4|5 added to disallowed_groups, none of these make sense here, it’s only concrete groups that matter. Other plugins Activity Pub Remove showStatusToUser clientside checking of user.groups and everyone check. Change activity_pub_post_status_visibility_groups to default to 4|5. Suggested Edits user_in_suggested_edits_group? needs to use user.in_any_groups? in GuardianExtensions. Add 1 to suggested_edits_review_groups mandatory_groups and remove admin special case in can_review_suggested_edits_in_topic_list Add 0|4|5 to suggested_edits_review_groups and suggested_edits_suggest_groups disallowed_groups, this setting isn’t really intended to be used with these pseudogroups Live Remove the untargetable_group_ids workaround in public_room_message_bus_targets since this was addressed in FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub Change resenha_allowed_groups default from 0 to 4|5 Themes Components Low priority issues Core is_in_edit_topic_groups in TopicGuardian should use the _map extension for the site setting Roleable#whisperer? should use user.in_any_groups? and get rid of admin check, add 1 to whispers_allowed_groups setting as mandatory_values Add 0|4 to disallowed_groups for allow_solved_in_groups site setting, this deals with PMs only Add 0|4|5 to disallowed_groups for about_page_extra_groups, this is supposed to be dealing with concrete groups only on the about page Note in can_view? for PresenceChannel that we need to remove the Group::AUTO_GROUPS[:everyone] check when this upcoming change moves to Permanent Core plugins Chat Note for everyone_allowed in various places in chat auto-join/auto-leave logic and users_with_unreads to remove :everyone check when this upcoming change moves to Permanent Update chat_allowed_group_ids in Chat::Publisher to remove special pseudogroup, as at FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub MessageBus can now deal with the pseudogroups correctly Assign Get rid of add_model_callback(Group) in plugin.rb, its irrelevant/dead code looking at group names instead of IDs Other plugins Code Review can_review_code? check on code_review_allowed_groups doesn’t use _map extension and isn’t using user.in_any_groups?. Add 1 to mandatory_groups for the setting and get rid of special admin check in guardian. Add 0|4|5 to disallowed_groups. Needs Love can_needs_love? check on needs_love_allowed_groups doesn’t use _map extension and isn’t using user.in_any_groups?. Add 1 to mandatory_groups for the setting and get rid of special admin check in guardian. Add 0|4|5 to disallowed_groups. Staff Alias can_post_as_staff_alias check on staff_alias_allowed_groups doesn’t use _map extension and isn’t using user.in_any_groups?. Add 0|4|5 to disallowed_groups Themes Components Next steps for migration Migrate AiAgent model allowed_group_ids

[图片] martin: Core About - apply_excluded_groups only is used to hide selected moderators & admins from the groups in about_page_hidden_groups. It doesn’t make sense for pseudogroups like 0|4|5 to be used here, they should be added to disallowed_groups. We need to update the setting description too as it’s misleading. EditCategoryTabsController - In _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub we are only looking at visible groups, this should be a server-side check like evaluate for ACLs Done here FIX: everyone pseudogroup roadmap part 1 - Pull Request #43798 - discourse/discourse - GitHub

通往稳定版，再到永久版的 granular_anonymous_and_logged_in_groups_permissions 之路

开发

martin (Martin Brennan) 2026 年10 月 21 日 01:44 3

已在此处完成 FIX: everyone pseudogroup roadmap part 1 - Pull Request #43798 - discourse/discourse - GitHub

话题		回复	浏览量
Granular group-based permissions for anonymous and logged in users Announcements groups	43	2351	2026 年9 月 10 日
AI Agent group settings don't seem to be handled by the upcoming change removing the everyone group Bug ai	3	190	2026 年9 月 9 日
Category permissions and the new permission groups Bug	12	548	2026 年8 月 16 日
Deprecating the user of `user.groups` in the `User` model in JavaScript Development dev-news	5	244	2026 年8 月 31 日
Allow anonymous users to inherit their parent user groups Feature groups , anonymous-mode	9	801	2024 年3 月 6 日

通往稳定版，再到永久版的 granular_anonymous_and_logged_in_groups_permissions 之路

相关话题