これは、メールが変更された場合にのみ発生するようです。例：
https://forum.{mySite}.com/u/{user}/preferences/email
確認メールのリンクテンプレート：
%{base_url}/u/authorize-email/%{email_token}
実際の確認メールのリンク：
https://forum.{mySite}.com/u/authorize-email/{someHash}
@tshenry さん、これを再現できますか？
今週、私たちのところでも上記と同じことが起きました。
おそらく、リンクを変更する前にそのメールをカスタマイズされたのでしょう。
/admin/customize/email_templates/user_notifications.confirm_new_email に移動し、そこにあるリンクが以下のようになっていることを確認してください。
%{base_url}/u/confirm-new-email/%{email_token}
以下ではありません。
%{base_url}/u/authorize-email/%{email_token}
結局、マイグレーションを追加したほうが良いかもしれません。これはすでに何度か話題になっています。
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
壊れたリンクの件は、まあ、なんとか処理できました…「まあ」ですが。今はユーザーをログイン画面にリダイレクトするだけになっています。
メール変更が可能になったことは良いことですが、なぜ管理者が管理パネルから直接メールを編集できないのでしょうか？私が読んだ限りでは、なりすまし → プロフィール → メール変更、という手順しかないとのことですが、これが本当に正規の手順なのでしょうか？
アカウントを削除したりなりすましたりはできるのに、メール変更ができないというのは、少し不自然に思えますね〜
%{base_url}/u/confirm-new-email/%{email_token}
私のリンクは上記のようになっており、それでもユーザーが「おっと」というエラーメッセージに誘導されてしまいます。順序が逆であるべきだとおっしゃっているのでしょうか？
私の場合、%{base_url}/u/confirm-new-email/%{email_token} はアカウントを有効化せずにログインページにリダイレクトしてしまいます。もう一方は「おっと」ページです。
これは奇妙なんですが：
最初はこれでした：
%{base_url}/u/confirm-new-email/%{email_token}
エラーメッセージが表示されました。
次にこれに変更しました：
%{email_token}/u/authorize-email/%{base_url}
それでもエラーメッセージが表示されました。
その後、手動で（リセットではなく）これに戻しました：
%{base_url}/u/confirm-new-email/%{email_token}
そして、今では動作します！
追記：あ、でも今度はまた動作しなくなりました。
もう少しこの件を先送りしたいと考えています。
後方互換性のある（非推奨の）ミラーリンクはどうでしょうか？あるいは、数バージョンにわたる置き換えスクリプトは？次のバージョンで古い %{} を新しい %{} に replace() することは可能でしょうか？すでに移行済みの場合、何も起こりません。
どちらにせよ、私の問題は解決していません。あるいは、そう見えます：アクティベーションなしでログイン画面にリダイレクトされてしまうのです。
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ これは正しいでしょうか？相手はシークレットモードを使用したと主張し、ログイン画面のスクリーンショットを示しました。確認したところ、管理画面には古いメールアドレスがまだ表示されていました。
よくわかりません。なぜ関連するロケールのカスタマイズをすべて削除して最初から始めないのでしょうか？
私や他の人々と同じように、多くの人がこの事象自体を把握していませんでした。「メールテンプレートを変更してください」という更新ボタンが、点滅するライトで知らせてくれるわけではないのですから。
私はまさにその通り行いましたが、以下の問題があります：
実際、私もここでアカウントを持っていますが、それでもこの事象に気づかず、修正策を探すために掘り起こす必要がありました。私の見解では、Discourse の管理体験において、他のどの更新と比較してもこれは許容できません（私が経験した中で、意図的に互換性を破壊する更新はこれが初めてです）。私は私自身のためではなく、他の人のために言っているのです。
この問題が私のフォーラムでどれくらいの期間続いていたのかはわかりません。x 番目の更新でテンプレートの変更が互換性を破壊していたことに気づかなかったため、どれだけの新規ユーザーを失ったのか疑問に思います。私が唯一の被害者であるはずがありません。
これについてフォローアップしたかったのですが
カスタマイズは行なっていません。ご助言通り%{base_url}/u/confirm-new-email/%{email_token}が含まれていますが、実際のメール内のリンクには/authorize-email/が含まれています。つまり、Discourse のエンジンルームの奥深くにある設定ファイルと Web 管理パネルの間に何らかの問題が発生しているようです。バージョンは 2.5.0.beta6 です。
追記：さらに奇妙なことに、管理者がメールアドレスを変更すると、旧アドレスには%{base_url}/u/confirm-new-email/%{email_token}を含む確認メールが届きますが、新アドレスには%{base_url}/u/authorize-email/%{email_token}を含む確認メールが届きます。
@Willemb2 私たちのインスタンスでは、問題が発生したのはインターフェースを特定の言語に設定しているユーザーに限られていました。そのため、私が使用している言語に設定しようとしても、フランス語を話しているユーザーには全く影響がありませんでした。私が自分のインターフェースをフランス語に設定したところ、突然フランス語版のカスタマイズが可能になり、それ以降は問題が発生していません。
@gh_irina 確認しましたが、デフォルト言語（私たちの場合：オランダ語）のユーザーでも同様の現象が発生します。
ああ、それは面倒ですね。申し訳ありません。
フォーラムのメンバーであるのですが、この問題が発生しました。リンクを手動で調整することで回避できましたが、このような破壊的な変更の場合、古いリンクのキャッチャーを含めて管理者に通知するのはどうでしょうか？
