Permissões granulares baseadas em grupos para usuários anônimos e logados

martin · Maio 13, 2026, 1:18am

Houve um pseudogrupo historicamente confuso chamado @everyone em nossa base de código, que pode ser usado para:

Configurações do site do tipo group_list
Permissões de categoria
Grupos de tags

Em alguns casos, as pessoas interpretam @everyone como “todos os usuários anônimos e todos os usuários logados”, enquanto outras entendem que significa apenas “todos os usuários logados”. Na realidade, para configurações do site, na maioria dos casos, isso significa apenas “todos os usuários logados”.

Ainda mais confuso é o fato de que esse grupo @everyone pode ser usado em configurações do site onde não faz sentido que “todos os usuários anônimos e logados” tenham acesso ao recurso, como em pm_tags_allowed_for_groups.

Isso também gera confusão do ponto de vista de sinalização de recursos e experiência do desenvolvedor, pois para algumas mudanças futuras ou outras configurações, podemos realmente querer habilitá-las para “todos os usuários anônimos e logados”.

Solução

Estamos introduzindo dois pseudogrupos automáticos separados:

anonymous_users (ID 4) — Representa usuários anônimos que visitam seu site sem conta
logged_in_users (ID 5) — Representa todos os usuários logados em seu site, com efeito semelhante ao grupo automático trust_level_0, mas mais específico

Esses grupos já foram introduzidos, mas só entrarão em vigor quando a mudança futura granular_anonymous_and_logged_in_groups_permissions for habilitada em seu site.

Quando a mudança futura for habilitada, qualquer configuração com everyone como grupo selecionado será automaticamente traduzida para o ID logged_in_users, de modo que nenhum dado na tabela de configurações do site será alterado ao alternar a mudança futura. Quando a mudança futura se tornar permanente, realizaremos uma migração de dados para todas as configurações de grupo para aplicar essa alteração.

Além disso, marcamos anonymous_users como um disallowed_group para várias configurações do site onde não faz sentido, como personal_message_enabled_groups.

Conflitos com nomes de grupos existentes são tratados automaticamente, renomeando os grupos existentes e atualizando as menções de grupo nos posts.

E quanto às permissões de tags e categorias?

Essas permissões permanecerão inalteradas, pois o conceito de “todos” nelas difere de algumas maneiras e não depende do grupo automático subjacente.

Jagster · Maio 13, 2026, 6:42am

Espera… o quê Isso significa que todas as categorias que agora são públicas (todos) serão alteradas para categorias fechadas que exigem login, quando isso for ativado?

martin · Maio 13, 2026, 6:45am

Não, porque:

Isso afeta apenas as configurações do site do tipo lista de grupos que atualmente permitem selecionar “todos” da seguinte forma:

Moin · Junho 7, 2026, 8:59pm

Alguém pode me ajudar a entender como preciso ajustar meus componentes de tema?

Tentei usar o componente copy-post como exemplo, pois lembro que ele também usa uma configuração de grupo que concede acesso ao recurso. E que houve um problema porque o pseudogrupo “everyone” exigia uma verificação separada, assim como no meu componente, pois comparar os IDs dos grupos aos quais o usuário pertence não ajuda — esses IDs precisam ser verificados separadamente. Por isso, eu esperava uma mudança recente ali, pois, conforme entendo, os novos grupos também são pseudogrupos e o ID precisaria ser verificado separadamente. Estou perdendo algo que explique por que isso não é necessário aqui?

Meu componente favorite filters possui duas configurações de grupo: uma que permite que grupos salvem seus próprios filtros e outra que oferece filtros padrão.
Por padrão, apenas membros do grupo trust_level_0 podem usar filtros personalizados, pois apenas usuários registrados podem ter dados armazenados em um campo personalizado de usuário. Então, aqui faria sentido se eu não permitisse anonymous_users como uma seleção. Como faço isso em um componente de tema? Já existe algum exemplo para isso?

A configuração padrão para os filtros padrão é “everyone”, pois acho útil que até mesmo usuários não registrados possam ver e usar os filtros padrão. O problema é que everyone muda para logged_in_users, mesmo que eu o tenha selecionado especificamente. Preciso criar uma migração personalizada para isso, para que os administradores que atualmente usam everyone continuem tendo filtros para usuários não registrados no futuro? Quando essa migração precisa ocorrer? Ou cada administrador precisa alterar isso individualmente após você ter executado a migração?

