Cambio en el comportamiento sobre el correo

De repente, después de la última actualización, Discourse envía correos electrónicos con:

“Alguien respondió a un tema que estás siguiendo.” anteponiéndose a cada correo electrónico. Todos mis usuarios se están quejando mucho, y ninguno ha cambiado ninguna configuración de correo electrónico.

Todos dicen que es muy molesto.

Entonces, ¿qué ha pasado y cómo podemos desactivar esto y volver al comportamiento normal y simple? No creo que esto se haya implementado bien, y el desarrollador ni siquiera se molestó en revisarlo, ya que “watching” (siguiendo) está escrito con una W innecesariamente en mayúscula.

Creo que la fuente de molestia para los miembros de la comunidad de Andrew es %{header_instructions}.

Ese token se expande a un bloque de texto repetitivo bastante grande (“no responder…”, enlaces, instrucciones, etc.) y aparece al principio del cuerpo del correo electrónico en muchas plantillas de notificación. Para los usuarios experimentados, domina el mensaje y se lee como una reprimenda en lugar de algo útil.

Actualmente no hay una configuración a nivel de sitio para desactivarlo o reubicarlo. Para eliminarlo, un administrador tiene que editar cada plantilla de correo electrónico individualmente en Admin → Email → Templates.

En la versión actual latest-release (estoy en latest-release +17), debería ser posible abordar esto de forma centralizada con un script de Rails para las plantillas que ya tienen anulaciones en la base de datos, por ejemplo, eliminando %{header_instructions} cuando aparece al principio del cuerpo. Esa parte es sencilla y utiliza el modelo EmailTemplate.

Aplicar el mismo cambio a todas las plantillas predeterminadas (incluidas aquellas sin anulaciones existentes) requeriría crear anulaciones extrayendo los cuerpos de las plantillas predeterminadas a través de las API de búsqueda internas. Eso es factible, pero depende de los componentes internos de Discourse y necesitaría la revisión/validación de un mantenedor antes de recomendarse ampliamente.

Por lo tanto, el problema subyacente no es solo el contenido de %{header_instructions}, sino que es efectivamente un texto repetitivo global sin un interruptor a nivel de administrador, y eliminarlo o moverlo requiere trabajo manual por plantilla o scripting no compatible.

@Ethsim2 gracias, eso es realmente genial. Pero ¿por qué cambió esto de repente? No soy un experto en leer o incluso localizar registros de cambios.

@Andro sí, pregunta totalmente justa.

La parte de “de repente” se debe a que %{header_instructions} no es algo que hayas cambiado localmente: es un bloque proporcionado por el núcleo que Discourse inyecta en varios correos electrónicos de notificación. Si el núcleo cambia su redacción o cuándo se incluye, todos lo notarán inmediatamente, incluso si no se tocó ninguna configuración de administrador.

No quiero exagerar sin una referencia de commit específica, pero la causa más probable es un cambio reciente del núcleo en el texto predeterminado al que se expande %{header_instructions} para las notificaciones de temas seguidos (por ejemplo, al añadir la línea “Alguien respondió a un tema que estás siguiendo”), o en cuándo se incluye ese bloque en el cuerpo del correo electrónico.

Cómo confirmar de dónde viene:

  • En Administrador → Correo electrónico → Configuración de correo electrónico → Plantillas, revisa las plantillas de notificación que reciben tus usuarios (seguido / rastreado / respondido / mencionado).
  • Si el cuerpo comienza con %{header_instructions}, esa es la fuente del nuevo texto introductorio.
  • Eliminarlo, o moverlo debajo de %{message} / %{context} (o incluso %{reply_instructions}), revertirá al comportamiento “simple” anterior.

Desafortunadamente, actualmente no hay un interruptor general para esto. Cada plantilla afectada debe ajustarse individualmente, por eso esto se siente abrupto y difícil de controlar cuando el comportamiento del núcleo cambia.

Si utilizas Discourse alojado, la solución práctica es simplemente editar el pequeño puñado de plantillas que tus usuarios reciben realmente, en lugar de todas ellas.

1 me gusta

