Eu dei um contexto sobre o caso de uso em Restrict exposure of full name to certain groups. Estamos usando o Discourse para facilitar a discussão sobre o sistema de ensino público local; a base de usuários alvo é composta principalmente por pais e outros membros da comunidade local. Queremos encontrar um equilíbrio:
Por um lado, tornar o site aberto à navegação anônima (para que os motores de busca possam indexá-lo, para que seja acessível mesmo para não membros, para que seja aberto/transparente por princípio, …)
Por outro lado, evitar tornar desnecessariamente informações pessoalmente identificáveis disponíveis para rastreadores e visitantes não membros — queremos permitir que as pessoas compartilhem seus nomes dentro da comunidade e queremos lidar com a cautela que muitas pessoas têm ao fazer isso.
Originalmente, parecia que desabilitar “Exibir nome nas postagens” e habilitar “Ocultar perfis de usuário do público” cuidaria de bloquear vazamentos de nomes para usuários anônimos — mas então percebemos que não. (E já prometemos às pessoas via TOS e FAQ que faríamos isso. )
Negar o acesso ao nome completo apenas a usuários anônimos resolveria o problema. Mas, como é realmente tão fácil vincular o acesso à associação de grupo, acho que também poderia fazer isso — o que abre a possibilidade, em nosso site, de restringir o acesso a >=TL1, o que é ainda melhor. (Atualmente, exigimos um convite para se inscrever, mas queremos nos livrar disso.)
Ao investigar esse problema/tópico, vi outras menções de solicitações iguais ou semelhantes, por exemplo, “queremos que apenas o grupo X possa ver nomes”… então isso também resolveria esses casos.
Uma pergunta para você (que você pode até considerar uma pergunta de produto!):
A configuração enable_names tem a intenção de significar “Não mostrar nomes completos aos usuários.” ou “Este site não usa nomes completos, ponto final.”?
Tenho a sensação (pelo próprio código e por tópicos/problemas como este) de que há uma falta de clareza subjacente sobre este ponto — e algumas pessoas entenderam de uma maneira e outras de outra.
Concordo. Os administradores devem poder acessar o Nome Completo sem precisar ativar e desativar a alternância. Existem razões particularmente importantes (pelo menos para o nosso fórum) para ocultar nomes reais.
Agradeço a todos que contribuíram para este tópico. Gostaria apenas de perguntar respeitosamente se este problema será resolvido em uma versão futura—ou pelo menos reconhecido como uma regressão conhecida.
Desabilitar a opção de ativar nomes atualmente quebra funcionalidades importantes de administração de uma forma que parece não intencional, e a falta de clareza sobre se isso é por design ou um bug está dificultando nosso planejamento. Para aqueles de nós que executam sites de produção onde nomes de usuário são preferidos em vez de nomes completos, essa limitação introduz atrito real e comportamento inesperado.
Eu entendo que as prioridades precisam ser equilibradas, mas seria incrivelmente útil receber uma atualização da equipe sobre se isso está no radar. Agradeço antecipadamente por qualquer informação que possa fornecer.
Ei, @tobiaseigen, alguma contribuição de engenharia sobre isso? (Já se passaram 3 meses — mas eu também estava ocupado com outras coisas e perdi o controle disso, então não posso reclamar.)
Eu poderia começar a enviar pull request(s) esta semana para tornar a conversa mais concreta — mas estou receoso de que eles fiquem sem revisão, e eu também poderia usar algum feedback sobre alguns aspectos da minha abordagem.
@RGJ@chrismalone e @mdoggydog Muito obrigado pela contribuição de vocês. Continuamos precisando dessa correção e gratos a todos que estão trabalhando no problema.
Sim, para ser sincero, estou surpreso que isso não tenha tido mais atenção. Eu entendo ser cauteloso em fazer um PR sem saber se ele será revisado e potencialmente implementado.
Embora um PR eu imagine que talvez pudesse se tornar um plugin, mas isso limita mais essa opção a auto-hospedagem.
@mdoggydog Parece que sua solução aqui é substituir a configuração enable names por uma que aceite uma lista de grupos, e os nomes dos membros só são visíveis para esses grupos.
Note que isso ainda precisaria respeitar a configuração display name on posts (e quaisquer outras semelhantes que possam existir), então, mesmo grupos permitidos não veem o nome nas postagens se essa configuração estiver desativada.
Além disso, algumas outras coisas que precisamos corrigir/alterar aqui como efeitos colaterais:
Os nomes devem sempre ser visíveis na visualização de administrador de um perfil de usuário. Este será o caso, independentemente de quaisquer configurações.
Os nomes só devem ser exibidos em e-mails se o usuário estiver em um grupo permitido.
O acima deve corrigir os problemas atuais, bem como tornar este recurso mais flexível e útil.
Isso soa como o que você está propondo aqui? Se sim, ficaríamos definitivamente felizes em dar uma olhada em qualquer PR que você enviar com esta atualização incluída.
O código que escrevi não remove a configuração enable names,[1] mas adiciona a ela:
Adicionar uma configuração full_names_visible_to_groups (que inclui admins e moderators como valores obrigatórios).
Adicionar um método can_see_full_names? ao Guardian, que realiza um “E” de enable_names e a associação de grupo em full_names_visible_to_groups.
Usar este novo método em todos os locais apropriados onde um nome completo é exposto/emitido pelo servidor.
1 e 2 foram fáceis. 3 é mais complicado, e sei que encontrei alguns obstáculos que não tinha certeza de como resolver sem obter conselhos/orientação. Preciso voltar e revisar meu código e minhas anotações em profundidade. (Já se passaram mais de 2 meses desde que me aprofundei nisso. )
(Se me lembro bem, display name on posts e similares são configurações do lado do cliente, que afetam a apresentação dos dados recebidos do servidor. Em outras palavras, uma restrição sobre o que o servidor emite.)
Acredito que (1) é tratado se enable_names for verdadeiro, o que provavelmente será o que quase todo mundo quer assim que a nova configuração por grupo estiver disponível.[2]
Acho que encontrei e lidei com (2) — na maior parte.[3]
Lembro-me de alguns outros casos em que nomes completos estão sendo vazados.[4]
De qualquer forma, revisarei minhas anotações e tentarei enviar PRs esta semana, e desenterrar as perguntas abertas/pontas soltas no processo.
…por uma série de razões, entre elas: (a) eu não tinha certeza de qual era a intenção real da configuração (veja minha pergunta em uma postagem anterior acima) e (b) mantê-la oferece um caminho de atualização incremental mais seguro. ↩︎
…se considerarmos que enable_names = false significa “Este site não usa nomes completos de forma alguma.” ↩︎
Por exemplo, quando um e-mail de convite é enviado para algum endereço (obviamente não associado a um usuário, caso contrário, eles não precisariam de convite), o e-mail inclui o nome completo de quem convidou ou não? ↩︎
Por exemplo, oneboxer.rb, ao fazer um onebox de um usuário local, escreve o nome completo no conteúdo da postagem cozida, o que o torna visível para todos e qualquer pessoa, para sempre. ↩︎
Este PR é um pré-requisito para os subsequentes, garantindo que as instâncias de Guardian sejam realmente passadas de um serializador para o próximo. Os detalhes estão no PR/mensagem de commit. A conversa sobre este PR pode muito bem começar enquanto preparo o próximo.
Minha Aventura Mini na Conta do GitHub
…bem, estava lá até eu digitar a URL na caixa de edição aqui… e então toda a minha conta foi subitamente suspensa.
Eu solicitei a reativação e atualizarei quando tiver uma atualização.
13 horas depois, recebi um e-mail que dizia, basicamente: “Às vezes isso acontece; tudo bem agora.” Muito Kafkaesco. Minha conta desapareceu do site — a ponto de posts que eu fiz em Issues/PRs anos atrás terem sumido, deixando para trás conversas misteriosas unilaterais, com alguns blocos de citação fantasmagóricos como única evidência de que outra pessoa (eu) esteve lá.
Isso parece horrivelmente pesado, não apenas para a conta suspensa, mas também para todos os projetos que tiveram partes de sua história silenciosamente removidas.
Estou percebendo que isso envolverá a coordenação de mudanças nos repositórios de plugins do Discourse também — o que significa uma cadeia de PRs, em uma espécie de ordem de dentro para fora, para garantir que os testes sempre passem (e, claro, que main esteja sempre funcional).
Imagino que a sequência seria assim (onde CORE significa “PR em discourse/discourse” e PLUG significa “PR(s) em repositórios de plugins oficiais”):
Impor o encaminhamento do escopo do serializador (nenhuma mudança funcional esperada)
a. CORE Implementar a verificação do escopo do serializador, desativada por padrão
b. PLUG Correções para o encaminhamento do escopo
c. CORE Correções para o encaminhamento do escopo e ativar a verificação do escopo por padrão
Fornecer preventivamente Guardians (substituindo espaços reservados) nos locais necessários para a Fase 4 (nenhuma mudança funcional esperada)
CORE Correções de espaços reservados
PLUG Correções de espaços reservados
Implementar Guardian#can_see_full_names? simples que depende apenas de enable_names(nenhuma mudança funcional esperada)
CORE Adicionar método ao Guardian
Usar can_see_full_names? onde o nome completo é emitido (substituindo o uso direto de enable_names conforme apropriado) (pode ter mudança funcional)
CORE usar o novo método Guardian
PLUG usar o novo método Guardian
Implementar a configuração full_names_visible_to_groups(mudança funcional)
CORE Adicionar nova configuração ao config e verificar a configuração no método Guardian
(1) e (2) se resumem a garantir que os Guardians sejam usados de forma mais consistente e confiável em todo o código-fonte do Discourse.
(3) e (4) são sobre instituir uma abstração mais precisa para controlar quando os nomes completos são expostos pelo backend (decidindo sobre a exposição dependendo de qualquer contexto que o Guardian represente).
(5) é finalmente a parte (relativamente trivial) onde a exposição do nome completo é controlada pela associação ao grupo.
Lamento, mas tenho que rejeitar este PR. Essa mudança é muito complexa e difícil de manter. As principais razões são:
O escopo nem sempre é necessário e não deve ser imposto;
Alterar e, posteriormente, manter isso em todos os lugares, como plugins, seria uma quantidade enorme de trabalho;
PlaceholderGuarian não está resolvendo o problema, mas adicionando um escopo falso (com a intenção de corrigir mais tarde);
Na maioria das vezes, a serialização deve ocorrer no controller, e o escopo será adicionado automaticamente.
Exibir um nome de usuário ou nome completo com base no grupo é bastante complicado. Em vez de tentar mesclar isso no core do Discourse, podemos começar criando um plugin? Se sua comunidade for pequena, é assim que pode funcionar:
Defina SiteSetting.enable_names como false para sempre usar o nome de usuário;
Defina um endpoint que retorne um mapa de nome de usuário → nome completo para usuários TL3;
Terminei um PR resolvendo o problema original. O administrador sempre poderá ver o nome completo e editá-lo. Tentaremos mesclá-lo no início da próxima semana
Acho que ainda há um mal-entendido/desacordo fundamental sobre o que exatamente a configuração enable_names deveria fazer, o que se resume a esta questão:
A configuração enable_names tem a intenção de significar
“Não mostre nomes completos publicamente.”,
“Este site não usa nomes completos, ponto final.”
Acho que algumas pessoas neste tópico pensam que significa (1), e outras pensam que significa (2). Minha impressão é a última, que enable_names decide se o site usa ou não nomes completos.
Tenha em mente que, quando enable_names está desativado:
A caixa de diálogo de inscrição não oferece o campo de nome completo.
Os usuários não veem o campo de nome completo em sua própria página de preferências de conta; os usuários nunca veem seu próprio nome completo em lugar nenhum.
Não entendo o caso de uso para um site em que administradores, e apenas administradores, são as únicas pessoas que sabem que um campo de nome completo existe no sistema. Minha falta de imaginação me deixa cético de que alguém aqui realmente queira isso. Se alguém quiser isso, por favor, me ilumine!
(Acho que também há algum mal-entendido sobre o que meu PR draft está tentando realizar, e como, e por quê — mas eu queria abordar primeiro a questão “O que enable_names realmente faz?”)
Sim, posso citar inúmeros exemplos. Muitas vezes, a empresa dona da comunidade tem o direito legal (e/ou a necessidade) de conhecer os nomes de seus clientes, mas as leis de privacidade a proíbem de publicar esses nomes para terceiros. É praticamente a mesma coisa que usar CCO em um e-mail em massa é um erro e você deveria usar CCO.
Bem, isso começou como um relatório de bug bastante simples em que ele simplesmente se comportou mal. E então todos nós entramos em uma discussão sobre o que deveria fazer, o que também causou muita confusão e discussão extra. O que é bom, mas teria sido melhor em um tópico de Feature.
É o #1. A descrição da configuração diz:
Mostre o nome completo do usuário em seu perfil, cartão de usuário e e-mails. Desative para ocultar o nome completo em todos os lugares.
O fato de o nome completo estar oculto implica que ele existe, e os administradores podem ver coisas ocultas.
Há também display_name_on_posts, full_name_requirement e display_name_on_email_from.
Se você quiser o #2, acho que faria mais sentido construir sobre full_name_requirement e adicionar uma opção ‘Nunca’ lá.
(E sim, concordo que enable_names deveria ter um nome diferente, mas renomear configurações nunca é divertido). E também concordo que
Isso corrigirá a função original? Ou seja, o administrador e o usuário podem ver o nome completo deles? Parece que essa mudança inicialmente causou muitos problemas em comparação com a função original. Mesmo o moderador completo deveria ter uma opção para ver o nome real através de uma configuração, pois em alguns casos de uso isso pode ser desejado/necessário.
Após a equipe implementar essa mudança, todos os usuários que haviam inserido o nome real ficaram em branco.
Essa configuração, na minha opinião, deveria ter sido separada em 2 configurações com definições claras. Com o recurso mais recente para desativar nomes sendo uma nova configuração para desativar nomes reais.
Tenho sorte por ter uma comunidade pequena. Imagine um site com milhares de membros cujos nomes reais foram apagados.
)
)
