Desativar a exigência de e-mail de ativação para usuários convidados

Olá pessoal, tenho um caso de uso que atualmente não é muito bem suportado: preciso desativar o e-mail de ativação para usuários convidados — incluindo usuários convidados por meio de um link.

Depois que criei o tópico acima, isso foi implementado, mas apenas para usuários convidados por e-mail.

Minha instância do Discourse é apenas por convite e, na verdade, estou enviando links de convite por e-mail, mas não os e-mails nativos do Discourse. Gero os links de convite com uma requisição POST para /invites/link e os armazeno em um banco de dados externo; a partir daí, envio os links ao usuário. Assim, quando os usuários clicam no link, eles já verificaram seu e-mail, mas são solicitados a fazer isso novamente.

Percebo que meu caso de uso não é muito comum, então pensei em tentar criar um plugin simples para modificar as partes necessárias do Discourse e fazer isso funcionar como preciso.

Já tenho um esqueleto funcionando e adicionei uma configuração do site (no_activation_enabled). Depois de pesquisar no repositório principal, acho que este pode ser o arquivo que precisa ser editado:

Não tenho certeza total, mas acho que talvez alterando condicionalmente (se SiteSetting.no_activation_enabled for verdadeiro e se o usuário foi convidado por um membro da equipe, talvez invite.invited_by.staff?) o valor de active para true em user.attributes possa funcionar:

    user.attributes = {
      email: invite.email,
      username: available_username,
      name: name || available_username,
      active: false,
      trust_level: SiteSetting.default_invitee_trust_level,
      ip_address: ip_address,
      registration_ip_address: ip_address
    }

Mas como faço para alterar isso a partir de um plugin? Isso está mesmo no escopo do que os plugins podem fazer? Ou eles só podem adicionar coisas, não modificar? Ou preciso substituir todo o arquivo invite_redeemer.rb?

Concluí a introdução à criação de plugins, além deste guia, mas depois de horas tentando explorar a base de código, incluindo outros plugins, sinto que estou batendo a cabeça na parede… Então, se alguém tiver alguma orientação para mim, ficaria super grato!

Se você está lidando com isso a partir de um site externo, por que não fazer com que ele gerencie o SSO e simplesmente passe a verificação no payload?

Olá Stephen, obrigado pelo seu feedback.

Não gerencio contas de usuários em um site externo. Tenho um Airtable principal integrado ao Zapier e a GCFs que conectam vários serviços (como ESPs, etc.), mas o Discourse é o principal banco de dados de usuários. Apenas não quero usar o formulário de cadastro padrão do Discourse, pois ele não é ideal para conversão e não pode ser integrado, por exemplo, em posts de blog. Na verdade, o Discourse atua como provedor de SSO para o site de conteúdo baseado em Jekyll, enviando solicitações fetch para verificar se um usuário está logado no Discourse e ajustando as páginas de conteúdo com base nisso.

Ei, bem-vindo :slight_smile:

Assim como o @Stephen, não tenho certeza absoluta de que esta é a ferramenta certa, mas confio que você analisou bem a situação.

Eu evitaria isso a todo custo. Quase sempre existe outra solução, mesmo que seja necessário fazer um monkey patch em uma classe. Sobre monkey patching no Discourse, veja: Override existing Discourse methods in plugins.

Neste caso, parece que já há código no método que você está analisando que faz exatamente o que você deseja: discourse/app/models/invite_redeemer.rb at main · discourse/discourse · GitHub

O problema é que os convites que você gerou não possuem o emailed_status_type correto, então essa condição não está sendo satisfeita. Acredito que a solução aqui seja gerar convites diferentes desde o início. É nisso que eu focaria.

Isso é essencialmente reintroduzir um recurso que foi removido do núcleo por ser muito perigoso — se você manusear incorretamente esses tokens de convite, qualquer pessoa que os roubar (antes de o destinatário pretendido usá-los) poderá entrar no fórum como o destinatário. Recomendo fortemente não usar esse tipo de convite para contas de moderador ou administrador.

É por isso que o código para lidar com isso já está lá, mas você precisará de algumas configurações personalizadas para realmente acessá-lo.