Это, похоже, происходит только если электронная почта изменяется. Например,
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
Это решило проблему с битой ссылкой… ну, вроде бы; теперь пользователя просто перенаправляет на экран входа.
Хотя хорошо, что я об этом узнал и теперь смогу убедиться, что люди могут сменить свой email, почему в панели администратора нет возможности редактировать email? Единственный способ — это имитация >> профиль >> смена email? По крайней мере, так я понял — это действительно правильный способ сделать это?
Я могу удалить аккаунт и войти как этот пользователь, но не могу изменить email? Это кажется немного нелогичным~
%{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. Использую версию 2.5.0.beta6.
Редактирование: ещё более странно: когда администратор меняет адрес электронной почты, подтверждение на старый адрес приходит с %{base_url}/u/confirm-new-email/%{email_token}, а на новый адрес — с %{base_url}/u/authorize-email/%{email_token}.
@Willemb2 Мы обнаружили на нашем экземпляре, что проблема возникала только у пользователей, у которых интерфейс был установлен на определённый язык. Поэтому, сколько бы раз я ни пытался установить его на используемый мной язык, для говорящих по-французски это ничего не меняло. Мне пришлось переключить свой собственный интерфейс на французский, и тогда внезапно появилась возможность настроить французскую версию. С тех пор проблема больше не возникала.
@gh_irina Я проверил это, но это также происходит у пользователей с языком по умолчанию (в нашем случае: нидерландский).
Ох, это раздражает. Мне жаль.
Я только что столкнулся с этой проблемой на форуме, участником которого я являюсь. Мне удалось обойти её, вручную изменив ссылку. Для таких критических изменений почему бы не добавить перехватчик для старой ссылки, чтобы уведомлять администратора?
