Путь к стабильности, а затем к постоянству для гранулярных разрешений анонимных и авторизованных групп

Эта тема является дополнением к 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:

  • Core (Ядро)
    • Раздел «О сайте» — 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 мы смотрим только на видимые группы. Это должно быть серверное проверка, как evaluate для ACL.

Плагины ядра

  • Discourse Templates
      • can_use_private_templates? по-прежнему напрямую ссылается на everyone и не использует сокращение _map в настройках сайта.
  • Discourse AI
      • can_see_summary? в расширениях guardian не использует user.in_any_groups?
      • can_attach? в AiBot::Playground не использует user.in_any_groups?
      • addTopicAdminMenuButton в ai-translation-topic-admin смотрит на currentUser.groups на клиенте, что ненадежно. Вместо этого следует выполнять серверную проверку для content_localization_allowed_groups
  • Discourse Assign. Здесь довольно много проблем.
    • Вместо user_ids_in_groups в AssignmentPermissions мы должны использовать 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
    • user_in_suggested_edits_group? должен использовать user.in_any_groups? в GuardianExtensions. Добавить 1 в mandatory_groups для suggested_edits_review_groups и удалить специальное исключение для администраторов в can_review_suggested_edits_in_topic_list
    • Добавить 0|4|5 в disallowed_groups для suggested_edits_review_groups и suggested_edits_suggest_groups, эта настройка не предназначена для использования с этими псевдогруппами.
  • Resenha

Темы

Компоненты

Проблемы низкой приоритетности

  • Core (Ядро)
    • is_in_edit_topic_groups в TopicGuardian должен использовать расширение _map для настройки сайта.
    • Roleable#whisperer? должен использовать user.in_any_groups? и избавиться от проверки администратора, добавить 1 в настройку whispers_allowed_groups как mandatory_values.
    • Добавить 0|4 в disallowed_groups для настройки сайта allow_solved_in_groups, это касается только личных сообщений.
    • Добавить 0|4|5 в disallowed_groups для about_page_extra_groups, это должно касаться только конкретных групп на странице «О сайте».
    • Примечание в can_view? для PresenceChannel: нам нужно удалить проверку Group::AUTO_GROUPS[:everyone], когда это предстоящее изменение перейдет в статус Permanent.

Плагины ядра

  • Chat
    • Примечание для everyone_allowed в различных местах логики авто-вступления/авто-выхода в чате и users_with_unreads: удалить проверку :everyone, когда это предстоящее изменение перейдет в статус Permanent.
    • Обновить chat_allowed_group_ids в Chat::Publisher, чтобы удалить специальную псевдогруппу, так как в FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub MessageBus теперь может правильно работать с псевдогруппами.
  • Assign
    • Избавиться от add_model_callback(Group) в plugin.rb, это нерелевантный/мертвый код, который смотрит на имена групп, а не на ID.

Другие плагины

  • Code Review
    • Проверка can_review_code? для code_review_allowed_groups не использует расширение _map и не использует user.in_any_groups?. Добавить 1 в mandatory_groups для этой настройки и избавиться от специальной проверки администратора в guardian. Добавить 0|4|5 в disallowed_groups.
  • Needs Love
    • Проверка can_needs_love? для needs_love_allowed_groups не использует расширение _map и не использует user.in_any_groups?. Добавить 1 в mandatory_groups для этой настройки и избавиться от специальной проверки администратора в guardian. Добавить 0|4|5 в disallowed_groups.
  • Staff Alias
    • Проверка can_post_as_staff_alias для staff_alias_allowed_groups не использует расширение _map и не использует user.in_any_groups?. Добавить 0|4|5 в disallowed_groups.

Темы

Компоненты

Следующие шаги для миграции

TBA (Будет определено)

2 лайка