Sem problemas! Fico feliz que disallowed_groups será útil. Já integrei esse PR agora.
Preciso revisar todos os nossos temas e componentes oficiais agora que temos disallowed_groups e resolve_group_memberships disponíveis. Sugiro que você e @moin façam o mesmo quando puderem para seus próprios temas e componentes, pois, após fazer as alterações em nossos repositórios oficiais, gostaria muito de avançar com a estabilização da mudança mencionada no post original.
Há muito trabalho central agora dependendo ou usando anonymous_users e logged_in_users, e eu realmente gostaria de excluir o grupo everyone.
Acabei de fazer uma atualização completa da minha instância, e agora estou adicionando a configuração de objeto disallowed_groups ao meu componente para everyone e anonymous_users, com base nos IDs de grupo automático aqui:
O que estou fazendo de errado na configuração do objeto? Notei que, mesmo sem o disallowed_groups nos objetos, o grupo anonymous_users ainda não aparece (então, no momento, não há diferença na lista do meu componente, independentemente de eu definir disallowed_groups ou não). Testei com outros IDs de grupo e devo estar cometendo algum erro na forma como estou usando disallowed_groups (ou na sintaxe), pois não parece ter nenhum efeito, independentemente de quais eu uso.
Ah, houve alguns problemas no GitHub mais cedo no dia, então a alteração de disallowed_groups só acabou de ser incorporada à versão mais recente em Commits · discourse/discourse · GitHub
Não tenho certeza absoluta de que esse será o problema, mas você pode tentar atualizar novamente e ver se ele persiste? Se não for o caso, me avise e me indique seu componente de tema (ou é apenas o seu componente de barra lateral de grupo?) para que eu possa depurar
hah obrigado Moin! na verdade eu esqueci que a nova configuração granular de grupos já estava nas próximas mudanças de qualquer jeito.
Martin, a configuração do objeto disallowed_groups funciona perfeitamente. eu realmente gostei dessa mudança. obrigado mais uma vez Equipe - excelente melhoria.
Abri um PR rápido para adicionar essas duas classes (anonymous_users e logged_in_users).
Não testei direito (kkk), mas acho que é bem direto. O código só verifica se o usuário atual existe; se existir, ele é membro de logged_in_users, e se não, é anonymous_users.
observação: tenho quase certeza de que o Discourse adiciona .anon automaticamente de qualquer forma, então o CSS para usuários anônimos versus logados pode ser feito sem o componente, mas isso simplesmente usa as novas convenções de grupo.
Apenas para informação a todos, eu ainda não havia postado aqui, mas fundi esses PRs para que os componentes oficiais usem resolve_group_membership e disallowed_groups:
Estou trabalhando em um plano para as próximas etapas dessa mudança iminente. Acho que ainda há alguns lugares nas bases de código do núcleo/plugins que verificam everyone diretamente ou não usam user.in_any_groups? no lado do servidor.
Existe algum motivo pelo qual isso ainda não foi mesclado?
O motivo pelo qual abri este tópico é que finalmente atualizei meu componente
[quote=“martin, post:14, topic:402273”]
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 (todos), que será removido em breve.
[/quote]\nFiz isso. Mas ainda tenho a impressão de que isso ajuda apenas para fóruns que adicionam o componente depois que eu fiz essa alteração. Aqueles que já o estavam usando não recebem o novo padrão (o que geralmente é bom!). Então ainda vejo o problema de que há uma mudança inesperada de comportamento para aqueles que já usam o componente.
Além disso, você sabe o que acontece se um administrador configurou uma configuração com um grupo que eu adiciono como um grupo não permitido na minha atualização?
Como não acho que o componente seja usado em muitos fóruns, não me preocupei muito e mesclarei de qualquer maneira, mas tanto a migração quanto a configuração de grupos não permitidos podem ser relevantes para outros desenvolvedores de temas.
Não, por algum motivo acho que meu cérebro achou que isso não era um PR na organização do Discourse Farei o merge logo após os testes de CI serem executados.
Para casos como este e outros no futuro, acho que a melhor maneira é provavelmente escrever uma migração por tema/componente Migrate Discourse theme settings
No meu post acima, perguntei quando isso precisaria acontecer. Migrar sem ter certeza de que os novos grupos funcionam em todos os fóruns também pode causar problemas, e os administradores podem ativar e desativar a alteração. Portanto, parece impossível migrar no momento certo.
Peço desculpas se isso já foi mencionado e eu perdi…
Percebi que, se resolve_group_membership estiver incluído nas configurações, só consigo acessar o valor booleano através do prefixo user_in_, mas não consigo mais acessar o valor bruto do campo de configuração.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true ou false
Acho que sim. Caso contrário, a solução para esse bug poderia ter sido diferente.
Isso também faz sentido para mim. user_in_x também verifica grupos que o frontend não conhece, porque o grupo é visível apenas para administradores ou sua visibilidade é limitada por padrão, como everyone. Portanto, você obtém resultados diferentes dependendo do que usa, então combinar os dois poderia ter consequências inesperadas.
Obrigado, Moin, está exatamente certo. @gormus o único lugar onde os IDs reais dos grupos ainda aparecem é na interface administrativa para as configurações do tema.
Não tenho certeza se isso ficou claro com base no que postei antes, mas os grupos anonymous_users e logged_in_users podem ser usados a qualquer momento, mesmo sem essa alteração futura estar ativada; eu os adicionei independentemente há meses. Esta é a principal função da alteração futura:
Portanto, de qualquer forma, você estará seguro se eliminar everyone em todos os lugares onde é usado e usar apenas anonymous_users e logged_in_users a partir de agora.
Hoje planejo elaborar um plano do trabalho restante que preciso fazer para realmente eliminar everyone nas configurações do site (deixando as configurações de categoria de lado por enquanto), e o postarei aqui, com a esperança de que isso ajude a manter todos na mesma página no futuro, e eu possa continuar atualizando este plano conforme avanço.
Mas os grupos não são visíveis na interface se a alteração estiver desabilitada. Os administradores não podem alterar uma configuração para esses grupos. Portanto, quando adiciono “todos” como disallowed_group, eles não veem mais nenhum grupo que lhes permita configurar um componente para ser visível para visitantes. Para mim, “usável” implica não apenas funcionar, mas também ser visível. Como ainda é possível desabilitar a alteração, eu não chamaria de “seguro” depender apenas dos novos grupos.
Hmm, você tem razão. Há mais algumas coisas que preciso corrigir para que o problema desse disallowed_group desapareça quando a alteração iminente estiver desativada:
anonymous_users e logged_in_users não estão presentes no seletor de grupos. Acho que é seguro permitir isso aqui agora; assim, não importará se você adicionou everyone aos disallowed_groups caso a alteração iminente esteja desativada.
Corrigir Guardian::AnonymousUser#in_any_groups? para respeitar anonymous_users com a alteração iminente desativada.
Adicionar o mesmo alias de tempo de leitura de 0 (everyone) → 5 (logged_in_users) para as configurações de tema, que já fazemos para as configurações do site.
Acho que também vou marcar everyone com (legacy) no(s) seletor(es) de grupos enquanto a alteração iminente ainda for opcional e estiver desativada.
Priorizarei essas questões e as adicionarei ao meu plano geral que estou elaborando.
Criei um tópico dedicado aqui @moinThe road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . O post original está incompleto; ainda estou analisando todos os casos localmente e vou mantê-lo atualizado. Não me importo se você continuar postando neste tópico, mas prefiro que nossas discussões futuras aconteçam no novo tópico, para que eu possa citar partes do post original ou complementá-lo conforme necessário.
obrigado Moin! na verdade eu esqueci que a nova configuração granular de grupos já estava nas próximas mudanças de qualquer jeito.
Farei o merge logo após os testes de CI serem executados.