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}
Riesci a riprodurre questo @tshenry?
È successo anche a noi questa settimana, esattamente come descritto sopra.
Probabilmente hai personalizzato quell’email prima che cambiassimo il link.
Per favore, vai su /admin/customize/email_templates/user_notifications.confirm_new_email e assicurati che il link lì assomigli a
%{base_url}/u/confirm-new-email/%{email_token}
invece di
%{base_url}/u/authorize-email/%{email_token}
Potrebbe essere una buona idea aggiungere una migrazione, dopo tutto. Questo è già emerso più volte.
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
Quello ha sistemato il link rotto… in un certo senso; ora, reindirizza semplicemente l’utente alla schermata di accesso.
Anche se è positivo che se ne sia parlato per garantire che le persone possano cambiare la propria email, come mai non c’è un modo per un amministratore di modificare l’email dal pannello di amministrazione? L’unico metodo era impersonare >> profilo >> modifica email? È quanto ho letto, in ogni caso - è davvero il modo corretto per farlo?
Posso eliminare un account e impersonare, ma non cambiare un’email? Sembra un po’ controintuitivo~
%{base_url}/u/confirm-new-email/%{email_token}
Il mio link appare così e sta comunque reindirizzando le persone a un messaggio di errore “Oops”. Stai dicendo che dovrebbe essere al contrario?
Per me, %{base_url}/u/confirm-new-email/%{email_token} reindirizza gli utenti alla pagina di accesso senza attivare l’account. L’altro è la pagina “oops”.
È strano, ma:
Era così:
%{base_url}/u/confirm-new-email/%{email_token} e ha restituito un messaggio di errore
L’ho modificato in questo:
%{email_token}/u/authorize-email/%{base_url} e ha comunque restituito un messaggio di errore
L’ho riportato manualmente a questo:
%{base_url}/u/confirm-new-email/%{email_token} (senza reimpostarlo)
e ora funziona! 
modifica: oh, e ora non funziona più.
Vorrei rimandare questa decisione per un po’ di tempo.
E se si utilizzasse un link specchio retrocompatibile (deprecato)? O uno script di sostituzione per alcune versioni? Si potrebbe sostituire %{} vecchio con %{} nuovo nella prossima versione? Se la migrazione è già avvenuta, non succederebbe nulla.
Comunque sia, il mio problema non è stato risolto… o almeno così sembra: vengono semplicemente reindirizzati alla schermata di login senza attivazione.
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ È corretto? La persona insiste sul fatto di aver utilizzato la modalità di navigazione in incognito e ha mostrato uno screenshot della schermata di login. Dall’analisi, vedo che l’indirizzo email vecchio è ancora visibile nell’area di amministrazione.
Non capisco il motivo: perché non eliminare semplicemente tutte le personalizzazioni relative alla tua lingua e ricominciare da zero?
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?
