Esto parece ocurrir solo si el correo electrónico se modifica. Por ejemplo,
https://forum.{mySite}.com/u/{user}/preferences/email
Plantilla del enlace de confirmación en el correo:
%{base_url}/u/authorize-email/%{email_token}
Enlace real de confirmación en el correo:
https://forum.{mySite}.com/u/authorize-email/{someHash}
¿Puedes reproducir esto, @tshenry?
Nos pasó a nosotros también esta semana, tal como se describió anteriormente.
Probablemente personalizó ese correo antes de que cambiáramos el enlace.
Por favor, vaya a /admin/customize/email_templates/user_notifications.confirm_new_email y asegúrese de que el enlace allí se vea así:
%{base_url}/u/confirm-new-email/%{email_token}
en lugar de:
%{base_url}/u/authorize-email/%{email_token}
Podría ser una buena idea agregar una migración después de todo. Esto ya ha surgido varias veces.
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
Eso solucionó el enlace roto… más o menos; ahora, simplemente redirige al usuario a la pantalla de inicio de sesión.
Aunque es bueno que esto haya salido a la luz para asegurar que los usuarios puedan cambiar su correo electrónico, ¿por qué no hay una forma para que un administrador edite el correo desde el panel de administración? ¿La única opción era suplantación de identidad > perfil > cambiar correo? Eso es lo que entendí, de todos modos. ¿Es realmente la forma legítima de hacerlo?
Puedo eliminar una cuenta y suplantar la identidad, pero no cambiar un correo electrónico. Parece un poco contra intuitivo~
%{base_url}/u/confirm-new-email/%{email_token}
Mi enlace se ve así y sigue enviando a las personas a un mensaje de error Oops. ¿Estás diciendo que debería ser al revés?
Para mí, %{base_url}/u/confirm-new-email/%{email_token} redirige a las personas a la página de inicio de sesión sin activar la cuenta. La otra es la página de “error”.
Esto es raro, pero:
Antes era esto:
%{base_url}/u/confirm-new-email/%{email_token} y daba un mensaje de error
Lo cambié a esto:
%{email_token}/u/authorize-email/%{base_url} y seguía dando un mensaje de error
Lo volví a cambiar manualmente a esto:
%{base_url}/u/confirm-new-email/%{email_token} (sin restablecerlo)
y ¡ahora funciona! 
edición: oh, y ahora ya no funciona de nuevo.
Me gustaría posponer esto un poco más.
¿Qué tal un enlace espejo compatible hacia atrás (obsoleto)? ¿O un script de reemplazo para algunas versiones? ¿Podríamos usar replace() para cambiar el %{} antiguo por el nuevo %{} en la próxima versión? Si ya se ha migrado, no pasaría nada.
Pero de todas formas, mi problema no está resuelto… o eso parece: simplemente los redirige a la pantalla de inicio de sesión sin activación.
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ ¿Es esto correcto? La persona insiste en que usó la navegación privada y mostró una captura de pantalla de la pantalla de inicio de sesión. Al inspeccionar, puedo ver que la dirección de correo electrónico antigua sigue apareciendo en el panel de administración.
No te estoy siguiendo, ¿por qué no simplemente borras todas tus personalizaciones de idioma relevantes y empiezas desde cero?
Porque, como yo y otros, no tienen ni idea de que esto siquiera ocurrió. No es como si el botón ‘Hacer clic para actualizar’ tuviera luces parpadeantes diciéndonos que cambiáramos nuestra plantilla de correo.
Hice exactamente eso, pero:
Vaya, tengo una cuenta aquí y aún así no tenía ni idea de esto y tuve que buscar una solución. En mi opinión, es inaceptable para la experiencia de administración de Discourse en comparación con cualquier otra actualización (es la primera actualización que he experimentado que “rompe intencionalmente” algo). No lo pido por mí, ya que lo resolví como dijiste, sino por los demás.
¿Quién sabe cuánto tiempo estuvo ocurriendo esto en mi foro? Me pregunto cuántos nuevos usuarios perdimos porque no teníamos ni idea de que una actualización X había cambiado la plantilla de forma que rompía cosas. No hay manera de que yo sea el único.
Solo quería dar seguimiento a esto
Nunca lo personalicé. Contiene %{base_url}/u/confirm-new-email/%{email_token} como me aconsejaste, pero en el correo electrónico real el enlace tiene /authorize-email/. Supongo que algo falla entre el panel de administración web y algún archivo de configuración oculto en el corazón del motor de Discourse. Estoy ejecutando la versión 2.5.0.beta6.
Edición: aún más extraño: cuando un administrador cambia la dirección de correo electrónico, la confirmación enviada a la dirección antigua contiene %{base_url}/u/confirm-new-email/%{email_token}, pero la nueva dirección recibe una con %{base_url}/u/authorize-email/%{email_token}.
@Willemb2 En nuestra instancia descubrimos que el problema solo ocurría en usuarios que tenían su interfaz configurada en un idioma específico. Así que, sin importar cuántas veces intentara configurarlo en el idioma que yo estaba usando, no marcaba ninguna diferencia para los que hablaban francés. Tuve que cambiar mi propia interfaz al francés y, de repente, me permitió personalizar la versión en francés; desde entonces, no hemos tenido el problema.
@gh_irina Lo revisé, pero también ocurre con usuarios que tienen el idioma predeterminado (en nuestro caso: neerlandés).
¡Vaya, eso es molesto! Lo siento.
Me acabo de encontrar con este problema en un foro del que soy miembro. Logré solucionarlo ajustando manualmente el enlace. Para estos cambios drásticos, ¿por qué no incluir un detector para el enlace antiguo para alertar al administrador?
