The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions

[martin (Martin Brennan)]

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:

@martin

1. 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.
2. Fix Guardian::AnonymousUser#in_any_groups? to respect anonymous_users with the upcoming change turned off.
3. 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.

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
• Resenha
  • 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

TBA