Permisos granulares basados en grupos para usuarios anónimos y registrados

martin · 13 Mayo, 2026 01:18

Históricamente ha existido un pseudogrupo confuso llamado @everyone dentro de nuestra base de código, el cual se puede utilizar para:

Configuraciones del sitio de tipo group_list
Permisos de categorías
Grupos de etiquetas

En algunos casos, las personas interpretan @everyone como “todos los usuarios anónimos y todos los usuarios con sesión iniciada”, mientras que otros lo interpretan como solo “todos los usuarios con sesión iniciada”. La realidad para las configuraciones del sitio es que, en la mayoría de los casos, solo significa “todos los usuarios con sesión iniciada”.

Aún más confuso es el hecho de que este grupo @everyone pueda utilizarse en configuraciones del sitio donde no tiene sentido que “todos los anónimos y usuarios con sesión iniciada” tengan acceso a la función, como pm_tags_allowed_for_groups.

Esto también genera confusión desde la perspectiva de la gestión de flags de funcionalidades y la experiencia del desarrollador, ya que para algunos cambios futuros u otras configuraciones podríamos querer habilitarlas realmente para “todos los anónimos y usuarios con sesión iniciada”.

Solución

Estamos introduciendo dos pseudogrupos automáticos separados:

anonymous_users (ID 4) — Representa a los usuarios anónimos que visitan tu sitio sin cuenta
logged_in_users (ID 5) — Representa a todos los usuarios con sesión iniciada en tu sitio, con un efecto similar al del grupo automático trust_level_0, pero más específico

Estos ya han sido introducidos, pero solo entrarán en vigor cuando se habilite el cambio futuro granular_anonymous_and_logged_in_groups_permissions en tu sitio.

Cuando se habilite el cambio futuro, cualquier configuración que tenga everyone como grupo seleccionado se traducirá automáticamente al ID logged_in_users, por lo que ningún dato en la tabla de configuraciones del sitio cambiará al activar el cambio futuro. Cuando el cambio futuro se vuelva permanente, realizaremos una migración de datos para todas las configuraciones de grupos para aplicar este cambio.

Además, hemos marcado anonymous_users como un disallowed_group para varias configuraciones del sitio donde no tiene sentido, por ejemplo personal_message_enabled_groups.

Los conflictos con nombres de grupos existentes se manejan automáticamente, renombrando los grupos existentes y actualizando las menciones de grupos en las publicaciones.

¿Qué pasa con los permisos de etiquetas y categorías?

Estos permisos permanecerán sin cambios, ya que su concepto de “todos” es diferente en varios aspectos y no depende del grupo automático subyacente.

Jagster · 13 Mayo, 2026 06:42

Espera… ¿qué? ¿Eso significa que todas las categorías que ahora son públicas (para todos) se cambiarán a cerradas, requiriendo inicio de sesión, cuando eso esté habilitado?

martin · 13 Mayo, 2026 06:45

No, porque:

Esto solo afecta a los ajustes del sitio de tipo lista de grupos que actualmente permiten seleccionar “todos” de la siguiente manera:

Moin · 7 Junio, 2026 20:59

¿Puede alguien ayudarme a entender cómo debo ajustar los componentes de mi tema?

Intenté usar el componente copy-post como ejemplo, ya que recuerdo que también utiliza una configuración de grupo que otorga acceso a la función. Y que hubo un problema porque el pseudogrupo «todos» requería una verificación separada, al igual que en mi componente, ya que comparar los IDs de los grupos a los que pertenece el usuario no ayuda; esos IDs deben verificarse por separado. Por eso esperaba un cambio reciente allí, porque, según mi entendimiento, los nuevos grupos también son pseudogrupos y el ID debería verificarse por separado. ¿Estoy pasando por alto algo que explique por qué esto no es necesario aquí?

Mi componente favorite filters tiene dos configuraciones de grupo: una que permite a los grupos guardar sus propios filtros y otra que ofrece filtros estándar.
Por defecto, solo los miembros del grupo trust_level_0 pueden usar filtros personalizados, ya que solo los usuarios registrados pueden tener datos almacenados en un campo de usuario personalizado. Por lo tanto, en este caso tendría sentido que no permitiera anonymous_users como selección. ¿Cómo lo hago en un componente de tema? ¿Ya existe algún ejemplo para esto?

