Ao adicionar grupos a uma categoria, as opções anonymous_users e logged_in_users podem ser selecionadas, mas não funcionam.
2 Curtiram
Isso não requer que o recurso beta “Permissões granulares para grupos anônimos e conectados” esteja ativado?
1 Curtiu
@martin alguma ideia sobre isso?
1 Curtiu
Obrigado pelo relatório, vou dar uma olhada 
Com base na sua resposta no outro tópico
Quanto mais penso nisso, mais me preocupo com isso.
O que acontece se eu adicionar apenas anonymous_users a uma categoria e não adicionar logged_in_users?
O que acontece se eu adicionar anonymous_users enquanto meu fórum estiver com login_required (login obrigatório)?
Além disso, a implementação técnica atual é que, quando as permissões de categoria estão definidas como everyone, simplesmente não há entrada em category_groups e read_restricted está definido como false.
Isso é muito simples e direto: se não houver permissões definidas, as permissões são determinadas pelas permissões globais do fórum (a configuração login_required) e nenhuma restrição adicional se aplica.
Então, fazer essa mudança adicionaria uma enorme quantidade de complexidade e combinações estranhas seriam possíveis (você poderia fazer usuários anônimos e staff 
)
Minha sugestão seria:
- remover
anonymous_userscomo opção para permissões de categoria completamente - manter
everyoneelogged_in_users - remover
trust_level_0como opção, já que equivale alogged_in_users
ou alternativamente, mas talvez menos claro para administradores menos experientes
- remover
anonymous_userselogged_in_userscomo opção para permissões de categoria - manter
everyone(e TL0)
Em todos os casos, mantenha everyone. E você também não precisará de uma migração 
4 Curtiram
Obrigado pelas suas observações, é por isso que eu não queria entrar muito em detalhes sobre permissões de categoria no início com aquela alteração de “todos” 
Acho que muita coisa do que você diz aqui poderia simplesmente ser tornada impossível. Já tenho trabalhado em alguns sistemas preliminares aqui com ACLs e uma interface de permissões mais amigável no nosso plugin kanban que estamos desenvolvendo. Aqui está um exemplo. Pretendemos mudar as permissões de categoria para usar isso eventualmente:
Há várias regras envolvidas aqui, como é impossível dar permissões de Gerente para usuários anônimos em um quadro kanban, e assim por diante, e até mesmo suporta permissões obrigatórias, como Administradores podem sempre gerenciar um quadro.
Nós faríamos com que você não pudesse adicionar usuários anônimos quando o fórum exigir login.
Novamente, outra validação/restrição que podemos adicionar.
Nós poderíamos adicionar validações/avisos para esse tipo de coisa também.
É isso que quero evitar, esse tipo de permissões implícitas que estão em todo o Discourse, em vez de ter usuários logados + usuários anônimos explicitamente configurados sempre para uma categoria se ela for pública/não restrita à leitura.
De qualquer forma, por enquanto, não quero entrar muito fundo nisso, ainda há um caminho a percorrer antes de eu lidar com categorias. Mas concordo que o OP é um bug que precisa ser corrigido no meio tempo, então ainda farei isso.
1 Curtiu
Com aquela outra questão em mente, eu pessoalmente recomendaria contra esse tipo de lógica. O que acontece quando eu mudo um fórum para exigir login quando já existem usuários anônimos na lista de permissões? E o contrário disso? Isso vai ser um pesadelo, e será opaco para os administradores.
Eu estou muito cauteloso com essa complexidade.
2 Curtiram
Novamente, mais pontos positivos. Há muito o que pensar, e esse assunto é complicado. Com certeza, terei em mente a experiência do administrador ao fazer alterações nas categorias, pois há muita história por trás disso e não quero que ninguém fique surpreso. Nada disso será feito rapidamente; levará muito tempo para analisar cuidadosamente os diferentes cenários quando eu chegar a esse projeto.
1 Curtiu
Me pergunto por que o fato de poder configurar coisas para anônimos, mas não para usuários logados, ser um problema no contexto de permissões de categoria, mas não no contexto de permissões configuradas via configurações de site/plugin/tema. Um exemplo simples: agora é possível tornar o styleguide disponível para anonymous_users sem adicionar logged_in_users. Isso faz mais sentido do que mostrar uma categoria para anônimos, mas não para usuários logados?
1 Curtiu
Não faz sentido, é apenas mais um caso extremo para cobrir… vou adicionar anonymous_users aos disallowed_groups para esse plugin. Além disso, duvido muito que haja muitos sites por aí com esse plugin ativado, então não estou muito preocupado com essa configuração incorreta no momento.
Acho que é assim que eu geralmente lidaria com esse tipo de configuração. Também podemos usar mandatory_values para garantir que certos grupos estejam sempre selecionados, para que você não acabe com apenas anonymous_users em alguns lugares. Ou usar validações de configuração para dizer “você não pode escolher anonymous_users sem pelo menos um grupo de usuários autenticados”, e assim por diante.
Não entendo por que isso é necessário. Qual é o problema em ser uma opção?
Isso funciona apenas para configurações do site, ou também para componentes de tema?
Ainda não funciona para componentes de tema, mas poderia. De novo, estamos realmente adiantando demais a conversa aqui.