Quando um novo usuário entra através de um link de convite, percebo que também preciso aprovar o usuário no momento.
Isso anula todo o propósito de um convite; eu poderia muito bem apenas enviar o link para o fórum.
Tentei isso para uma variedade de situações (link novo, link antigo, uma pessoa, várias) em mais de uma instância, e é o mesmo.
Tenho /admin/site_settings/category/all_results?filter=must_approve_users como TRUE nessas instâncias. Parece que está levando um pouco literal demais! Eu quero apenas precisar aprovar aqueles que estão entrando sem um convite, que é como as coisas costumavam operar.
Pensei que um convite da equipe fosse aprovação explícita - especialmente se incluísse o endereço de e-mail do usuário!
Com um convite aberto, há, é claro, muitas oportunidades para abusar do link. Mas o membro da equipe tem que configurar deliberadamente o link para permitir isso e pode assumir a responsabilidade por (e limitar) esse risco com bastante facilidade.
Isso também significa que as pessoas que descobrem meu site não podem entrar e são excluídas, a menos que consigam encontrar alguém para convidá-las. Isso é péssimo.
Sugestão
Que tal adicionar duas opções em /admin/site_settings/category/all_results?filter=must_approve_users?
A equipe deve aprovar TODOS os usuários
A menos que convidados pela equipe, os usuários devem ser aprovados
Apenas registros públicos exigem aprovação da equipe
Foi, mas o comportamento foi alterado há cerca de um mês:
Temos uma instância usada por uma instituição de caridade/sindicato para treinamento de habilidades que foi impactada de forma semelhante.
Antes da mudança, a equipe convidava usuários para pular a aprovação, agora eles precisam fazer ambos. Com a necessidade de voltar e verificar cada aprovação em relação às listas de membros, isso aumentou substancialmente sua sobrecarga administrativa.
Sim… acho que a solução de longo prazo é adicionar uma configuração de site que permita o modo de aprovação flexível, opcional.
No entanto, me preocupo, pois acertar a segurança aqui é muito, muito difícil. Quanto mais casos extremos permitirmos, maior a complexidade e potenciais falhas de segurança.
Eu me pergunto se o principal caso extremo é apenas permitir que a configuração do usuário que deve aprovar seja substituída se o convite tiver um endereço de e-mail específico nele, e manter a configuração do usuário que deve aprovar para os links de convite anônimos — mas pode ser mais complexo no back-end para fazer isso do que eu imagino.
Isso faz sentido para mim, especialmente se o convite foi para um endereço de e-mail específico E foi enviado pela equipe. Não imagino que um segundo nível de aprovação seria necessário nesse cenário.
Que tal permitir que apenas os administradores definam uma flag “aprovar automaticamente” e, opcionalmente, limitá-la a “e-mail inalterado” ou “restrito a um” ou algo assim? No meu caso, eu ficaria até feliz com um convite por linha de comando que possa criar esses convites especiais pré-aprovados, existe algo assim disponível?
Como uma solução alternativa precária, fiz o que Sam sugeriu:
Espalhei generosamente um convite para o nosso Fórum, e isso funciona bem.
O problema são os ‘visitantes’ que tropeçam no site através de uma pesquisa no Google ou similar. Eles têm que enviar um e-mail para obter um link de adesão, o que é uma grande dor para o administrador.
A sugestão de Arman é bastante simples e não acho que seria muito difícil de implementar (ou ser falha):
No momento, isso simplesmente não é o caso se must_approve_users for TRUE:
Cada vez que temos um grupo de pessoas para convidar, ou aceitamos muito atrito (a etapa de aprovação) ou temos que reconfigurar o site temporariamente (e fechá-lo para registros públicos), o que é bastante doloroso.
Olá, gostaria também de solicitar que haja um recurso para que os convites da equipe ignorem a etapa de aprovação, talvez por um booleano opcional na caixa de diálogo de geração de convite.
Atualmente, o “Compartilhe este link para conceder acesso instantâneo ao site” simplesmente não é verdade para sites que têm must_approve_users.
Para recapitular, esta solicitação é para que a equipe em um site must_approve_users possa criar um link de convite que ignorará a etapa de aprovação. Embora o site que administro exija aprovação, às vezes gostaríamos de poder ‘pré-aprovar’ usuários por meio de um link de convite que sabemos que será compartilhado privadamente com indivíduos confiáveis, ou quando compartilhamos o link em um evento físico relacionado à comunidade do fórum. (Não necessariamente sabemos os endereços de e-mail preferidos de tais convidados, então não podemos usar um convite em massa)
Com nossos sites must_approve_users (grandes o suficiente), isso continua sendo uma grande dor de cabeça sempre que realizamos um evento físico.
O problema é que não podemos simplesmente dar às pessoas um belo código QR, convite ou link para acessar diretamente nossa instância. Pelo menos não sem uma solução alternativa um tanto feia.
A solução alternativa e seus problemas
Desativar must_approve_users e tornar o site invite_only não é realmente satisfatório, pois:
Muitas pessoas parecem estragar qualquer processo de convite e tentam entrar pela “porta da frente” (agora bloqueada).
O burburinho criado pelo evento geralmente se espalha para não convidados também - mas eles também não podem solicitar participação.
O estado atual desde a mudança definitivamente tornou as coisas muito mais difíceis. A instituição de caridade de treinamento de habilidades com a qual trabalhei, que foi a mais impactada, optou por fechar sua comunidade várias semanas depois.
É muito overhead administrativo adicional quando centenas de pessoas entram e saem a cada semana.
Obrigado por trazer isso à tona novamente. Acho que estamos na terceira vez que alguma correção é necessária para tornar o convite mais fácil e contínuo. O sistema de convite provou ser complicado de mudar porque todo mundo parece estar usando-o de maneiras diferentes. Queremos ter diretrizes claras e tentar evitar quebrar o fluxo de trabalho deles.
Vou verificar com a equipe e ver o que podemos gerenciar.
Isso é novidade para mim, vamos analisar isso separadamente.
Nossa preocupação é que os sites possam ser configurados de várias maneiras e, em seguida, esperar que o sistema de convites funcione de maneiras diferentes também. A segurança é uma preocupação muito real. Portanto, tomaremos cuidado ao fazer quaisquer outras alterações no sistema de convites.
Minha opinião pessoal é que a seguinte abordagem seria a melhor, porque não depende de uma configuração de administrador e torna o comportamento cristalino diretamente no modal de convite. Seria difícil até mesmo para alguém completamente novo no Discourse criar e compartilhar acidentalmente um link de convite que faça algo que ele não espera. O que todos vocês acham?
Quando a configuração de administrador deve aprovar usuários estiver habilitada
Um alternador é exibido para a equipe no modal de convite para criar um convite que ignore o requisito de aprovação. Ex: [ ] Não exigir aprovação da equipe
Convites resgatados quando o alternador em (2) é selecionado permitem que o usuário entre no site sem exigir aprovação
A suposição é que apenas a equipe deve ter acesso a este alternador, porque a intenção da configuração deve aprovar usuários é dar à equipe controle sobre quem pode ingressar na comunidade.
Se houver demanda suficiente, poderíamos considerar mais tarde adicionar uma configuração de administrador para determinar quem tem acesso a este recurso por grupo.
Sam chegou a se referir à mudança como surpreendentemente complexa. Não duvido dele.
O esforço agregado da mudança original e mais esta será obviamente maior do que se isso tivesse sido considerado desde o início. Estabelecemos na época que, embora uma comunidade achasse o padrão atual objetável, havia várias comunidades que dependiam desse comportamento. Por exemplo, a união que abandonou seu site de treinamento de habilidades baseado em Discourse não tomou a decisão levianamente, mas era impraticável para eles continuarem assim que os formandos convidados pela equipe se perdessem na piscina geral de aprovação.
Se o problema aqui foi a falta de compreensão explícita, então provavelmente precisa haver um passo intermediário entre deve aprovar usuários e o modal de convite que oferece a opção para convites de equipe ignorarem a aprovação, caso contrário, a reclamação original que levou a essa mudança ainda pode surgir.
Então, mais como:
Quando a configuração de administrador deve aprovar usuários estiver habilitada e um novo convites de equipe ignoram aprovação for alterado de seu padrão nunca:
Se sempre, o comportamento antigo entrará em vigor
Se opcional, exiba o interruptor no modal para dar a opção de ignorar a aprovação subsequente
Sem o intermediário, os administradores não estão totalmente cientes das implicações de “deve aprovar”, e um pouco de granularidade resolverá o outro problema ao esquecer de usar o alternador.
Acredito que isso funcionaria muito bem (talvez com o ajuste de @Stephen também) - e adoro que seja uma abordagem centrada nas pessoas que não quebraria nada, pois deixaria a maquinaria padrão completamente intacta.
Um caso extremo de altíssima importância para mim, no entanto, seriam os convites de e-mail automáticos relacionados a convites de grupo. Isso permite que as pessoas sejam adicionadas a um grupo OU enviadas um convite, dependendo se já estão cadastradas por meio de um único ato administrativo. Pessoalmente, eu realmente precisaria que isso fosse coberto de alguma forma também.