La configuración predeterminada para los filtros predeterminados es «todos», porque considero útil que incluso los usuarios no registrados puedan ver y usar los filtros predeterminados. El problema es que everyone cambia a «logged_in_users» incluso aunque lo haya seleccionado específicamente. ¿Necesito crear una migración personalizada para que los administradores que actualmente usan everyone sigan teniendo filtros para usuarios no registrados en el futuro? ¿Cuándo debe llevarse a cabo esta migración? ¿O debe cambiar cada administrador esto individualmente después de que se haya ejecutado la migración?

¿Es realmente innecesario todo esto de lo que me estoy preocupando? Si se necesitan ajustes, menos de cuatro semanas parece un plazo bastante corto, considerando la cantidad de componentes mantenidos por la comunidad que podrían verse afectados.
Además de «copy-post», también revisé el componente unanswered filter, pero tampoco encontré ningún cambio allí. Siento que estoy pasando por alto algo importante. Después de todo, el cambio se ha habilitado por defecto desde hace casi una semana. Por eso asumo que los componentes oficiales ya habrían sido actualizados si fueran necesarios ajustes.

HAWK · 7 Junio, 2026 22:28

Se fusionaron 3 publicaciones en un tema existente: Modernización del tema Foundation

martin · 8 Junio, 2026 05:23

Al observar estos componentes, currentUser?.groups no es confiable de todos modos, ya que solo incluye grupos visibles para el usuario, y los grupos en los que está y que afectan los permisos podrían no estar serializados aquí:

github.com/discourse/discourse

app/serializers/current_user_serializer.rb

ba3e2d766


      
          def groups
            owned_group_ids = GroupUser.where(user_id: id, owner: true).pluck(:group_id).to_set
          
            object
              .visible_groups
              .pluck(:id, :name, :has_messages)
              .map do |id, name, has_messages|
                group = { id: id, name: name, has_messages: has_messages }
                group[:owner] = true if owned_group_ids.include?(id)
                group
              end
          end

En el núcleo y los plugins, sorteamos esto haciendo cosas como las siguientes en el serializador de usuario actual:

github.com/discourse/discourse

app/serializers/current_user_serializer.rb

ba3e2d766


      
          def can_delete_all_posts_and_topics
            object.in_any_groups?(SiteSetting.delete_all_posts_and_topics_allowed_groups_map)
          end

Pero, obviamente, esto no está disponible para los componentes de temas o los temas y sus configuraciones.

Hmm, no estoy seguro, tendré que pensarlo. Si realmente querías decir everyone, entonces tendría que cambiar tanto a logged_in_users como a anonymous_users. Este fue el principal problema con everyone, como se mencionó en la publicación original: algunas personas lo interpretaron como solo usuarios con sesión iniciada, otros como usuarios con sesión iniciada más anónimos, y dependía mucho de la situación.

Elegí la interpretación de «solo usuarios con sesión iniciada» porque era más segura desde el punto de vista de la seguridad.

No, simplemente no pensé en los componentes de temas o los temas y sus configuraciones, ni en cómo se verían afectados por este cambio; estaba enfocado principalmente en la configuración del sitio. Cosas como esta serán especialmente difíciles de encontrar, ya que ni siquiera están usando la constante AUTO_GROUPS:

De todos modos, pensaré en algunas soluciones para estos problemas y no moveré este cambio a Stable hasta que los resuelva.

martin · 26 Junio, 2026 01:46

Actualización rápida: se me ha ocurrido una idea para manejar esto y estamos teniendo algunas discusiones internas al respecto. Espero que no tome demasiado tiempo

Noble_Fish · 5 Julio, 2026 08:02

Esto me describe exactamente a mí ; así que, para crear una categoría solo para usuarios registrados, configuré su permiso de acceso para que solo fuera TL0, confiando en el grupo de usuarios automático TL0 para distinguir a los usuarios conectados de los invitados.

Me pregunto si existe una tabla que distinga el significado de este término en diferentes contextos. Estas diferencias son tanto confusas como inquietantes, porque cuando la gente eligió esta configuración originalmente, probablemente no sabía su significado real, por lo que querrían verificar la configuración relacionada. Actualmente, solo puedo verificar cada lugar donde se configuran los grupos individualmente y confirmar lo que significaba antes viendo a quién se cambió después de habilitar la función de grupos detallados, lo cual se siente como tanteando a ciegas.

