Logins locais estão desativados (logins via Facebook e Google estão configurados)
A equipe deve aprovar todas as novas contas de usuário
Temos uma grande lista de e-mail e gostaríamos de “pré-aprovar” todos os endereços de e-mail nessa lista. Se uma pessoa acessar o site e tentar se cadastrar ou fazer login com uma conta do Facebook ou Google associada a um e-mail em nossa lista de pré-aprovação, ela não precisará esperar que um membro da equipe a aprove e poderá começar a usar o site imediatamente.
Idealmente, também gostaríamos de poder pré-configurar a associação a grupos por e-mail.
Isso é possível? Soluções que exigem o uso da API do Discourse são bem-vindas.
Tenho medo de que isso não vá funcionar de forma alguma!
Principalmente porque os convites não funcionam sem logins locais ativados. Então, você provavelmente estará olhando para um plugin muito personalizado que lidará com tudo isso ou um sistema de autenticação externo para atender aos seus requisitos.
Acho que, se você importar os endereços com um script de importação, a coisa certa vai acontecer. Você deve garantir que esses usuários não sejam marcados como ativos, a menos que queira arriscar inundá-los com notificações e resumos.
Isso deve ser razoavelmente fácil de fazer pelo console. Acredito que também possa ser feito via API, caso você esteja hospedado em algum lugar.
“Grande” significa cerca de 5.000 — o suficiente para que não queiramos digitar manualmente na interface em algum lugar.
@pfaffman, você poderia esclarecer um pouco como eu criaria os usuários via API? Parece que ‘password’ é um campo obrigatório para criar usuários, o que, supõe-se, não pode ser feito se o login local estiver desativado: POST /users
Para expandir um pouco o caso de uso, para outros que possam estar considerando algo semelhante: Queremos incentivar os usuários a fazer login com suas contas sociais — muitas das pessoas que estamos tentando engajar no Discourse não são experientes em tecnologia e queremos que saibam que não precisam gerenciar outro nome de usuário e senha.
No entanto, o recurso atual de convite por e-mail no Discourse exige que o usuário escolha uma senha, o que compromete nosso objetivo de manter as coisas simples para nossos usuários.
Talvez haja uma maneira diferente de alcançar nosso objetivo? Não me oponho a ativar o login local se for necessário, mas quero que os usuários convidados vejam claramente que podem fazer login com redes sociais e não precisam de senha alguma.
Obrigado a todos! Estou muito animado para ver mais pessoas usando o Discourse.
Permitir que não criem uma senha e exigir que informem qual endereço de e-mail usam com login social simplesmente não é a mesma coisa. Eles ainda podem pular a criação de senha se usarem login social. Eu frequentemente me recuso a fazer login com minha conta do Gmail (embora com menos frequência agora) e minha esposa quase sempre se recusa a fazer o mesmo. Além disso, o login por e-mail é muito útil e significa que você nunca precisa de uma senha. Mas estou me desviando do assunto.
Se a API exigir uma senha, basta gerar uma aleatória. Ter uma senha que você não conhece e não precisa é praticamente o mesmo que não ter senha.
Tenho que admitir que não percebi até uma inspeção mais detalhada que o campo de senha é opcional para usuários que aceitam convites por e-mail. Você tem um ponto válido de que os usuários devem poder escolher se querem usar um e-mail diferente e criar uma senha. Me sentiria muito mais seguro se a interface fosse mais clara sobre a senha ser opcional, especialmente quando o login social está habilitado no site. Com a interface atual, alguém precisaria realmente não querer criar uma senha para descobrir que isso não é estritamente obrigatório, na minha opinião. Acho que deveria me preparar e fazer um PR para melhorar a UX
Dê uma olhada no código de exemplo, obrigado! Pelo que vale, precisei usar essa “gambiarra” para fazer as chamadas de API apropriadas: Using the API to create a user on an SSO only system - #13 by DylannCordel - mesmo assim, não acho que isso atenda ao caso de uso que eu tinha em mente, pois ele dispara um e-mail para o usuário para ativação, o que eu esperava evitar em favor de uma experiência “simplesmente funciona” quando eles eventualmente fizerem login no site.
Também brinquei um pouco com essa solução: How to manually add user in discourse? - #10 - acho que funcionaria para “hackear” as contas de usuário que eu quero que existam usando esse método, mas, no final, não tenho certeza se vale o risco para mim modificar diretamente o ambiente dentro do container para fazer essas alterações.
Então, no geral, acho que o fluxo de trabalho que eu esperava não é realmente um fluxo de trabalho suportado/esperado, e terei que ficar bem com isso até que a interface seja melhorada (talvez) em algum momento.
Você está misturando algumas coisas diferentes aqui.
Os logins sociais pulam a senha, já que a autenticação é feita pelo Facebook, Twitter, Google, etc.
Os convites tornam a senha temporariamente opcional, mas você precisa seguir o link do convite novamente para “fazer login”. Acredito que isso foi restringido tanto que, na prática, não funciona mais. Você precisaria solicitar uma redefinição de senha por e-mail para entrar depois disso, o que exige definir uma senha.
É uma história longa, mas os convites foram criados para permitir que as pessoas entrem e respondam o mais rápido possível, com o mínimo de complicação. No entanto, eles NÃO foram feitos para permitir que as pessoas pulem a definição de senha para sempre.
Enviar um convite por e-mail para um usuário (o login local deve estar habilitado para que isso esteja disponível)
Quando o usuário clica no convite, ele pode deixar a senha em branco e ser logado imediatamente.
Na próxima vez que visitar o site e precisar fazer login, ele poderá usar uma conta social associada a esse e-mail.
Agora, é justo dizer que talvez isso não devesse funcionar e que meu comentário anterior sobre uma interface confusa seja, na verdade, um recurso e não um defeito, projetado para desencorajar as pessoas a usarem essa solução alternativa. Dito isso, parece ser um caminho aceitável para um usuário que foi convidado por e-mail, mas que, no final das contas, não quer criar uma senha e prefere os outros benefícios do login social (ou seja, copiar sua foto de perfil).
Entendo perfeitamente o ponto anterior de que alguns usuários preferem ativamente ter uma senha em vez de usar o login social, e estou convencido de que não devo desativar isso para quem deseja essa opção. Ainda espero, no entanto, um caminho fácil e claro para convidar ou configurar usuários que preferem não ter uma senha.