Estas vistas previas se agregaron hace unos días

3 Me gusta

¿Entonces, solo eliminar %{email_preview} de las plantillas solucionaría esto?

1 me gusta

La palabra Watching a menudo se escribe con mayúscula en referencia a la función específica de Discourse.

Siempre estoy observando (watching) la aparición de temas interesantes. Pero estoy Vigilando (Watching) temas concretos para ver si hay nuevas respuestas.

2 Me gusta

Y luego Seguimiento, etc., como se indica en el menú desplegable de estado de notificación del tema.

Para ser honesto, no lo habría descubierto. Lo entiendo, pero es un poco inusual, en cierto modo.

1 me gusta

Gracias, eso tiene sentido.

Así que en este caso, el cambio repentino que Andro está viendo proviene de que %{email_preview} se agregó recientemente (PR #36657), lo que explica por qué apareció de la noche a la mañana sin ningún cambio administrativo.

Desde el punto de vista de un administrador, el problema es similar de todos modos: es contenido inyectado centralmente en la parte superior del cuerpo del correo electrónico, y actualmente no hay una opción global para deshabilitarlo o reposicionarlo. La única solución hoy en día es editar las plantillas de correo electrónico afectadas y eliminar o mover %{email_preview} (al igual que %{header_instructions}).

Para los clientes alojados en particular, por eso se siente tan abrupto: los valores predeterminados cambiaron, pero no hay un control global compatible.

Las cadenas de vista previa también se pueden anular: puedes buscar la cadena específica o .preview y luego usar Ctrl-F para buscar user_notifications y encontrarlas.

Del mensaje de confirmación (commit message):

Para los correos electrónicos html, este texto de vista previa se oculta con display: none para evitar que aparezca dentro del cuerpo del correo electrónico. Para la versión de texto sin formato del correo electrónico, aparecerá dentro del cuerpo del correo electrónico.

¿Para qué usuarios aparece este mensaje? No debería.

En mi cliente de correo electrónico, veo en el código fuente:

<div> class="email-preview" style="display:none"> <p>Someone sent you a PM.</p> </div>

y está oculto tanto en Thunderbird como en Gmail (web).

2 Me gusta

Como referencia, así es como aparece el nuevo texto de vista previa en Outlook para iOS para mí: no es solo un fragmento de la bandeja de entrada; se convierte en la primera línea visible asociada con el mensaje, que es a lo que los usuarios están reaccionando.

Esto parece consistente con la adición reciente de %{email_preview}: incluso si está destinado a ser texto de preencabezado oculto para correos electrónicos HTML, en la práctica es muy visible para los usuarios (al menos en algunos clientes/rutas de entrega), lo que explica las quejas repentinas.

Esto es probablemente intencional ya que está mostrando la razón del correo electrónico en la vista previa del mensaje. Me atrevería a adivinar que sin él, la vista previa del mensaje generalmente no es útil.

Eso tiene sentido, y estoy de acuerdo en que tener algo de texto de vista previa significativo es generalmente útil.

El problema al que los usuarios parecen reaccionar (al menos en Outlook para iOS y clientes similares) es que este texto de vista previa no solo influye en el fragmento de la bandeja de entrada, sino que se lee visualmente como parte del cuerpo del mensaje, apareciendo antes del contenido real. En la práctica, eso se siente repetitivo y molesto en lugar de útil.

También hay una pequeña tensión en la redacción actual: la formulación anónima (“Alguien respondió…”) es útil desde el punto de vista de la privacidad y el uso compartido de capturas de pantalla, pero en el uso diario es menos informativa que las vistas previas conscientes del remitente, donde los usuarios principalmente quieren saber quién respondió y si necesita atención.

Por lo tanto, se trata menos de si el texto de vista previa debe existir o no, y más de si la implementación actual, bastante rígida, degrada la experiencia de lectura en algunos clientes o rutas de entrega. Un enfoque sensible al cliente, o una forma compatible de reposicionarlo o deshabilitarlo, probablemente abordaría la mayoría de las quejas sin perder el beneficio de mejores vistas previas.

1 me gusta