martin · 6 Julio, 2026 01:59

Es una buena idea… Tal vez pueda improvisar algo con IA para que busque en todos los lugares donde se usan configuraciones basadas en grupos y determine si es posible que anonymous pueda acceder a esas cosas.

Hay un montón de configuraciones que ya impiden que se seleccione el grupo anonymous_users, así que esas probablemente sean un buen punto de partida… volveré aquí con los resultados.

Estoy trabajando ahora en PRs para esto:

github.com/discourse/discourse

DEV: Add resolve_group_membership functionality to theme settings (#41360)

main ← dev/theme-setting-group-setting-membership

merged 11:29PM - 07 Jul 26 UTC

martin-brennan

+517 -10

Currently, theme settings with `type: list` and `list_type: group` require clie…nt-side permission checks, but `currentUser.groups` only includes visible groups, not all groups the user belongs to. This makes permission checks unreliable and can leak hidden group membership. To address this, this commit adds an opt-in `resolve_group_membership: true` option that replaces the group ID list with a user_in_SETTING_NAME boolean resolved server-side via `guardian.in_any_groups?`. The original group list is removed from the frontend payload to prevent leaking group IDs. Since theme settings are cached per-theme (not per-user), the resolution happens after the cache lookup during per-request serialization in `ApplicationLayoutPreloader#activated_themes_json`. Example YAML: ```yaml copy_button_allowed_groups: type: list list_type: group resolve_group_membership: true default: "1|3" ``` Frontend usage: ```javascript if (!settings.user_in_copy_button_allowed_groups) return; ```

Habrá PRs de seguimiento y cambios en la documentación poco después.

martin · 6 Julio, 2026 05:54

@Noble_Fish, esta es la lista generada por IA de configuraciones basadas en grupos, para qué sirve cada configuración y cómo aplican los usuarios anónimos/registrados a esa configuración. Ten en cuenta que tengo un razonable nivel de confianza en que esto es correcto, pero como con cualquier contenido generado por IA, es bueno verificar los hechos por ti mismo.

Creo que la columna más interesante es “¿everyone también incluía anonymous_users antes del cambio?”, si esto es Sí, significa que everyone se refería a usuarios registrados Y anónimos antes de que se aplicara este próximo cambio.

Como puedes ver, solo hay unos pocos en la lista, así que esos son los únicos a los que un administrador necesitaría agregar explícitamente anonymous_users en la configuración del sitio:

hidden_post_visible_groups - De hecho, necesito cambiar este para permitir anonymous_users, el código no es del todo correcto para este próximo cambio.
lazy_load_categories_groups - También necesito corregir este, hace una verificación redundante de everyone que ya se realiza dentro de user.in_any_groups?
styleguide_allowed_groups - Esto funciona tal como está, pero también lo ajustaré un poco

Cuando este próximo cambio se haga permanente, los grupos logged_in_users y anonymous_users se usarán exclusivamente, y everyone será eliminado.

Configuración	Descripción	¿Aplica a `logged_in_users`?	¿Aplica a `anonymous_users`?	¿`everyone` también incluía `anonymous_users` antes del cambio?	Búsqueda de código
`whispers_allowed_groups`	Permitir comunicación privada dentro de temas para miembros de grupos especificados.	No	No	No	`everyone`, `logged_in_users` y `anonymous_users` están deshabilitados; el tiempo de ejecución también espera membresía de grupo concreto.
`hidden_post_visible_groups`	Permitir a miembros de estos grupos ver publicaciones ocultas. Los usuarios del personal siempre pueden ver publicaciones ocultas.	Sí	No	Sí	Verifica `everyone` antes de rechazar usuarios anónimos; de lo contrario usa `in_any_groups?`.
`about_page_hidden_groups`	No mostrar miembros de grupos específicos en la página `/about`.	No	No	No	Usa `group_users`; los pseudogrupos no tienen filas de miembros.
`about_page_extra_groups`	Grupos a mostrar en la página about debajo de los moderadores.	No	No	No	Carga grupos y miembros concretos para mostrar.
`anonymous_posting_allowed_groups`	Grupos que tienen permitido habilitar publicaciones anónimas.	Sí	No	No	Control de usuario registrado vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`personal_message_enabled_groups`	Permitir a usuarios en estos grupos crear mensajes personales.	Sí	No	No	Control de usuario registrado vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`shared_drafts_allowed_groups`	Permitir a usuarios en estos grupos ver y editar Borradores Compartidos.	Sí	No	No	Control de guardian de usuario; `anonymous_users` está deshabilitado.
`here_mention_allowed_groups`	Grupos que tienen permitido mencionar `@here`.	Sí	No	No	Requiere usuario autenticado; `anonymous_users` está deshabilitado.
`approve_unless_allowed_groups`	Publicaciones de usuarios que no están en estos grupos deben ser aprobadas.	Sí	No	No	Control de usuario vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`approve_new_topics_unless_allowed_groups`	Nuevos temas de usuarios que no están en estos grupos deben ser aprobados.	Sí	No	No	Control de usuario vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`skip_review_media_groups`	Usuarios fuera de estos grupos tienen publicaciones con multimedia incrustada enviadas para revisión.	Sí	No	No	Control de usuario vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`content_localization_allowed_groups`	Grupos permitidos para actualizar contenido localizado.	Sí	No	No	Control de guardian/usuario; `anonymous_users` está deshabilitado.
`email_in_allowed_groups`	Grupos que tienen permitido publicar nuevos temas por correo electrónico.	Sí	No	No	Control de usuario remitente de correo electrónico; `anonymous_users` está deshabilitado.
`view_raw_email_allowed_groups`	Grupos que pueden ver el contenido de correos electrónicos entrantes sin formato.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`uploaded_avatars_allowed_groups`	Especificar grupos permitidos para subir fotos de perfil personalizadas.	Sí	No	No	Control de usuario actual/objetivo; `anonymous_users` está deshabilitado.
`create_topic_allowed_groups`	Grupos que tienen permitido crear nuevos temas.	Sí	No	No	Requiere usuario y usa `in_any_groups?`; `anonymous_users` está deshabilitado.
`topic_timers_allowed_groups`	Grupos que tienen permitido establecer temporizadores de tema.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`edit_wiki_post_allowed_groups`	Grupos que tienen permitido editar publicaciones marcadas como wiki.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`edit_post_allowed_groups`	Grupos que tienen permitido editar publicaciones.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`self_wiki_allowed_groups`	Permitir a usuarios en estos grupos hacer sus propias publicaciones wiki.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`send_email_messages_allowed_groups`	Grupos que tienen permitido enviar mensajes personales por correo electrónico.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`flag_post_allowed_groups`	Grupos que tienen permitido marcar publicaciones.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`post_links_allowed_groups`	Grupos que tienen permitido incluir enlaces en publicaciones.	Sí	No	No	Requiere usuario autenticado; `anonymous_users` está deshabilitado.
`embedded_media_post_allowed_groups`	Usuarios en estos grupos tienen permitido incrustar elementos multimedia en una publicación.	Sí	No	No	Control de usuario actuante; `anonymous_users` está deshabilitado.
`profile_background_allowed_groups`	Grupos que tienen permitido subir un fondo de perfil.	Sí	No	No	Control de usuario; `anonymous_users` está deshabilitado.
`user_card_background_allowed_groups`	Grupos que tienen permitido subir un fondo de tarjeta de usuario.	Sí	No	No	Control de usuario; `anonymous_users` está deshabilitado.
`invite_allowed_groups`	Grupos que tienen permitido invitar usuarios.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`ignore_allowed_groups`	Grupos que tienen permitido ignorar a otros usuarios.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`delete_all_posts_and_topics_allowed_groups`	Grupos permitidos para eliminar publicaciones y temas creados por otros usuarios y ver contenido eliminado.	Sí	No	No	Control de usuario actual/guardian; `anonymous_users` está deshabilitado.
`edit_all_topic_groups`	Permitir a usuarios en este grupo editar títulos, etiquetas y categorías de temas de otros usuarios.	Sí	No	No	División cruda luego `in_any_groups?`; `anonymous_users` está deshabilitado.
`edit_all_post_groups`	Permitir a usuarios en este grupo editar publicaciones de otros usuarios.	Sí	No	No	Control de usuario vía `in_any_groups?`; `anonymous_users` está deshabilitado.
`change_post_ownership_allowed_groups`	Permitir a usuarios en estos grupos cambiar la propiedad de publicaciones.	Sí	No	No	Control de usuario actual; `anonymous_users` está deshabilitado.
`cross_origin_opener_unsafe_none_groups`	Grupos ocultos de anulación de COOP; los usuarios coincidentes obtienen `Cross-Origin-Opener-Policy: unsafe-none`.	Sí	No	No	Requiere `current_user.present?`; la selección anónima no tiene efecto en tiempo de ejecución.
`user_api_key_allowed_groups`	Se requiere membresía de grupo para la generación de claves de API de usuario.	Sí	No	No	Control de usuario actual; `anonymous_users` está deshabilitado.
`create_tag_allowed_groups`	Grupos que tienen permitido crear etiquetas.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`edit_tags_allowed_groups`	Grupos que tienen permitido editar etiquetas, descripciones de etiquetas y sinónimos de etiquetas.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`tag_topic_allowed_groups`	Grupos que tienen permitido etiquetar temas.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`pm_tags_allowed_for_groups`	Permitir a miembros de grupos incluidos etiquetar cualquier mensaje personal.	Sí	No	No	Control de usuario guardian; `anonymous_users` está deshabilitado.
`lazy_load_categories_groups`	Carga diferida de información de categorías solo para usuarios de estos grupos.	Sí	Sí	Sí	Verificación explícita de `everyone` más `in_any_groups?` de guardian; `anonymous_users` es significativo.
`chat_allowed_groups`	Usuarios en estos grupos pueden chatear, excepto usuarios anónimos que solo pueden ver el chat cuando se agregan a esta configuración.	Sí	Sí	No	El chat de usuario registrado usa `in_any_groups?`; el chat público anónimo verifica explícitamente `anonymous_users`.
`direct_message_enabled_groups`	Permitir a usuarios dentro de estos grupos crear Chats Personales de usuario a usuario.	Sí	No	No	Control de guardian de chat de usuario registrado; no hay ruta de DM anónima significativa.
`chat_pinning_messages_allowed_groups`	Usuarios en estos grupos tienen permitido fijar mensajes de chat.	Sí	No	No	Requiere acceso a chat/usuario actual; no hay ruta de fijación anónima.
`chat_message_flag_allowed_groups`	Usuarios en estos grupos tienen permitido marcar mensajes de chat.	Sí	No	No	Control de usuario; la ruta anónima está bloqueada por permisos de chat circundantes.
`no_ads_for_groups`	No mostrar anuncios a usuarios en estos grupos.	Sí	No	No	Agregado solo al serializador de `current_user`; no hay carga útil de usuario actual anónima.
`adsense_exclude_groups`	Los anuncios no se mostrarán a miembros de estos grupos.	Sí	No	No	Bandera de anuncio de usuario actual vía `in_any_groups?`; no hay carga útil de usuario actual anónima.
`dfp_exclude_groups`	Los anuncios no se mostrarán a miembros de estos grupos.	Sí	No	No	Bandera de anuncio de usuario actual vía `in_any_groups?`.
`amazon_exclude_groups`	Los anuncios no se mostrarán a miembros de estos grupos.	Sí	No	No	Bandera de anuncio de usuario actual vía `in_any_groups?`.
`carbonads_exclude_groups`	Los anuncios no se mostrarán a miembros de estos grupos.	Sí	No	No	Bandera de anuncio de usuario actual vía `in_any_groups?`.
`adbutler_exclude_groups`	Los anuncios no se mostrarán a miembros de estos grupos.	Sí	No	No	Bandera de anuncio de usuario actual vía `in_any_groups?`.
`composer_ai_helper_allowed_groups`	Usuarios en estos grupos verán el botón de asistente de IA en el compositor.	Sí	No	No	Control de asistente de IA de usuario registrado vía `in_any_groups?`.
`post_ai_helper_allowed_groups`	Grupos de usuarios permitidos para acceder a funciones de Asistente de IA en publicaciones.	Sí	No	No	Control de asistente de IA de usuario registrado vía `in_any_groups?`.
`ai_pm_summarization_allowed_groups`	Grupos permitidos para crear y ver resúmenes en mensajes personales.	No	No	No	Usa `user.group_ids` crudo, por lo que los pseudogrupos no coinciden.
`ai_bot_debugging_allowed_groups`	Permitir a estos grupos ver un botón de depuración que muestra la solicitud y respuesta de IA sin formato.	Sí	No	No	Devuelve explícitamente falso para anónimos, luego usa `in_any_groups?`.
`ai_bot_allowed_groups`	Cuando el Bot GPT tiene acceso al mensaje personal, responderá a miembros de estos grupos.	Sí	No	No	Los controles principales usan `in_any_groups?`; una ruta de campo de juego usa `group_ids` crudo.
`ai_bot_public_sharing_allowed_groups`	Permitir a estos grupos compartir mensajes personales de IA con el público a través de un enlace único.	Sí	No	No	Devuelve explícitamente falso para anónimos, luego usa `in_any_groups?`.
`assign_allowed_on_groups`	Usuarios en estos grupos tienen permitido asignar temas.	No	No	No	Usa `user.group_ids`/`GroupUser` crudo; los pseudogrupos no tienen filas.
`discourse_post_event_allowed_on_groups`	Grupos que tienen permitido crear eventos.	No	No	No	`groups.where(id: ...)` crudo; `everyone` tiene un caso especial, pero `logged_in_users` no.
`discourse_kanban_manage_board_allowed_groups`	Grupos permitidos para crear y configurar tableros kanban.	Sí	No	No	El guardian usa `in_any_groups?`, pero los controladores de escritura requieren inicio de sesión.
`create_policy_allowed_groups`	Se requiere membresía de grupo para agregar políticas a publicaciones.	Sí	No	No	Control de publicación/usuario vía `in_any_groups?`.
`flag_posts_voting_comments_allowed_groups`	Grupos permitidos para marcar un comentario de votación de publicación.	Sí	No	No	Control de usuario vía `in_any_groups?`.
`allow_solved_in_groups`	Permitir marcar soluciones en mensajes de grupo para estos grupos.	Sin control de usuario	Sin control de usuario	Sin control de usuario	Coincide con `topic.allowed_groups` del mensaje personal, no con la membresía del usuario actual.
`accept_all_solutions_allowed_groups`	Grupos que tienen permitido aceptar soluciones en cualquier tema.	Sí	No	No	Control de usuario autenticado/actual vía `in_any_groups?`.
`discourse_templates_groups_allowed_private_templates`	Grupos permitidos para usar plantillas privadas.	No	No	No	`GroupUser.exists?` crudo; solo `everyone` tiene un caso especial.
`poll_create_allowed_groups`	Los grupos que tienen permitido crear encuestas.	Sí	No	No	Control de usuario actuante/actual vía `in_any_groups?`.
`styleguide_allowed_groups`	Limita la visibilidad de la guía de estilo a miembros de los grupos proporcionados.	Sí	Sí	Sí	El controlador maneja explícitamente `anonymous_users`; también permitía anónimos a través de `everyone` antes del cambio.

martin · 6 Julio, 2026 06:40

Separa estos ajustes en un nuevo PR:

github.com/discourse/discourse

DEV: Minor fixes to everyone-based permissions for granular_anonymous_and_logged_in_groups_permissions (#41459)

main ← dev/uc-everyone-group-minor-fixes

merged 11:38PM - 06 Jul 26 UTC

martin-brennan

+44 -22

Some minor changes based on findings in https://meta.discourse.org/t/granular-gr…oup-based-permissions-for-anonymous-and-logged-in-users/402273/12?u=martin , see individual commits for details. - **DEV: Cleanup hidden_post_visible_groups usage** - **DEV: Cleanup can_lazy_load_categories?** - **FIX: Access check for styleguide_allowed_groups in styleguide**

martin · 8 Julio, 2026 06:36

@moin este PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub ya está fusionado y estoy añadiendo documentación en DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub. He corregido discourse-copy-post con DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub y ahora estoy revisando nuestros otros plugins oficiales para ver si alguno más necesita el mismo tratamiento (por ejemplo, ya señalaste GitHub - discourse/discourse-unanswered-filter · GitHub).

Para tu propio Filter Favorites, puedes ver el ejemplo de copy-post que hice, pero básicamente necesitas añadir resolve_group_membership: true tanto a default_favorite_filters_groups como a custom_favorite_filters_allowed_groups, luego estarán disponibles como valores booleanos dependiendo de las membresías de grupo del usuario en settings como settings.user_in_default_favorite_filters_groups y settings.user_in_custom_favorite_filters_allowed_groups respectivamente, y ya no necesitarás verificar manualmente los IDs de grupo de usuario en el frontend.

Cambiaría el valor predeterminado de default_favorite_filters_groups a 4|5 en tu componente de tema, que son usuarios iniciados sesión y anónimos, en lugar de 0 (everyone) que pronto se eliminará.

Haré una nota para ejecutar una migración de BD en la configuración de temas cuando elimine el grupo everyone, también necesito hacer una para la configuración del sitio, esto sucederá cuando el cambio próximo se vuelva permanente en las próximas semanas (dependiendo de si surjan otros problemas y qué tan rápido pueda corregir otros temas/componentes que necesiten añadir resolve_group_membership).

No, por el momento no hay forma de hacer esto como hay para la configuración del sitio… no creo que sea necesario añadirlo ahora mismo, simplemente puedes mencionarlo en la descripción de la configuración y protegerlo con currentUser en el frontend de todos modos. Quizás en el futuro lo añada si hay más necesidad.

Moin · 8 Julio, 2026 18:44

¿Esto también funciona para el tipo groups en la configuración de objetos?

martin · 9 Julio, 2026 00:57

No, ¿es necesario? No estaba al tanto de esto, no sé si se usa para permisos o no.

Moin · 9 Julio, 2026 05:18

Creo que se utiliza, por ejemplo, en Discourse Group Sidebar Menus para que los administradores puedan configurar qué grupos deberían poder ver cada sección de la barra lateral, y se usa en Notification Banners para configurar la visibilidad de cada banner.

Asumí que también lo usarías en tu componente de anuncios. Pero parece que depende de una cadena de nombres de grupos en su lugar.

Intento preferir la configuración de tipo de grupo, porque ayuda al administrador a ingresar fácilmente los grupos con un menú desplegable, mientras que dependen de los IDs de grupo, que es menos probable que cambien en comparación con los nombres. Y creo que es confuso si la lista de grupos en una configuración de objeto y el tipo de lista no funcionan de la misma manera.

Para mí, escribir "everyone" también resultará en "trust_level_0" porque esto no funciona para visitantes es diferente de la nueva versión, donde el menú desplegable ofrece explícitamente "anonymous_users" - incluso si digo que no funcionará. Si decirlo en la descripción era suficiente, podrías haber hecho lo mismo para las configuraciones del sitio. Para el administrador que usa ambos tipos de configuraciones, será difícil entender por qué, en algunos lugares, los grupos que no funcionan están ocultos, y en otros lugares, no lo están - no porque el creador del componente no se haya preocupado, sino porque aún no es posible en ese lugar.

martin · 9 Julio, 2026 23:42

Vale, gracias por encontrar ejemplos, tendré que incorporar este cambio a los objetos de configuración del tema con el tipo de grupo. Este, por ejemplo, de los menús laterales de grupos, creo que lo haría funcionar de la misma manera, así que tendrías esto en la configuración:

groups:
  type: groups
  required: true
  resolve_group_memberships: true
  validations:
    max: 20

Luego, en el cliente, groups se convertiría en user_in_groups como un booleano.

La funcionalidad de disallowed_groups podría no ser demasiado difícil en realidad… tomando lo anterior, terminarías con esto para deshacerte de anonymous_users:

groups:
  type: groups
  required: true
  resolve_group_memberships: true
  disallowed_groups: "4"
  validations:
    max: 20

Y para la configuración regular del tipo de grupo del tema:

copy_button_allowed_groups:
  type: list
  list_type: group
  default: "11" # trust_level_1
  disallowed_groups: "4" # anonymous_users
  description: "Selecciona los grupos que tienen permitido usar el botón de copiar."
  resolve_group_membership: true

Veré la posibilidad de agregar esta funcionalidad.

Tema		Respuestas	Vistas
Simpler and faster Category Settings page UX category-groups	23	422	27 Marzo 2025
New category permission - "cannot see"/"exclude" Feature	36	4575	4 Septiembre 2024
Changes coming to settings for giving access to features (from trust levels to groups) Announcements trust-levels	30	5590	2 Marzo 2025
Allow moderators to add a member to a group? Feature	48	11318	28 Diciembre 2017
Improving the Groups page for 1.7 Feature feedback	70	11068	11 Enero 2017

Permisos granulares basados en grupos para usuarios anónimos y registrados

Solución

¿Qué pasa con los permisos de etiquetas y categorías?

Temas relacionados