Foi adicionada uma nova configuração de opção chamada invite_code.
Quando definida, todas as contas em registro devem inserir o código de convite para que a criação da conta seja permitida. Usuários sem esse código não podem registrar uma conta.
Isso requer moderação manual de cada conta. Essa configuração é realmente muito útil para quem deseja testar com alguns usuários ou para quem está promovendo alguma ação onde o acesso ao fórum é um benefício. Um código de convite assim reduzirá drasticamente a carga de trabalho em fóruns de projetos piloto também.
Porque preciso aprovar cada e-mail individualmente e ficar na fila de aprovação 24 horas por dia, 7 dias por semana, e não tenho ideia se se trata de um bot aleatório que se registrou ou de alguém que realmente deveria ter acesso.
Com um código de convite, sei que, pelo menos, eles tinham um código de convite que compartilhei de forma privada.
+1 por essa funcionalidade, que é extremamente útil para várias comunidades que administro. Entendo o ponto do @codinghorror e do @ondrej sobre a aprovação manual mencionado acima, mas acredito que isso preenche uma lacuna que existe entre convidar manualmente todos (site apenas por convite) e aprovar manualmente todos (site com aprovação de usuários).
Não queremos aprovar usuários. Apenas queremos publicar um código em um grupo do Slack/Telegram/WhatsApp e deixar que todos o utilizem. Às vezes, alguns testadores extras antes do lançamento formal não fazem mal algum.
Eu também acho isso muito útil, especialmente se a funcionalidade for ligeiramente estendida para permitir “vincular” grupos a um código de convite específico, ou seja, alguém que cria uma conta usando um código específico é automaticamente adicionado a um grupo específico.
Em alguns casos de uso, isso também pode atender à solicitação de tokens de convite independentes de e-mail, que surge de vez em quando…
Sou fã disso em formas um pouco diferentes, só precisa de alguns ajustes. Se há uma necessidade urgente (?) disso agora, então imagino que esteja tudo bem?
Apenas não sinto pessoalmente que a mágica domínio …
por favor, inscreva-se em https://forum.this-is-my-magic-domain.org
seja um nível de proteção de inscrição completamente inutilizável e totalmente inviável, comparado à mágica senha …
você deve conhecer o segredo this-is-my-magic-password para acessar este site
Existem duas formas disso que estou super feliz em apoiar:
Por favor, visite amazing.forum.com e insira o código de convite: fantastic para obter acesso (implementado)
E
Por favor, visite amazing.forum.com/register?code=fantastic para se registrar e obter acesso ao fórum
Provavelmente já ultrapassamos a regra do 100 aqui, considerando que nossa maneira geral de resolver esse problema é colocar sites atrás de autenticação básica HTTP.
Ambas são bastante semelhantes; implementei a #1 por enquanto, mas darei sequência com a #2.
A #1 tem a vantagem de ser um pouco mais fácil quando você não está dependendo de copiar e colar, por exemplo, receber instruções pelo WhatsApp e depois usar o desktop para concluir.
A #2 tem a vantagem de reduzir a digitação de fantastic e é prática para um compartilhamento por “e-mail” versus um compartilhamento pelo WhatsApp.
Não está entendendo de onde veio forum.this-magic-domain.org aqui? Em ambos os casos, este é exatamente o mesmo domínio em que o fórum está hospedado.
(Isso está em um site de desenvolvimento com must_approve_users ativado, após a validação por e-mail)
Deve ser opcional no cadastro e opcional no login enquanto não aprovado, pois qualquer coisa que exija que todos os usuários consigam copiar o código vai quebrar e exigir intervenção do administrador.
Percebo agora que acabei de reiterar acidentalmente os pontos de @codinghorror do tópico anterior. (o que eu não havia lido no momento da escrita, pois isso estava em #feature:announcements)
Essencialmente, isso deve ser construído sobre must_approve_users + login_required, em vez de criar um sistema totalmente paralelo. A implementação atual está boa como uma solução paliativa para nos levar através da crise atual, mas deve ser corrigida.
Alguém vai esquecer o código ou não anotá-lo se você o apresentar em uma conferência. Ou você precisará atualizar o código depois que os vídeos da conferência forem publicados. É muito melhor perguntar no seu grupo do WhatsApp “de quem é a conta @test3?”, obter uma resposta afirmativa e clicar
Acho que está tudo bem, só precisamos chegar aos ajustes finais. Definitivamente há algumas melhorias que apoio totalmente aqui.
Primeiro, integração com a página de convites de usuários, por exemplo: se você se cadastrar no Meta acessando o link https://meta.discourse.org/signup?u=codinghorror, você aparecerá como alguém que eu convidei na minha página de perfil de usuário, assim:
Lembre-se de que convites baseados em e-mail já concedem o nível TL1 aos usuários que você convidou… então já temos esse benefício… veja a caixa de diálogo de convite… note que você também pode adicionar acesso a grupos, e o aumento do TL é implícito. Provavelmente deveríamos explicar isso claramente no texto desta caixa de diálogo, na verdade:
Segundo, você deve poder gerar links de convite sem e-mail no mesmo local onde envia convites, conforme mencionado acima … isso resolve completamente o problema de “mas eu não sei os endereços de e-mail deles ”.
Terceiro, acho que está tudo bem para um site ser “apenas por convite” e os convites sejam todos na forma de hiperlinks mais uma senha secreta. Dessa forma, é:
algo que você tem (por exemplo, um link para o site)
algo que você sabe (por exemplo, a senha abre-te sésamo)
E se seu site tiver aprovações, a senha secreta permite que você pule a aprovação também. Se você não tiver aprovações, não consegue entrar sem a senha secreta…
Meu principal problema é que não estamos integrando com os recursos existentes aqui, apenas adicionando coisas aleatórias através de uma configuração de site obscura. Mas podemos integrar, para tornar o recurso de convite ainda melhor, em vez de ser uma configuração de site isolada e estranha.