Notei que os campos de usuário personalizados são sempre visíveis para os usuários durante o cadastro ou em seus perfis, dependendo das configurações.
Atualmente, existe alguma maneira de criar um campo de usuário que seja visível e editável apenas pela equipe (para uso interno), não exposto aos usuários?
Se não, seria algo que a equipe poderia considerar dar suporte no futuro?
Existe uma solicitação de recurso para isso: Option to include user field that is only editable by staff
Dependendo do que você deseja usar o campo, pode ser suficiente ocultar o campo do usuário para todos, exceto para a equipe, com um componente de tema.
Eu executo o Discourse para cursos universitários, e o campo de usuário personalizado seria o número do aluno. Um componente de tema parece uma solução paliativa aceitável, mas tornar um campo personalizado completamente invisível para qualquer coisa além da equipe ou da API do sistema seria mais limpo.
Na verdade, eu me pergunto se a opção de ocultar o campo do usuário no cadastro, que foi adicionada recentemente, torna possível campos de usuário que os usuários não podem ver.
Eu acho que os campos de usuário só são mostrados aos usuários quando eles são editáveis. Portanto, se você o ocultar no cadastro e desabilitar a edição (e a exibição e a busca), o campo deverá ficar oculto para o usuário.
Agradeço muito sua ajuda anterior! Elaborei um relatório de bug mostrando esse comportamento claramente.
Olá, notei uma configuração no admin chamada “Campos personalizados de usuário da equipe”. Não tenho certeza do que é ou como usá-la.
Você poderia me ajudar a entender como isso funciona? Obrigado!
Até agora, eu não tinha caso de uso para usar campos personalizados através da API. Portanto, não posso dizer mais do que aprendi em
Dê uma olhada em Discourse User Notes - Plugin - Discourse Meta. Ele serve para a equipe compartilhar internamente notas sobre usuários. (Adora gatos – Joga golfe com o CEO – etc.)
@copymonopoly as sugestões de Moin e Toddz te ajudaram a resolver seu problema? FWIW, nós aqui no meta fazemos uso muito ativo de notas de usuário para compartilhar informações entre a equipe sobre nossos membros. Funciona bem (possivelmente melhor do que campos de usuário personalizados) porque as notas estão ao seu alcance:
Você também pode acessar notas de usuário via data explorer e provavelmente adicioná-las/acessá-las via API.
Eu também não tinha certeza sobre isso, mas encontrei algumas pistas…
Faz mais sentido ao lado da configuração complementar Campos personalizados de usuário públicos:
E eles têm a ver com quem pode acessar quais registros via API:
Curiosamente, os campos acima não parecem selecionar entre os campos personalizados de usuário disponíveis, mas aceitam qualquer entrada de texto – então você teria que digitar os nomes dos campos precisamente ler este documento cuidadosamente.
É o nome? Com base no documento que compartilhei acima, pensei que você precisava do ID
Ah, eu perdi esse documento! 
O campo aceitou o que quer que eu digitasse e eu fiz uma suposição errada.
Talvez seja um caso em que seria bom a descrição da configuração ter um link para a documentação.
Eu acho que o que seria 
seria ter uma pesquisa de campo personalizada para essas configurações de administrador que funcione de maneira semelhante à do Automação ‘adicionar usuário ao grupo através do Campo Personalizado do Usuário’:
Acho que foi mencionado anteriormente em algum lugar, mas não sei se ganhou alguma força.
Muito obrigado pela sugestão!
Originalmente, eu estava planejando usar campos de usuário personalizados porque queria escrever um pequeno componente que exibisse informações específicas que adiciono para cada usuário. Por isso, eu não tinha realmente considerado o plugin principal Discourse User Notes.
Mas parece que User Notes pode conseguir algo semelhante e pode ser uma abordagem útil. Agradeço muito a recomendação — estou atualmente analisando isso!
@hugh algum feedback para sua equipe. Os campos de entrada para as configurações do site campos personalizados de usuário público e campos personalizados de usuário da equipe aceitam qualquer coisa, mas apenas o ID funciona, o que é confuso.
