O caminho para a estabilidade e, em seguida, a perenidade das permissões de grupos granulares, anônimos e autenticados

[martin (Martin Brennan)]

Este é um tópico complementar a Granular group-based permissions for anonymous and logged in users e está em andamento (WIP).

---

Ainda há alguns lugares em várias bases de código do núcleo, plugins e temas que referenciam diretamente o ID do grupo everyone ou (0), sem levar em conta esta mudança futura ou sem usar user.in_any_groups? ou os vários métodos de guardian usados para lidar com isso.

Para referência rápida, alguns IDs de grupos automáticos:

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

Este tópico serve como um local central para acompanhar as correções para este sistema à medida que nos aproximamos da versão estável. Plugins e temas personalizados para clientes do Discourse não são rastreados aqui; terei uma lista separada internamente para isso.

Problemas de alta prioridade

Problema levantado por Moin:

@martin

1. anonymous_users e logged_in_users não estão no seletor de grupos. Acho que é seguro permitir estes aqui agora, assim não importará se você adicionou everyone a disallowed_groups se a mudança futura estiver desativada.
2. Corrija Guardian::AnonymousUser#in_any_groups? para respeitar anonymous_users com a mudança futura desativada.
3. Adicione o mesmo alias de tempo de leitura de 0 (everyone) → 5 (logged_in_users) para configurações de tema, como fazemos para configurações do site.

• Núcleo
  • Sobre - apply_excluded_groups é usado apenas para ocultar moderadores e administradores selecionados dos grupos em about_page_hidden_groups. Não faz sentido que pseudogrupos como 0|4|5 sejam usados aqui; eles devem ser adicionados a disallowed_groups. Precisamos atualizar a descrição da configuração também, pois é enganosa.
  • EditCategoryTabsController - Em _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub estamos olhando apenas para grupos visíveis; isso deve ser uma verificação no servidor, como evaluate para ACLs

Plugins do núcleo

• Discourse Templates
  • • can_use_private_templates? ainda referencia everyone diretamente e não usa o atalho _map nas configurações do site.
• Discourse AI
  • • can_see_summary? nas extensões de guardian não está usando user.in_any_groups?
  • • can_attach? em AiBot::Playground não está usando user.in_any_groups?
  • • addTopicAdminMenuButton em ai-translation-topic-admin está olhando para currentUser.groups no cliente, o que não é confiável; faça uma verificação no servidor para content_localization_allowed_groups em vez disso
• Discourse Assign. Bastante problemas aqui.
  • Em vez de user_ids_in_groups em AssignmentPermissions, devemos usar user_ids_in_groups
  • assign_allowed_on_groups deve ter 0|4|5 adicionado a disallowed_groups; nenhum desses faz sentido aqui, apenas grupos concretos importam.

Outros plugins

• Activity Pub
  • Remova a verificação no cliente de showStatusToUser em user.groups e a verificação de everyone. Altere activity_pub_post_status_visibility_groups para ter 4|5 como padrão.
• Suggested Edits
  • user_in_suggested_edits_group? precisa usar user.in_any_groups? em GuardianExtensions. Adicione 1 a mandatory_groups em suggested_edits_review_groups e remova o caso especial de admin em can_review_suggested_edits_in_topic_list
  • Adicione 0|4|5 a disallowed_groups em suggested_edits_review_groups e suggested_edits_suggest_groups; esta configuração não é realmente destinada a ser usada com esses pseudogrupos
• Resenha
  • Remova o workaround de untargetable_group_ids em public_room_message_bus_targets, pois isso foi abordado em FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub
  • Altere o padrão de resenha_allowed_groups de 0 para 4|5

Temas

Componentes

Problemas de baixa prioridade

• Núcleo
  • is_in_edit_topic_groups em TopicGuardian deve usar a extensão _map para a configuração do site
  • Roleable#whisperer? deve usar user.in_any_groups? e se livrar da verificação de admin; adicione 1 à configuração whispers_allowed_groups como mandatory_values
  • Adicione 0|4 a disallowed_groups para a configuração do site allow_solved_in_groups; isso lida apenas com PMs
  • Adicione 0|4|5 a disallowed_groups para about_page_extra_groups; isso deve lidar apenas com grupos concretos na página sobre
  • Anote em can_view? para PresenceChannel que precisamos remover a verificação de Group::AUTO_GROUPS[:everyone] quando esta mudança futura passar para Permanent

Plugins do núcleo

• Chat
  • Anote para everyone_allowed em vários lugares na lógica de auto-entrada/saída do chat e users_with_unreads para remover a verificação de :everyone quando esta mudança futura passar para Permanent
  • Atualize chat_allowed_group_ids em Chat::Publisher para remover o pseudogrupo especial, pois em FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub o MessageBus agora pode lidar com os pseudogrupos corretamente
• Assign
  • Elimine add_model_callback(Group) em plugin.rb; é código irrelevante/morto que olha para nomes de grupos em vez de IDs

Outros plugins

• Code Review
  • A verificação de can_review_code? em code_review_allowed_groups não usa a extensão _map e não está usando user.in_any_groups?. Adicione 1 a mandatory_groups para a configuração e elimine a verificação especial de admin no guardian. Adicione 0|4|5 a disallowed_groups.
• Needs Love
  • A verificação de can_needs_love? em needs_love_allowed_groups não usa a extensão _map e não está usando user.in_any_groups?. Adicione 1 a mandatory_groups para a configuração e elimine a verificação especial de admin no guardian. Adicione 0|4|5 a disallowed_groups.
• Staff Alias
  • A verificação de can_post_as_staff_alias em staff_alias_allowed_groups não usa a extensão _map e não está usando user.in_any_groups?. Adicione 0|4|5 a disallowed_groups

Temas

Componentes

Próximas etapas para migração

A definir