Tudo isso que estou me preocupando é realmente desnecessário? Se forem necessários ajustes, menos de quatro semanas parece um prazo bastante curto, dado o número de componentes mantidos pela comunidade que poderiam ser potencialmente afetados.
Além do “copy-post”, também examinei o componente unanswered filter, mas não encontrei nenhuma mudança ali também. Sinto como se estivesse ignorando algo importante. Afinal, a mudança foi ativada por padrão há quase uma semana. Por isso, assumo que os componentes oficiais já teriam sido atualizados se ajustes fossem necessários.

HAWK · Junho 7, 2026, 10:28pm

3 posts foram mesclados em um tópico existente: Modernizando o tema Foundation

martin · Junho 8, 2026, 5:23am

Ao analisar esses componentes, currentUser?.groups não é confiável de qualquer forma, pois inclui apenas os grupos visíveis para o usuário, e os grupos nos quais ele está e que afetam as permissões podem não ser serializados aqui:

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

No núcleo e nos plugins, contornamos isso fazendo coisas como esta no serializador do usuário atual:

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

Mas, obviamente, isso não está disponível para componentes de temas e seus ajustes.

Hmm, não tenho certeza, terei que pensar sobre isso. Se você realmente quis dizer everyone, então seria necessário alterar para logged_in_users E anonymous_users. Esse foi o principal problema com everyone, conforme mencionado no OP — algumas pessoas interpretaram como apenas usuários logados, outras como logados + anônimos, e isso dependia muito da situação.

Escolhi a interpretação de „apenas usuários logados“ porque era mais segura do ponto de vista de segurança.

Não, simplesmente não pensei em componentes de temas e seus ajustes e como seriam impactados por essa mudança. Eu estava focado principalmente nas configurações do site. Coisas como essa serão especialmente difíceis de encontrar, pois nem mesmo estão usando a constante AUTO_GROUPS:

De qualquer forma, vou pensar em algumas soluções para esses problemas e não avançarei essa mudança para a versão Stable até resolvê-los.

martin · Junho 26, 2026, 1:46am

Atualização rápida: tenho uma ideia de como lidar com isso e estamos discutindo internamente. Espero que não demore muito

Noble_Fish · Julho 5, 2026, 8:02am

Isso é exatamente o meu caso ; então, para criar uma categoria apenas para usuários registrados, defini sua permissão de acesso como apenas TL0, confiando no grupo de usuários automático TL0 para distinguir usuários conectados de visitantes.

Estou pensando se existe uma tabela para distinguir o significado desse termo em diferentes contextos. Essas diferenças são confusas e perturbadoras — porque, quando as pessoas originalmente escolheram essa configuração, provavelmente não sabiam seu significado real, então elas desejariam verificar as configurações relacionadas. Atualmente, só posso verificar individualmente cada local onde os grupos são definidos e confirmar o que significava antes, vendo para quem foi alterado após a ativação do recurso de grupos granulares — o que parece estar tateando no escuro.

martin · Julho 6, 2026, 1:59am

Essa é uma boa ideia… Talvez eu consiga arranjar algo com IA para procurar em todos os lugares onde as configurações baseadas em grupos são usadas e verificar se é possível que anonymous acesse essas coisas.

Há várias configurações que já não permitem que o grupo anonymous_users seja selecionado, então essas provavelmente são um bom ponto de partida… vou retornar aqui com os resultados.

