El camino hacia la estabilidad y, a continuación, la permanencia de 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).

---

Aún hay algunos lugares en varias bases de código del núcleo, plugins y temas que hacen referencia directa al grupo everyone o al ID de grupo (0) directamente, sin tener en cuenta este cambio inminente, o sin utilizar user.in_any_groups? o los diversos métodos 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 lugar central para hacer 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 interna separada para esto.

Problemas de alta prioridad

Problema planteado por Moin:

@martin

1. anonymous_users y logged_in_users no están en absoluto en el selector de grupos. Creo que es seguro permitir estos aquí ahora, así no importará si has agregado everyone a disallowed_groups si el cambio inminente está desactivado.
2. Corregir Guardian::AnonymousUser#in_any_groups? para respetar anonymous_users con el cambio inminente desactivado.
3. Agregar 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 agregarse a disallowed_groups. También necesitamos actualizar la descripción de la configuración ya que es engañosa.
  • EditCategoryTabsController - En _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub solo estamos mirando los grupos visibles, esto debería ser una verificación del lado del servidor como evaluate para ACLs

Plugins del núcleo

• Discourse Templates
  • • can_use_private_templates? aún hace referencia directa a everyone y no usa el atajo _map en la configuración del sitio.
• Discourse AI
  • • can_see_summary? en extensiones guardian no está usando user.in_any_groups?
  • • can_attach? en AiBot::Playground no está usando user.in_any_groups?
  • • addTopicAdminMenuButton en ai-translation-topic-admin está mirando currentUser.groups en el cliente, lo cual no es confiable; realiza una verificació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 usar user_ids_in_groups
  • assign_allowed_on_groups debería tener 0|4|5 agregado a disallowed_groups, ninguno de estos tiene sentido aquí, solo importan los grupos concretos.

Otros plugins

• Activity Pub
  • Eliminar la verificación del lado del cliente de showStatusToUser sobre user.groups y la verificación de everyone. Cambiar activity_pub_post_status_visibility_groups para que tenga 4|5 como valor predeterminado.
• Suggested Edits
  • user_in_suggested_edits_group? necesita usar user.in_any_groups? en GuardianExtensions. Agregar 1 a mandatory_groups de suggested_edits_review_groups y eliminar el caso especial de administrador en can_review_suggested_edits_in_topic_list
  • Agregar 0|4|5 a disallowed_groups de suggested_edits_review_groups y suggested_edits_suggest_groups, esta configuración no está realmente destinada a usarse con estos pseudogrupos
• Live
  • Eliminar el workaround de 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 usar la extensión _map para la configuración del sitio
  • Roleable#whisperer? debería usar user.in_any_groups? y deshacerse de la verificación de administrador, agregar 1 a la configuración whispers_allowed_groups como mandatory_values
  • Agregar 0|4 a disallowed_groups para la configuración del sitio allow_solved_in_groups, esto trata solo con mensajes privados
  • Agregar 0|4|5 a disallowed_groups para about_page_extra_groups, esto está destinado a tratar solo con grupos concretos en la página de información
  • Nota en can_view? para PresenceChannel de que necesitamos eliminar la verificació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 auto-entrada/salida de chat y users_with_unreads para eliminar la verificación de :everyone cuando este cambio inminente pase a Permanent
  • Actualizar chat_allowed_group_ids en Chat::Publisher para eliminar el pseudogrupo especial, ya que 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 verificación de can_review_code? sobre code_review_allowed_groups no usa la extensión _map y no está usando user.in_any_groups?. Agregar 1 a mandatory_groups para la configuración y deshacerse de la verificación especial de administrador en guardian. Agregar 0|4|5 a disallowed_groups.
• Needs Love
  • La verificación de can_needs_love? sobre needs_love_allowed_groups no usa la extensión _map y no está usando user.in_any_groups?. Agregar 1 a mandatory_groups para la configuración y deshacerse de la verificación especial de administrador en guardian. Agregar 0|4|5 a disallowed_groups.
• Staff Alias
  • La verificación de can_post_as_staff_alias sobre staff_alias_allowed_groups no usa la extensión _map y no está usando user.in_any_groups?. Agregar 0|4|5 a disallowed_groups

Temas

Componentes

Próximos pasos para la migración

• Migrar allowed_group_ids del modelo AiAgent

[martin (Martin Brennan)]

@martin

• 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 aquí pseudogrupos como 0|4|5; deberían añadirse a disallowed_groups. También necesitamos actualizar la descripción del ajuste, ya que es engañosa.
  • EditCategoryTabsController - En _wouldLoseAccess discourse/frontend/discourse/admin/controllers/edit-category/tabs.js at 86552acfbaf816db3b9db5f761f5e9f2bd221c21 · discourse/discourse · GitHub solo estamos mirando los grupos visibles; esto debería ser una comprobación del lado del servidor, similar a evaluate para las ACLs

Hecho aquí FIX: everyone pseudogroup roadmap part 1 - Pull Request #43798 - discourse/discourse - GitHub