nathank
14 Junio, 2026 22:36
1
La notificación por correo electrónico de una nueva publicación de evento no incluye la descripción del evento. Si hay texto en el cuerpo de la publicación, este sí se incluye.
Esto me parece una experiencia muy “ligera”. ¡Demasiado ligera!
Por ejemplo:
Dado que la dirección actual parece ser la de animar a la gente a añadir más contenido en el campo Descripción, para mí tendría sentido incluirlo en los correos de notificación.
2 Me gusta
Gracias, se solucionará en
main ← fix-event-email-details
merged 03:10PM - 02 Jul 26 UTC
Previously, the notification email for an event post showed almost
nothing abou… t the event. The event card is rendered client-side from the
`[event]` block's `data-*` attributes, so emails (which run no
JavaScript) fell back to a sparse table that omitted the description
entirely and mishandled other fields: all-day events showed a bogus
"12:00 AM", recurring events gave no hint that they repeat, and
scheme-less URLs produced broken relative links.
This change extracts the email rendering into a dedicated
`DiscoursePostEvent::EmailRenderer` that mirrors the on-site event card
as closely as a static rendering allows. The email now includes the
description, status (e.g. Expired/Closed), creator, recurrence label, "N
going" count and cover image; formats all-day dates without a spurious
time/timezone; renders emoji in the event name; cooks markdown in the
location; and prepends a scheme to scheme-less URLs.
Translations are read from the existing client locale (the `js.*`
namespace) so the email and the card never drift, and recurrence/status
values are gated by `EventValidator::VALID_RECURRENCES` and the event's
own status. Purely interactive parts of the card (RSVP buttons,
chat-channel link, more menu) are intentionally omitted.
The creator is shown according to the site's name settings
(`display_name` gated by `enable_names`) rather than always exposing the
real name, which matches the on-site card and the other surfaces these
emails reach, such as embedded comments.
`PrettyText.format_for_email` does no sanitization of its own, so every
field is escaped where it is rendered. Description URLs are linkified by
escaping each text segment independently, keeping any markup that follows
a URL out of the generated `href`.
Finally, rendering is resilient: a failure on a single event is rescued
and logged so one malformed event can never abort an entire digest or
notification email.
**BEFORE / AFTER**
<img width="2720" height="1666" alt="before_after" src="https://github.com/user-attachments/assets/fe3aa7ce-7659-42c6-8c84-628516c92fdc" />
3 Me gusta
Este tema se cerró automáticamente después de 3 días. Ya no se permiten nuevas respuestas.
