Soudainement, après la dernière mise à jour, Discourse envoie des e-mails avec :
« Someone replied to a topic you are Watching. » précédant chaque e-mail. Tous mes utilisateurs se plaignent fortement, et aucun n’a modifié ses paramètres d’e-mail.
Tous disent que c’est très ennuyeux.
Alors, que s’est-il passé, et comment pouvons-nous désactiver cela et revenir au comportement normal et simple ? Je ne pense pas que cela ait été bien implémenté, et le développeur n’a même pas pris la peine de vérifier, car “watching” est écrit avec un W majuscule inutile.
Je pense que la source de l’agacement pour les membres de la communauté d’Andrew est %{header_instructions}.
Ce jeton se développe en un bloc de texte passe-partout assez volumineux (« ne pas répondre… », liens, instructions, etc.) et il apparaît tout en haut du corps de l’e-mail dans de nombreux modèles de notification. Pour les utilisateurs expérimentés, il domine le message et ressemble plus à une réprimande qu’à une aide.
Il n’existe actuellement aucun paramètre global pour le désactiver ou le déplacer. Pour le supprimer, un administrateur doit modifier chaque modèle d’e-mail individuellement sous Administration → E-mail → Modèles.
Sur la version actuelle de latest-release (je suis sur latest-release +17), il devrait être possible de résoudre ce problème de manière centralisée avec un script Rails pour les modèles qui ont déjà des remplacements dans la base de données, par exemple, en supprimant %{header_instructions} lorsqu’il apparaît au début du corps. Cette partie est simple et utilise le modèle EmailTemplate.
Appliquer le même changement à tous les modèles par défaut (y compris ceux sans remplacements existants) nécessiterait de créer des remplacements en récupérant les corps des modèles par défaut via des API de recherche internes. C’est faisable, mais cela dépend des mécanismes internes de Discourse et nécessiterait une révision/validation par un mainteneur avant d’être largement recommandé.
Le problème sous-jacent n’est donc pas seulement le contenu de %{header_instructions}, mais le fait qu’il s’agit d’un texte passe-partout global sans bascule au niveau de l’administrateur, et sa suppression ou son déplacement nécessite un travail manuel par modèle ou un script non pris en charge.
@Ethsim2 merci, c’est vraiment super. Mais pourquoi cela a-t-il changé soudainement ? Je ne suis pas un expert pour lire ou même localiser les journaux de modifications.
Le côté « soudain » vient du fait que %{header_instructions} n’est pas quelque chose que vous avez modifié localement : c’est un bloc fourni par le cœur (core) que Discourse injecte dans un certain nombre d’e-mails de notification. Si le cœur modifie son libellé ou le moment où il est inclus, tout le monde le remarquera immédiatement, même si aucun paramètre d’administrateur n’a été touché.
Je ne veux pas trop m’avancer sans référence de commit spécifique, mais la cause la plus probable est un changement récent du cœur dans le texte par défaut auquel %{header_instructions} se développe pour les notifications de sujets suivis (par exemple, l’ajout de la ligne « Quelqu’un a répondu à un sujet que vous suivez. »), ou dans le moment où ce bloc est inclus dans le corps de l’e-mail.
Comment confirmer d’où cela vient :
Dans Admin → E-mail → Paramètres des e-mails → Modèles, consultez les modèles de notification que vos utilisateurs reçoivent (suivi / suivi de près / réponse / mentionné).
Si le corps commence par %{header_instructions}, c’est la source du nouveau texte de préface.
Le supprimer, ou le déplacer sous %{message} / %{context} (ou même %{reply_instructions}), rétablira le comportement précédent « simple ».
Malheureusement, il n’y a actuellement pas d’interrupteur global pour cela. Chaque modèle affecté doit être ajusté individuellement, c’est pourquoi cela semble abrupt et difficile à contrôler lorsque le comportement du cœur change.
Si vous utilisez Discourse hébergé, la solution de contournement pratique consiste simplement à modifier la petite poignée de modèles que vos utilisateurs reçoivent réellement, plutôt que tous.
Donc, dans ce cas, le changement soudain qu’Andro constate provient de l’ajout récent de %{email_preview} (PR #36657), ce qui explique pourquoi il est apparu du jour au lendemain sans aucune modification administrative.
Du point de vue de l’administrateur, le problème est similaire dans tous les cas : il s’agit de contenu injecté au cœur du corps de l’e-mail, et il n’existe actuellement aucun interrupteur global pour le désactiver ou le repositionner. La seule solution de contournement aujourd’hui consiste à modifier les modèles d’e-mails affectés et à supprimer ou déplacer %{email_preview} (tout comme %{header_instructions}).
Pour les clients hébergés en particulier, c’est la raison pour laquelle cela semble abrupt — les paramètres par défaut ont changé, mais il n’y a aucun contrôle global pris en charge.
Les chaînes de prévisualisation peuvent également être remplacées - vous pouvez rechercher la chaîne spécifique ou .preview puis utiliser Ctrl-F pour rechercher user_notifications afin de les trouver.
D’après le message de validation (commit) :
Pour les e-mails HTML, ce texte de prévisualisation est masqué avec display: none pour éviter qu’il n’apparaisse dans le corps de l’e-mail. Pour la version texte brut de l’e-mail, il apparaîtra dans le corps de l’e-mail.
Pour quels utilisateurs ce message apparaît-il ? Il ne devrait pas.
Dans mon client de messagerie, je vois dans la source :
<div> class="email-preview" style="display:none"><p>Someone sent you a PM.</p></div>
et il est masqué à la fois dans Thunderbird et Gmail (web).
À titre de référence, voici comment le nouveau texte d’aperçu apparaît dans Outlook pour iOS pour moi : ce n’est pas seulement un extrait de la boîte de réception ; il devient la première ligne visible associée au message, ce à quoi les utilisateurs réagissent.
Ceci semble cohérent avec l’ajout récent de %{email_preview} : même s’il est destiné à être du texte de pré-en-tête masqué pour les e-mails HTML, il est en réalité très visible pour les utilisateurs (du moins dans certains clients/chemins de livraison), ce qui explique les plaintes soudaines.
C’est probablement intentionnel car cela fait apparaître la raison de l’e-mail dans l’aperçu du message. Je parierais que sans cela, l’aperçu du message n’est généralement pas très utile ?
Cela a du sens, et je suis d’accord que disposer d’un texte d’aperçu significatif est généralement utile.
Le problème auquel les utilisateurs semblent réagir (du moins dans Outlook pour iOS et des clients similaires) est que ce texte d’aperçu n’influence pas seulement l’extrait de la boîte de réception, mais qu’il est visuellement lu comme faisant partie du corps du message lui-même, apparaissant avant le contenu réel. En pratique, cela semble répétitif et bruyant plutôt qu’utile.
Il y a aussi une certaine tension dans la formulation actuelle : la formulation anonyme (« Quelqu’un a répondu… ») est utile d’un point de vue de la confidentialité et du partage de captures d’écran, mais dans l’utilisation quotidienne, elle est moins informative que les aperçus sensibles à l’expéditeur, où les utilisateurs veulent principalement savoir qui a répondu et si cela nécessite une attention.
Il s’agit donc moins de savoir si le texte d’aperçu doit exister ou non, et davantage de savoir si l’implémentation actuelle, assez rigide, dégrade l’expérience de lecture dans certains clients ou chemins de livraison. Une approche sensible au client, ou un moyen pris en charge pour le repositionner ou le désactiver, réglerait probablement la plupart des plaintes sans perdre l’avantage des aperçus améliorés.
Ceci est très utile. Mais maintenant, l’objet de l’e-mail qui contenait [The Jackrail][] n’a plus la catégorie. J’aimerais conserver le comportement d’origine.
De plus, comment puis-je savoir ce que contient la variable header_instructions ?
![Capture d'écran de Mail sur Outlook pour iOS montrant « Quelqu'un a répondu à votre publication. » apparaissant bien en évidence au-dessus du contenu du message, avec les préfixes FW/[PM] visibles](https://d11a6trkgmumsb.cloudfront.net/original/4X/9/1/f/91f715903dc7d1007a38043b45ed779ae5c6fe6d.jpeg)