O caminho para estável, e depois permanente, para granular_anonymous_and_logged_in_groups_permissions

[martin (Martin Brennan)]

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

---

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

Para referência rápida, alguns IDs de grupo automático:

• 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 deste 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 isso aqui agora, então não importará se você adicionou everyone a disallowed_groups se a mudança iminente estiver desativada.
2. Corrigir Guardian::AnonymousUser#in_any_groups? para respeitar anonymous_users com a mudança iminente desativada.
3. Adicionar o mesmo alias de tempo de leitura de 0 (everyone) → 5 (logged_in_users) para configurações de tema, que 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 usar pseudogrupos como 0|4|5 aqui; eles devem ser adicionados a disallowed_groups. Precisamos atualizar a descrição da configuração também, pois é enganosa.

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 guardião não usa user.in_any_groups?
  • • can_attach? em AiBot::Playground não usa user.in_any_groups?
  • • addTopicAdminMenuButton em ai-translation-topic-admin olhando para currentUser.groups no cliente, o que não é confiável; faça uma verificação no lado do servidor para content_localization_allowed_groups em vez disso
• Discourse Assign. Bastantes 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 deles faz sentido aqui, apenas grupos concretos importam.

Outros plugins

• Activity Pub
  • Remover a verificação cliente de user.groups e everyone em showStatusToUser. Alterar activity_pub_post_status_visibility_groups para padrão 4|5.
• Suggested Edits
  • user_in_suggested_edits_group? precisa usar user.in_any_groups? em GuardianExtensions. Adicionar 1 a suggested_edits_review_groups mandatory_groups e remover o caso especial de administrador em can_review_suggested_edits_in_topic_list
  • Adicionar 0|4|5 a suggested_edits_review_groups e suggested_edits_suggest_groups disallowed_groups; esta configuração não foi realmente projetada para ser usada com esses pseudogrupos
• Resenha
  • Remover a solução alternativa untargetable_group_ids em public_room_message_bus_targets já que isso foi abordado em FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub
  • Alterar 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 eliminar a verificação de administrador, adicionar 1 à configuração whispers_allowed_groups como mandatory_values
  • Adicionar 0|4 a disallowed_groups para a configuração do site allow_solved_in_groups, isso lida apenas com MPs
  • Adicionar 0|4|5 a disallowed_groups para about_page_extra_groups, isso deve lidar apenas com grupos concretos na página Sobre
  • Observação em can_view? para PresenceChannel de que precisamos remover a verificação Group::AUTO_GROUPS[:everyone] quando esta mudança iminente se tornar Permanent

Plugins do núcleo

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

Outros plugins

• Code Review
  • A verificação can_review_code? em code_review_allowed_groups não usa a extensão _map e não usa user.in_any_groups?. Adicionar 1 a mandatory_groups para a configuração e eliminar a verificação especial de administrador no guardião. Adicionar 0|4|5 a disallowed_groups.
• Needs Love
  • A verificação can_needs_love? em needs_love_allowed_groups não usa a extensão _map e não usa user.in_any_groups?. Adicionar 1 a mandatory_groups para a configuração e eliminar a verificação especial de administrador no guardião. Adicionar 0|4|5 a disallowed_groups.
• Staff Alias
  • A verificação can_post_as_staff_alias em staff_alias_allowed_groups não usa a extensão _map e não usa user.in_any_groups?. Adicionar 0|4|5 a disallowed_groups

Temas

Componentes

Próximas etapas para migração

A definir