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

Notícias e Eventos Anúncios
44

Não, não era, e vimos isso surgir repetidamente, tanto internamente quanto externamente, e em toda a base de código.

Ainda não cheguei às categorias, nada mudou aqui.

As pessoas usavam esmagadoramente TL0 para significar “todos os usuários conectados” porque não tínhamos uma melhor maneira de representar isso. O grupo logged_in_users pelo menos é totalmente claro no que implica, e absolutamente nada impede você de continuar usando TL0/TL1 etc. O único grupo sendo removido é everyone.

Sim, claro, estou fazendo tudo isso apenas por “mudança pela mudança” :+1: Por favor, considere por um momento sua escolha de palavras, não temos o hábito de fazer coisas totalmente desnecessárias sem motivo aqui. Este trabalho está em andamento há meses e não está mudando de direção.

3 curtidas
45

OK, talvez eu esteja mal interpretando essa mudança?

Se a proposta for introduzir:

  • anon
  • logged in

como grupos automatizados

isso parece razoável e são autoexplicativos.

(De fato, eu gosto bastante disso! :+1:)

Porém, se a proposta for eventualmente remover:

  • everyone

isso não faz sentido para mim, pois “everyone” faz parte de um conjunto de grupos automatizados que representam níveis de acesso e que também incluem:

  • trust_level_0
  • trust_leve_1

etc.

todos eles representam níveis de acesso, incluindo “everyone”.

o grupo “everyone” é também conhecido como “trust_level_none”

é uma forma concisa de indicar acesso público.

Entendo que você não está propondo removê-lo para as permissões de Categoria por enquanto (:+1:), mas pessoalmente eu gostaria de ver um compromisso de manter esse grupo automatizado, pois, pelo menos para mim, ele faz sentido.

e então, por que não permitir que ele seja usado em outros lugares, assim como qualquer outro grupo automatizado de nível de confiança?

caso contrário, em todos os lugares onde for necessário expressar algo com “acesso público”, você terá que adicionar dois grupos, o que parece uma complexidade desnecessária?

por que se dar ao trabalho de adicionar lógica para “ocultar” “everyone”?

talvez outra abordagem alternativa seja reconsiderar o nome “everyone”, caso exista um nome melhor, mas mantendo seu significado, funcionalidade e disponibilidade em toda a plataforma, e então todos (tosse) ficarão felizes?

46

Acho que a distinção aqui está entre manter uma forma conveniente de selecionar “acesso público” e manter o grupo everyone existente. Concordo que ter que selecionar dois grupos toda vez que se deseja acesso público é mais trabalhoso, e podemos melhorar isso com a interface.

Por exemplo, poderíamos adicionar um atalho “Público” no seletor de grupos que selecione tanto anonymous_users quanto logged_in_users em uma única ação. Você então veria ambos os grupos selecionados e poderia remover qualquer um deles. Isso daria a conveniência que você está descrevendo, mantendo as permissões subjacentes explícitas. Ofereceríamos esse atalho apenas onde ambos os grupos são permitidos.

O problema com a manutenção do grupo everyone existente é que ele não significou consistentemente “acesso público”. Para a visibilidade de categorias, sim, mas para a maioria das configurações do site baseadas em grupos, ele significou efetivamente “todos os usuários conectados”. Há também temas e plugins que o interpretam de forma diferente, como a discussão acima mostrou.

Portanto, não podemos simplesmente mantê-lo e dizer que inclui usuários anônimos em todos os lugares sem potencialmente conceder acesso que não existia antes. Manter seu comportamento atual preservaria a inconsistência, e renomeá-lo também não resolveria isso.

Um grupo universal consistentemente definido seria possível, mas ainda exigiria a migração e a auditoria que estamos fazendo agora. Ele também precisaria ser proibido em qualquer lugar onde o acesso anônimo não seja suportado, caso contrário, voltaríamos ao “everyone” significando “apenas usuários conectados” nesses locais. Há uma tonelada de configurações em que tive que adicionar anonymous_users como valor de disallowed_groups onde antes não era, e antes everyone era permitido nessas configurações. Por exemplo:

Eu preferiria fornecer essa conveniência na interface, usando os dois grupos explícitos por baixo, assim teremos consistência em todos os lugares para administradores e desenvolvedores.

2 curtidas