Estou trabalhando agora em PRs para isso:

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; ```

Teremos PRs de acompanhamento e alterações na documentação em breve.

martin · Julho 6, 2026, 5:54am

@Noble_Fish , esta é a lista gerada por IA de configurações baseadas em grupos, para que serve cada configuração e como usuários anônimos/autenticados se aplicam a essa configuração. Esteja ciente de que tenho uma confiança razoável de que isso está correto, mas como qualquer coisa gerada por IA, é bom verificar os fatos você mesmo.

Acho que a coluna mais interessante é “everyone também incluía anonymous_users antes da mudança?”, se for Sim, isso significa que everyone significava autenticado E anônimo antes que esta mudança iminente fosse aplicada.

Como você pode ver, há apenas alguns aqui, então esses são os únicos que um administrador precisaria adicionar explicitamente anonymous_users nas configurações do site:

hidden_post_visible_groups - Eu realmente preciso mudar este para permitir anonymous_users, o código não está totalmente certo para esta mudança iminente.
lazy_load_categories_groups - Eu preciso corrigir este também, ele faz uma verificação redundante de everyone que já é feita dentro de user.in_any_groups?
styleguide_allowed_groups - Isso funciona como está, mas vou ajustá-lo um pouco

Quando esta mudança iminente se tornar permanente, os grupos logged_in_users e anonymous_users serão usados exclusivamente, e everyone será excluído.

Configuração	Descrição	`logged_in_users` se aplica?	`anonymous_users` se aplica?	`everyone` também incluía `anonymous_users` antes da mudança?	Achado no código
`whispers_allowed_groups`	Permitir comunicação privada dentro de tópicos para membros de grupos especificados.	Não	Não	Não	`everyone`, `logged_in_users` e `anonymous_users` são proibidos; o tempo de execução também espera pertencimento a grupo concreto.
`hidden_post_visible_groups`	Permitir que membros desses grupos vejam posts ocultos. Usuários da equipe sempre podem ver posts ocultos.	Sim	Não	Sim	Verifica `everyone` antes de rejeitar usuários anônimos; caso contrário, usa `in_any_groups?`.
`about_page_hidden_groups`	Não mostrar membros de grupos específicos na página `/about`.	Não	Não	Não	Usa `group_users`; pseudogrupos não têm linhas de membros.
`about_page_extra_groups`	Grupos para mostrar na página about abaixo dos moderadores.	Não	Não	Não	Carrega grupos concretos e membros para exibição.
`anonymous_posting_allowed_groups`	Grupos que podem habilitar postagem anônima.	Sim	Não	Não	Verificação de usuário autenticado via `in_any_groups?`; `anonymous_users` é proibido.
`personal_message_enabled_groups`	Permitir que usuários nesses grupos criem mensagens pessoais.	Sim	Não	Não	Verificação de usuário autenticado via `in_any_groups?`; `anonymous_users` é proibido.
`shared_drafts_allowed_groups`	Permitir que usuários nesses grupos vejam e editem Rascunhos Compartilhados.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`here_mention_allowed_groups`	Grupos que podem mencionar `@here`.	Sim	Não	Não	Requer usuário autenticado; `anonymous_users` é proibido.
`approve_unless_allowed_groups`	Posts de usuários não nesses grupos devem ser aprovados.	Sim	Não	Não	Verificação de usuário via `in_any_groups?`; `anonymous_users` é proibido.
`approve_new_topics_unless_allowed_groups`	Novos tópicos de usuários não nesses grupos devem ser aprovados.	Sim	Não	Não	Verificação de usuário via `in_any_groups?`; `anonymous_users` é proibido.
`skip_review_media_groups`	Usuários fora desses grupos têm posts com mídia incorporada enviados para revisão.	Sim	Não	Não	Verificação de usuário via `in_any_groups?`; `anonymous_users` é proibido.
`content_localization_allowed_groups`	Grupos permitidos para atualizar conteúdo localizado.	Sim	Não	Não	Verificação de guardião/usuário; `anonymous_users` é proibido.
`email_in_allowed_groups`	Grupos que podem criar novos tópicos via e-mail.	Sim	Não	Não	Verificação de usuário remetente de e-mail; `anonymous_users` é proibido.
`view_raw_email_allowed_groups`	Grupos que podem ver o conteúdo de e-mails recebidos em formato bruto.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`uploaded_avatars_allowed_groups`	Especificar grupos permitidos para fazer upload de fotos de perfil personalizadas.	Sim	Não	Não	Verificação de usuário atual/destino; `anonymous_users` é proibido.
`create_topic_allowed_groups`	Grupos que podem criar novos tópicos.	Sim	Não	Não	Requer usuário e usa `in_any_groups?`; `anonymous_users` é proibido.
`topic_timers_allowed_groups`	Grupos que podem definir temporizadores de tópico.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`edit_wiki_post_allowed_groups`	Grupos que podem editar posts marcados como wiki.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`edit_post_allowed_groups`	Grupos que podem editar posts.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`self_wiki_allowed_groups`	Permitir que usuários nesses grupos transformem seus próprios posts em wiki.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`send_email_messages_allowed_groups`	Grupos que podem enviar mensagens pessoais via e-mail.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`flag_post_allowed_groups`	Grupos que podem sinalizar posts.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`post_links_allowed_groups`	Grupos que podem incluir links em posts.	Sim	Não	Não	Requer usuário autenticado; `anonymous_users` é proibido.
`embedded_media_post_allowed_groups`	Usuários nesses grupos podem incorporar itens de mídia em um post.	Sim	Não	Não	Verificação de usuário atuante; `anonymous_users` é proibido.
`profile_background_allowed_groups`	Grupos que podem fazer upload de um fundo de perfil.	Sim	Não	Não	Verificação de usuário; `anonymous_users` é proibido.
`user_card_background_allowed_groups`	Grupos que podem fazer upload de um fundo de cartão de usuário.	Sim	Não	Não	Verificação de usuário; `anonymous_users` é proibido.
`invite_allowed_groups`	Grupos que podem convidar usuários.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`ignore_allowed_groups`	Grupos que podem ignorar outros usuários.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`delete_all_posts_and_topics_allowed_groups`	Grupos permitidos para excluir posts e tópicos criados por outros usuários e ver conteúdo excluído.	Sim	Não	Não	Verificação de guardião/usuário atual; `anonymous_users` é proibido.
`edit_all_topic_groups`	Permitir que usuários neste grupo editem títulos, tags e categorias de tópicos de outros usuários.	Sim	Não	Não	Divisão bruta e depois `in_any_groups?`; `anonymous_users` é proibido.
`edit_all_post_groups`	Permitir que usuários neste grupo editem posts de outros usuários.	Sim	Não	Não	Verificação de usuário via `in_any_groups?`; `anonymous_users` é proibido.
`change_post_ownership_allowed_groups`	Permitir que usuários nesses grupos mudem a propriedade de posts.	Sim	Não	Não	Verificação de usuário atual; `anonymous_users` é proibido.
`cross_origin_opener_unsafe_none_groups`	Grupos ocultos de substituição de COOP; usuários correspondentes recebem `Cross-Origin-Opener-Policy: unsafe-none`.	Sim	Não	Não	Requer `current_user.present?`; seleção anônima não tem efeito em tempo de execução.
`user_api_key_allowed_groups`	Pertencimento a grupo necessário para geração de chaves de API de usuário.	Sim	Não	Não	Verificação de usuário atual; `anonymous_users` é proibido.
`create_tag_allowed_groups`	Grupos que podem criar tags.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`edit_tags_allowed_groups`	Grupos que podem editar tags, descrições de tags e sinônimos de tags.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`tag_topic_allowed_groups`	Grupos que podem marcar tópicos com tags.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`pm_tags_allowed_for_groups`	Permitir que membros de grupos incluídos marquem qualquer mensagem pessoal com tags.	Sim	Não	Não	Verificação de guardião de usuário; `anonymous_users` é proibido.
`lazy_load_categories_groups`	Carregar informações de categoria preguiçosamente apenas para usuários desses grupos.	Sim	Sim	Sim	Verificação explícita de `everyone` mais guardião `in_any_groups?`; `anonymous_users` é significativo.
`chat_allowed_groups`	Usuários nesses grupos podem conversar, exceto usuários anônimos que só podem ver o chat quando adicionados a esta configuração.	Sim	Sim	Não	Chat de usuários autenticados usa `in_any_groups?`; chat público anônimo verifica explicitamente `anonymous_users`.
`direct_message_enabled_groups`	Permitir que usuários dentro desses grupos criem Chats Pessoais de usuário para usuário.	Sim	Não	Não	Verificação de guardião de chat de usuário autenticado; nenhum caminho significativo de DM anônimo.
`chat_pinning_messages_allowed_groups`	Usuários nesses grupos podem fixar mensagens de chat.	Sim	Não	Não	Requer acesso ao chat/usuário atual; nenhum caminho de fixação anônima.
`chat_message_flag_allowed_groups`	Usuários nesses grupos podem sinalizar mensagens de chat.	Sim	Não	Não	Verificação de usuário; caminho anônimo é bloqueado pelas permissões de chat circundantes.
`no_ads_for_groups`	Não mostrar anúncios para usuários nesses grupos.	Sim	Não	Não	Adicionado apenas ao serializador `current_user`; nenhuma carga de usuário atual anônima.
`adsense_exclude_groups`	Anúncios não serão mostrados para membros desses grupos.	Sim	Não	Não	Bandeira de anúncio de usuário atual via `in_any_groups?`; nenhuma carga de usuário atual anônima.
`dfp_exclude_groups`	Anúncios não serão mostrados para membros desses grupos.	Sim	Não	Não	Bandeira de anúncio de usuário atual via `in_any_groups?`.
`amazon_exclude_groups`	Anúncios não serão mostrados para membros desses grupos.	Sim	Não	Não	Bandeira de anúncio de usuário atual via `in_any_groups?`.
`carbonads_exclude_groups`	Anúncios não serão mostrados para membros desses grupos.	Sim	Não	Não	Bandeira de anúncio de usuário atual via `in_any_groups?`.
`adbutler_exclude_groups`	Anúncios não serão mostrados para membros desses grupos.	Sim	Não	Não	Bandeira de anúncio de usuário atual via `in_any_groups?`.
`composer_ai_helper_allowed_groups`	Usuários nesses grupos verão o botão de assistente de IA no compositor.	Sim	Não	Não	Verificação de assistente de IA de usuário autenticado via `in_any_groups?`.
`post_ai_helper_allowed_groups`	Grupos de usuários permitidos para acessar recursos do Assistente de IA em posts.	Sim	Não	Não	Verificação de assistente de IA de usuário autenticado via `in_any_groups?`.
`ai_pm_summarization_allowed_groups`	Grupos permitidos para criar e ver resumos em MPs.	Não	Não	Não	Usa `user.group_ids` bruto, então pseudogrupos não correspondem.
`ai_bot_debugging_allowed_groups`	Permitir que esses grupos vejam um botão de depuração mostrando a solicitação e resposta brutas da IA.	Sim	Não	Não	Retorna explicitamente falso para anônimos, depois usa `in_any_groups?`.
`ai_bot_allowed_groups`	Quando o GPT Bot tem acesso ao MP, ele responderá aos membros desses grupos.	Sim	Não	Não	As verificações primárias usam `in_any_groups?`; um caminho de playground usa `group_ids` bruto.
`ai_bot_public_sharing_allowed_groups`	Permitir que esses grupos compartilhem mensagens pessoais de IA com o público via um link único.	Sim	Não	Não	Retorna explicitamente falso para anônimos, depois usa `in_any_groups?`.
`assign_allowed_on_groups`	Usuários nesses grupos podem atribuir tópicos.	Não	Não	Não	Usa `user.group_ids`/`GroupUser` bruto; pseudogrupos não têm linhas.
`discourse_post_event_allowed_on_groups`	Grupos que podem criar eventos.	Não	Não	Não	`groups.where(id: ...)` bruto; `everyone` é tratado como caso especial, mas `logged_in_users` não.
`discourse_kanban_manage_board_allowed_groups`	Grupos permitidos para criar e configurar quadros kanban.	Sim	Não	Não	Guardião usa `in_any_groups?`, mas controladores de escrita exigem login.
`create_policy_allowed_groups`	Pertencimento a grupo necessário para adicionar políticas a posts.	Sim	Não	Não	Verificação de post/usuário via `in_any_groups?`.
`flag_posts_voting_comments_allowed_groups`	Grupos permitidos para sinalizar um comentário de votação em post.	Sim	Não	Não	Verificação de usuário via `in_any_groups?`.
`allow_solved_in_groups`	Permitir marcar soluções em mensagens de grupo para esses grupos.	Sem verificação de usuário	Sem verificação de usuário	Sem verificação de usuário	Corresponde a `topic.allowed_groups` do MP, não ao pertencimento do usuário atual.
`accept_all_solutions_allowed_groups`	Grupos que podem aceitar soluções em qualquer tópico.	Sim	Não	Não	Verificação de usuário autenticado/atual via `in_any_groups?`.
`discourse_templates_groups_allowed_private_templates`	Grupos permitidos para usar modelos privados.	Não	Não	Não	`GroupUser.exists?` bruto; apenas `everyone` é tratado como caso especial.
`poll_create_allowed_groups`	Os grupos que podem criar enquetes.	Sim	Não	Não	Verificação de usuário atuante/atual via `in_any_groups?`.
`styleguide_allowed_groups`	Limita a visibilidade do guia de estilo a membros dos grupos fornecidos.	Sim	Sim	Sim	Controlador lida explicitamente com `anonymous_users`; também permitia anônimos através de `everyone` antes da mudança.

martin · Julho 6, 2026, 6:40am

Separe esses ajustes em um novo 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 · Julho 8, 2026, 6:36am

@moin este PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub já foi mesclado e estou adicionando a documentação em DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub. Corrigi o discourse-copy-post com DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub e agora estou revisando nossos outros plugins oficiais para ver se algum outro precisa do mesmo tratamento (por exemplo, você já apontou para GitHub - discourse/discourse-unanswered-filter · GitHub)

Para o seu próprio Filter Favorites, você pode ver o exemplo de copy-post que fiz, mas basicamente você precisa adicionar resolve_group_membership: true tanto em default_favorite_filters_groups quanto em custom_favorite_filters_allowed_groups, então eles estarão disponíveis como valores booleanos dependendo das associações de grupo do usuário em settings como settings.user_in_default_favorite_filters_groups e settings.user_in_custom_favorite_filters_allowed_groups respectivamente, e agora você não precisa mais verificar manualmente os IDs de grupo do usuário no frontend.

Eu mudaria o padrão de default_favorite_filters_groups para 4|5 no seu componente de tema, que são usuários conectados e anônimos, em vez de 0 (everyone) que será removido em breve.

Farei uma anotação para executar uma migração de banco de dados nas configurações de tema quando eu remover o grupo everyone, preciso fazer uma para as configurações do site também, isso acontecerá quando a mudança iminente se tornar permanente nas próximas semanas (dependendo se outros problemas surgirem e o quão rápido eu conseguir corrigir outros temas/componentes que precisam ter resolve_group_membership adicionado).

Não, no momento não há como fazer isso como há para as configurações do site… Não acho que seja necessário adicionar agora, você pode apenas mencionar isso na descrição da configuração e proteger com currentUser no frontend de qualquer maneira. Talvez no futuro eu adicione isso se houver mais necessidade.

Moin · Julho 8, 2026, 6:44pm

Isso também funciona para o tipo groups nas configurações de objeto?

martin · Julho 9, 2026, 12:57am

Não, precisa? Eu não sabia disso, não sei se é usado para permissões ou não.

Moin · Julho 9, 2026, 5:18am

Acho que é usado, por exemplo, em Discourse Group Sidebar Menus para que os administradores possam configurar quais grupos devem poder ver cada seção da barra lateral, e é usado em Notification Banners para configurar a visibilidade de cada banner.

Eu assumi que você também o usaria em seu componente de anúncios. Mas parece que ele depende de uma string de nomes de grupos em vez disso.

Eu tento preferir as configurações do tipo grupo, porque elas ajudam o administrador a inserir grupos facilmente com uma lista suspensa, enquanto dependem de IDs de grupo, que são menos propensos a mudar em comparação com os nomes. E acho que é confuso se a lista de grupos em uma configuração de objeto e o tipo de lista não funcionarem da mesma maneira.

Para mim, escrever "everyone" também resultará em "trust_level_0" porque isso não funciona para visitantes é diferente da nova versão, onde a lista suspensa oferece explicitamente "anonymous_users" - mesmo que eu diga que não funcionará. Se dizer isso na descrição fosse suficiente, você poderia ter feito o mesmo para as configurações do site. Para o administrador usando ambos os tipos de configurações, será difícil entender por que, em alguns lugares, os grupos que não funcionarão estão ocultos, e em outros, não estão - não porque o criador do componente não se importou, mas porque ainda não é possível naquele lugar.

Tópico		Respostas	Visualizações
Simpler and faster Category Settings page UX category-groups	23	422	27 de Março de 2025
New category permission - "cannot see"/"exclude" Feature	36	4575	4 de Setembro de 2024
Changes coming to settings for giving access to features (from trust levels to groups) Announcements trust-levels	30	5588	2 de Março de 2025
Allow moderators to add a member to a group? Feature	48	11318	28 de Dezembro de 2017
Improving the Groups page for 1.7 Feature feedback	70	11068	11 de Janeiro de 2017

Permissões granulares baseadas em grupos para usuários anônimos e logados

Solução

E quanto às permissões de tags e categorias?

Tópicos relacionados