Questo sembra accadere solo se l’email viene modificata. Ad esempio,
https://forum.{mySite}.com/u/{user}/preferences/email
Modello del link nell’email di conferma:
%{base_url}/u/authorize-email/%{email_token}
Link effettivo nell’email di conferma:
https://forum.{mySite}.com/u/authorize-email/{someHash}
Can you repro this @tshenry?
It happened on ours too this week, just as described above.
You probably customized that email before we changed the link.
Please go to /admin/customize/email_templates/user_notifications.confirm_new_email and make sure that link in there looks like
%{base_url}/u/confirm-new-email/%{email_token}
instead of
%{base_url}/u/authorize-email/%{email_token}
It might be a good idea to add a migration after all. This came up multiple times already.
cc @sam
That took care of the broken link… sort of; now, it just redirects the user to the login screen.
Although it’s good this came to my attention to ensure folks can change their email, how come there’s no way for an admin to edit email from the admin panel? The only way was to impersonate >> profile >> change email? That’s what I read, anyway - is that truly the legit way to do this?
I can delete an account and impersonate but not change an email? Seems a bit counter-intuitive~
%{base_url}/u/confirm-new-email/%{email_token}
My link looks like that and it’s still sending people to an Oops error message. Are you saying it should be the other way round?
For me, %{base_url}/u/confirm-new-email/%{email_token} redirects people to login page without activating the account. The other one is the “oops” page.
This is weird but:
It was this:
%{base_url}/u/confirm-new-email/%{email_token}and gave an error message
I changed it to this:
%{email_token}/u/authorize-email/%{base_url} . and it still gave an error message
I changed it back to this:
%{base_url}/u/confirm-new-email/%{email_token} manually (not by resetting it)
and now it works! 
edit: oh and now it doesn’t again.
I would like to punt on this for a bit longer.
What about a backwards-compatible (deprecated) mirror link? Or a replacement script for a few versions? Could replace() the old %{} with new %{} next ver? If already migrated, nothing would happen.
But either way – my issue isn’t resolved… or, so it seems: It just shoots them to login screen without activation.
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ Is this correct? The person insists they used incognito and showed screenshot of a login screen. Upon inspection, I can see that the old email address is still showing in admin.
I am not following, why not simply delete all your relevant locale customization and start from scratch?
Perché, come me e altri, non avevano idea che fosse successo. Non è come se il pulsante “Clicca per aggiornare” avesse luci lampeggianti che ci dicevano di modificare il nostro modello di email.
Ho fatto esattamente quello, ma:
Diamine, ho un account qui e ancora non ne sapevo nulla e ho dovuto scavare per trovare una soluzione. A mio avviso, è inaccettabile per l’esperienza di amministrazione di Discourse rispetto a qualsiasi altro aggiornamento (è il primo aggiornamento “intenzionalmente rotto” che ho sperimentato). Non lo chiedo per me, dato che l’ho risolto come hai detto, ma per gli altri.
Chi sa da quanto tempo questo stava accadendo sul mio forum. Mi chiedo quanti nuovi utenti abbiamo perso perché non sapevamo che l’aggiornamento x avesse una modifica rotta del modello? Non c’è modo che io sia l’unico.
Volevo solo fare un follow-up a riguardo
Non l’ho mai personalizzato. Contiene %{base_url}/u/confirm-new-email/%{email_token} come hai consigliato, ma nell’email effettiva il link contiene /authorize-email/. Quindi immagino che qualcosa vada storto tra il pannello di amministrazione web e un file di configurazione nascosto nel cuore di Discourse. Sto eseguendo la versione 2.5.0.beta6
Modifica: ancora più strano: quando un amministratore modifica l’indirizzo email, la conferma inviata al vecchio indirizzo contiene %{base_url}/u/confirm-new-email/%{email_token}, mentre quella inviata al nuovo indirizzo contiene %{base_url}/u/authorize-email/%{email_token}
@Willemb2 abbiamo riscontrato sulla nostra istanza che il problema si presentava solo per gli utenti che avevano l’interfaccia impostata su una lingua specifica. Quindi, non importa quante volte ho provato a impostarla nella lingua che stavo utilizzando, non ha fatto alcuna differenza per chi parlava francese. Ho dovuto impostare la mia interfaccia in francese e improvvisamente mi ha permesso di personalizzare la versione francese, e da allora non abbiamo più avuto il problema.
@gh_irina Ho controllato, ma succede anche per gli utenti con la lingua predefinita (nel nostro caso: olandese).
Oh, che seccatura. Mi dispiace.
Ho appena riscontrato questo problema in un forum di cui sono membro. Sono riuscito a risolverlo modificando manualmente il link. Per queste modifiche che interrompono la compatibilità, perché non includere un gestore per il vecchio link per avvisare l’amministratore?
