El camino hacia la estabilidad, y luego la permanencia, para granular_anonymous_and_logged_in_groups_permissions

[martin (Martin Brennan)]

Este es un tema complementario a Granular group-based permissions for anonymous and logged in users y está en desarrollo (WIP).

---

Todavía hay algunos lugares en varias bases de código del núcleo, los plugins y los temas que hacen referencia directa al ID de grupo everyone o (0), sin tener en cuenta este cambio inminente o sin utilizar user.in_any_groups? ni los diversos métodos de guardian utilizados para manejar esto.

Para referencia rápida, algunos IDs de grupos automáticos:

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

Este tema sirve como un lugar central para hacer un seguimiento de las correcciones de este sistema a medida que nos acercamos a la versión estable. Los plugins y temas personalizados para clientes de Discourse no se rastrean aquí; tendré una lista separada interna para esto.

Problemas de alta prioridad

Problema planteado por Moin:

@martin

1. anonymous_users y logged_in_users no están en el selector de grupos en absoluto. Creo que es seguro permitirlos aquí ahora, así que no importará si has añadido everyone a disallowed_groups si el cambio inminente se desactiva.
2. Corregir Guardian::AnonymousUser#in_any_groups? para que respete anonymous_users con el cambio inminente desactivado.
3. Añadir el mismo alias de tiempo de lectura de 0 (everyone) → 5 (logged_in_users) para la configuración de temas, que hacemos para la configuración del sitio.

• Núcleo
  • Acerca de - apply_excluded_groups solo se utiliza para ocultar moderadores y administradores seleccionados de los grupos en about_page_hidden_groups. No tiene sentido que se utilicen pseudogrupos como 0|4|5 aquí, deberían añadirse a disallowed_groups. También necesitamos actualizar la descripción de la configuración, ya que es engañosa.

Plugins del núcleo

• Discourse Templates
  • • can_use_private_templates? todavía hace referencia directa a everyone y no utiliza el atajo _map en la configuración del sitio.
• Discourse AI
  • • can_see_summary? en extensiones de guardian no utiliza user.in_any_groups?
  • • can_attach? en AiBot::Playground no utiliza user.in_any_groups?
  • • addTopicAdminMenuButton en ai-translation-topic-admin mira currentUser.groups en el cliente, lo cual no es fiable, haz una comprobación del lado del servidor para content_localization_allowed_groups en su lugar
• Discourse Assign. Bastantes problemas aquí.
  • En lugar de user_ids_in_groups en AssignmentPermissions, deberíamos utilizar user_ids_in_groups
  • assign_allowed_on_groups debería tener 0|4|5 añadido a disallowed_groups, ninguno de estos tiene sentido aquí, solo importan los grupos concretos.

Otros plugins

• Activity Pub
  • Eliminar la comprobación del lado del cliente de showStatusToUser de user.groups y la comprobación de everyone. Cambiar activity_pub_post_status_visibility_groups para que por defecto sea 4|5.
• Suggested Edits
  • user_in_suggested_edits_group? necesita utilizar user.in_any_groups? en GuardianExtensions. Añadir 1 a suggested_edits_review_groups mandatory_groups y eliminar el caso especial de administrador en can_review_suggested_edits_in_topic_list
  • Añadir 0|4|5 a suggested_edits_review_groups y suggested_edits_suggest_groups disallowed_groups, esta configuración no está realmente destinada a utilizarse con estos pseudogrupos
• Resenha
  • Eliminar la solución alternativa untargetable_group_ids en public_room_message_bus_targets ya que esto se abordó en FIX: Handle new pseudogroups in message bus group IDs (#42610) · discourse/discourse@699ad46 · GitHub
  • Cambiar el valor predeterminado de resenha_allowed_groups de 0 a 4|5

Temas

Componentes

Problemas de baja prioridad

• Núcleo
  • is_in_edit_topic_groups en TopicGuardian debería utilizar la extensión _map para la configuración del sitio
  • Roleable#whisperer? debería utilizar user.in_any_groups? y deshacerse de la comprobación de administrador, añadir 1 a la configuración whispers_allowed_groups como mandatory_values
  • Añadir 0|4 a disallowed_groups para la configuración del sitio allow_solved_in_groups, esto trata solo con mensajes privados
  • Añadir 0|4|5 a disallowed_groups para about_page_extra_groups, esto está destinado a tratar solo con grupos concretos en la página Acerca de
  • Nota en can_view? para PresenceChannel que necesitamos eliminar la comprobación de Group::AUTO_GROUPS[:everyone] cuando este cambio inminente pase a Permanent

Plugins del núcleo

• Chat
  • Nota para everyone_allowed en varios lugares en la lógica de unirse/salir automáticamente del chat y users_with_unreads para eliminar la comprobación de :everyone cuando este cambio inminente pase a Permanent
  • Actualizar chat_allowed_group_ids en Chat::Publisher para eliminar el pseudogrupo especial, como en FIX: Handle new pseudogroups in message bus group IDs - Pull Request #42610 - discourse/discourse - GitHub MessageBus ahora puede manejar los pseudogrupos correctamente
• Assign
  • Deshacerse de add_model_callback(Group) en plugin.rb, es código irrelevante/muerto que mira nombres de grupos en lugar de IDs

Otros plugins

• Code Review
  • La comprobación can_review_code? en code_review_allowed_groups no utiliza la extensión _map y no utiliza user.in_any_groups?. Añadir 1 a mandatory_groups para la configuración y deshacerse de la comprobación especial de administrador en guardian. Añadir 0|4|5 a disallowed_groups.
• Needs Love
  • La comprobación can_needs_love? en needs_love_allowed_groups no utiliza la extensión _map y no utiliza user.in_any_groups?. Añadir 1 a mandatory_groups para la configuración y deshacerse de la comprobación especial de administrador en guardian. Añadir 0|4|5 a disallowed_groups.
• Staff Alias
  • La comprobación can_post_as_staff_alias en staff_alias_allowed_groups no utiliza la extensión _map y no utiliza user.in_any_groups?. Añadir 0|4|5 a disallowed_groups

Temas

Componentes

Próximos pasos para la migración

Por determinar