nathank
Juin 14, 2026, 10:36
1
La notification par e-mail pour un nouveau message d’événement n’inclut pas la description de l’événement. Si le corps du message contient du texte, celui-ci est inclus.
Je trouve que cela offre une expérience très « épurée ». Trop épurée !
Par exemple :
Puisque la tendance actuelle semble être d’encourager les utilisateurs à ajouter plus de contenu dans le champ Description, il me semblerait logique de l’inclure dans les e-mails de notification.
2 « J'aime »
Merci, cela sera corrigé par
main ← fix-event-email-details
opened 12:41PM - 15 Jun 26 UTC
Previously, the notification email for an event post showed almost nothing about… 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.
3 « J'aime »
