Isso parece ocorrer apenas se o e-mail for alterado. Por exemplo,
https://forum.{mySite}.com/u/{user}/preferences/email
Modelo do link do e-mail de confirmação:
%{base_url}/u/authorize-email/%{email_token}
Link real do e-mail de confirmação:
https://forum.{mySite}.com/u/authorize-email/{someHash}
Você consegue reproduzir isso, @tshenry?
Aconteceu com a gente também essa semana, exatamente como descrito acima.
Você provavelmente personalizou esse e-mail antes de alterarmos o link.
Por favor, vá para /admin/customize/email_templates/user_notifications.confirm_new_email e verifique se o link ali está assim:
%{base_url}/u/confirm-new-email/%{email_token}
em vez de
%{base_url}/u/authorize-email/%{email_token}
Pode ser uma boa ideia adicionar uma migração, afinal. Isso já foi levantado várias vezes.
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
Isso resolveu o link quebrado… mais ou menos; agora, ele apenas redireciona o usuário para a tela de login.
Embora seja bom que isso tenha vindo à minha atenção para garantir que as pessoas possam alterar seu e-mail, por que não há uma maneira para um administrador editar o e-mail no painel de administração? A única opção era assumir a identidade do usuário > perfil > alterar e-mail? Foi isso que li, de qualquer forma — é realmente a maneira correta de fazer isso?
Posso excluir uma conta e assumir a identidade do usuário, mas não alterar um e-mail? Parece um pouco contra-intuitivo~
%{base_url}/u/confirm-new-email/%{email_token}
Meu link se parece com isso e ainda está enviando as pessoas para uma mensagem de erro “Ops”. Você está dizendo que deveria ser o contrário?
Para mim, %{base_url}/u/confirm-new-email/%{email_token} redireciona as pessoas para a página de login sem ativar a conta. O outro é a página de “ops”.
Isso é estranho, mas:
Era assim:
%{base_url}/u/confirm-new-email/%{email_token} e gerou uma mensagem de erro
Mudei para isso:
%{email_token}/u/authorize-email/%{base_url} . e ainda assim gerou uma mensagem de erro
Mudei de volta para isso:
%{base_url}/u/confirm-new-email/%{email_token} manualmente (não redefinindo)
e agora funciona! 
edição: ah, e agora não funciona mais.
Gostaria de adiar isso por um pouco mais de tempo.
E quanto a um link espelho compatível com versões anteriores (obsoleto)? Ou um script de substituição para algumas versões? Seria possível substituir() o antigo %{} pelo novo %{} na próxima versão? Se já tiver sido migrado, nada aconteceria.
Mas, de qualquer forma, meu problema não foi resolvido… ou pelo menos parece que não: Ele apenas os redireciona para a tela de login sem ativação.
https://forum.{meuSite}.com/u/confirm-new-email/{algumHash}
^ Isso está correto? A pessoa insiste que usou a navegação anônima e mostrou uma captura de tela da tela de login. Ao inspecionar, posso ver que o antigo endereço de e-mail ainda aparece no painel de administração.
Não estou entendendo. Por que não simplesmente excluir todas as personalizações de idioma relevantes e começar do zero?
Porque, como eu e outros – eles nem fazem ideia de que isso aconteceu. Não é como se o botão “Clique para atualizar” tivesse luzes piscantes nos dizendo para mudar nosso modelo de e-mail.
Fiz exatamente isso, mas:
Diabo, eu tenho uma conta aqui e ainda não fazia ideia disso e tive que procurar uma solução. Na minha opinião, é inaceitável para a experiência de administração do Discourse em comparação com qualquer outra atualização (é a primeira atualização “intencionalmente quebrada” que já experimentei). Não estou pedindo isso por mim, já que resolvi conforme você disse – mas por outros.
Quem sabe há quanto tempo isso estava acontecendo no meu fórum. Me pergunto quantos novos usuários perdemos porque não tínhamos ideia de que a atualização x tinha uma mudança quebrada no modelo? Não há como eu ser o único.
Só queria dar um retorno sobre isso
Eu nunca personalizei isso. Ele contém %{base_url}/u/confirm-new-email/%{email_token} como você recomendou, mas no e-mail real há /authorize-email/ no link. Então, imagino que algo esteja errado entre o painel de administração da web e algum arquivo de configuração lá no fundo do motor do Discourse. Estou executando a versão 2.5.0.beta6.
Edição: ainda mais estranho: quando um administrador altera o endereço de e-mail, a confirmação enviada para o endereço antigo contém %{base_url}/u/confirm-new-email/%{email_token}, mas o novo endereço recebe a confirmação com %{base_url}/u/authorize-email/%{email_token}.
@Willemb2 descobrimos em nossa instância que o problema só ocorria com usuários que tinham a interface definida para um idioma específico. Então, não importava quantas vezes eu tentasse definir no idioma que eu estava usando, não fazia diferença para os que falavam francês. Tive que definir minha própria interface para francês e, de repente, o sistema permitiu que eu personalizasse a versão em francês. Desde então, não tivemos mais o problema.
@gh_irina Verifiquei isso, mas também ocorre para usuários com o idioma padrão (no nosso caso: holandês).
Ah, isso é chato. Sinto muito.
Encontrei este problema em um fórum do qual sou membro. Consegui contorná-lo ajustando manualmente o link. Para essas alterações drásticas, por que não incluir um “catcher” para o link antigo para alertar o administrador?
