Cela semble ne se produire que si l’adresse e-mail est modifiée. Par exemple,
https://forum.{mySite}.com/u/{user}/preferences/email
Modèle de lien d’e-mail de confirmation :
%{base_url}/u/authorize-email/%{email_token}
Lien réel de l’e-mail de confirmation :
https://forum.{mySite}.com/u/authorize-email/{someHash}
Peux-tu reproduire cela @tshenry ?
C’est arrivé chez nous aussi cette semaine, exactement comme décrit ci-dessus.
Vous avez probablement personnalisé cet e-mail avant que nous ne changions le lien.
Veuillez vous rendre dans /admin/customize/email_templates/user_notifications.confirm_new_email et vérifier que le lien ressemble à
%{base_url}/u/confirm-new-email/%{email_token}
et non à
%{base_url}/u/authorize-email/%{email_token}
Ce serait peut-être une bonne idée d’ajouter une migration après tout. Ce sujet est revenu à plusieurs reprises déjà.
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
Cela a réglé le lien brisé… en quelque sorte ; maintenant, il redirige simplement l’utilisateur vers l’écran de connexion.
Même si c’est bien que cela soit venu à mon attention pour s’assurer que les utilisateurs puissent modifier leur adresse e-mail, pourquoi n’y a-t-il aucun moyen pour un administrateur de modifier l’e-mail depuis le panneau d’administration ? La seule méthode était d’usurper l’identité >> profil >> modifier l’e-mail ? C’est ce que j’ai lu, en tout cas — est-ce vraiment la façon légitime de procéder ?
Je peux supprimer un compte et usurper l’identité, mais pas modifier une adresse e-mail ? Cela semble un peu contre-intuitif~
%{base_url}/u/confirm-new-email/%{email_token}
Mon lien ressemble à cela et il redirige toujours les utilisateurs vers un message d’erreur Oops. Voulez-vous dire que cela devrait être l’inverse ?
Pour moi, %{base_url}/u/confirm-new-email/%{email_token} redirige les utilisateurs vers la page de connexion sans activer le compte. L’autre est la page « oops ».
C’est étrange, mais :
Ça fonctionnait comme ceci :
%{base_url}/u/confirm-new-email/%{email_token} et cela affichait un message d’erreur
J’ai modifié pour ceci :
%{email_token}/u/authorize-email/%{base_url}. et cela affichait toujours un message d’erreur
J’ai remis cela manuellement (sans le réinitialiser) :
%{base_url}/u/confirm-new-email/%{email_token}
et maintenant ça marche ! 
edit : oh, et maintenant ça ne marche plus.
Je souhaiterais repousser cela un peu plus longtemps.
Et si on ajoutait un lien miroir rétrocompatible (déprécié) ? Ou un script de remplacement valable pour quelques versions ? Pourrait-on remplacer %{} par %{} dans la prochaine version ? Si la migration est déjà faite, rien ne se produirait.
Mais dans les deux cas, mon problème n’est pas résolu… ou du moins c’est ce que cela semble être : cela redirige simplement vers l’écran de connexion sans activation.
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ Est-ce correct ? La personne insiste sur le fait qu’elle a utilisé la navigation privée et a montré une capture d’écran de l’écran de connexion. Après vérification, je constate que l’ancienne adresse e-mail est toujours affichée dans l’administration.
Je ne suis pas sûr de vous suivre. Pourquoi ne pas simplement supprimer toutes vos personnalisations de langue pertinentes et repartir de zéro ?
Parce que, comme moi et d’autres, ils n’ont aucune idée que cela s’est produit même. Ce n’est pas comme si le bouton « Cliquer pour mettre à jour » avait des lumières clignotantes nous disant de modifier notre modèle d’e-mail.
J’ai fait exactement cela, mais :
Bon sang, j’ai un compte ici et j’étais toujours au courant de cela et j’ai dû chercher une solution. À mon avis, c’est inacceptable pour l’expérience d’administration de Discourse par rapport à toute autre mise à jour (c’est la première mise à jour « intentionnellement cassante » que j’ai vécue). Je ne demande pas cela pour moi puisque je l’ai résolu comme vous l’avez dit, mais pour les autres.
Qui sait depuis combien de temps cela se produisait sur mon forum. Je me demande combien de nouveaux utilisateurs nous avons perdus parce que nous ignorions que la mise à jour x avait apporté une modification cassante au modèle ? Il est impossible que je sois le seul.
Je voulais juste faire un suivi à ce sujet
Je ne l’ai jamais personnalisé. Il contient %{base_url}/u/confirm-new-email/%{email_token} comme vous l’avez conseillé, mais dans l’e-mail réel, le lien contient /authorize-email/. Je suppose donc qu’il y a un problème entre le panneau d’administration web et un fichier de configuration profondément enfoui dans la machine de Discourse. Version en cours : 2.5.0.beta6
Édition : encore plus étrange : lorsqu’un administrateur modifie son adresse e-mail, une confirmation est envoyée à l’ancienne adresse avec %{base_url}/u/confirm-new-email/%{email_token}, mais la nouvelle adresse reçoit un lien avec %{base_url}/u/authorize-email/%{email_token}.
@Willemb2 nous avons constaté sur notre instance que le problème ne survenait que pour les utilisateurs ayant défini leur interface sur une langue spécifique. Ainsi, peu importe le nombre de fois où j’essayais de le configurer dans la langue que j’utilisais, cela ne changeait rien pour ceux qui parlaient français. J’ai dû passer moi-même mon interface en français, et soudain, cela m’a permis de personnaliser la version française. Nous n’avons plus rencontré ce problème depuis.
@gh_irina J’ai vérifié cela, mais cela se produit également pour les utilisateurs avec la langue par défaut (dans notre cas : néerlandais).
Oh, c’est embêtant. Je suis désolé.
J’ai rencontré ce problème sur un forum dont je suis membre. J’ai réussi à le contourner en ajustant manuellement le lien. Pour ces changements majeurs, pourquoi ne pas inclure un mécanisme de capture pour l’ancien lien afin d’alerter l’administrateur ?
