Plötzlich nach dem neuesten Update sendet Discourse E-Mails mit:
„Jemand hat auf ein Thema geantwortet, das Sie beobachten.“ vor jeder E-Mail. Alle meine Benutzer beschweren sich stark, und niemand hat seine E-Mail-Einstellungen geändert.
Alle sagen, es sei sehr ärgerlich.
Was ist also passiert, und wie können wir das deaktivieren und zum normalen, einfachen Verhalten zurückkehren? Ich glaube nicht, dass dies gut umgesetzt wurde, und der Entwickler hat sich nicht einmal die Mühe gemacht, es zu überprüfen, da „watching“ mit einem unnötigen großen W geschrieben ist.
Ich denke, die Quelle der Verärgerung für Andrews Community-Mitglieder ist %{header_instructions}.
Dieses Token expandiert zu einem ziemlich großen Block von Boilerplate-Text („nicht antworten…“, Links, Anweisungen usw.) und erscheint ganz oben im E-Mail-Text in vielen Benachrichtigungsvorlagen. Für erfahrene Benutzer dominiert es die Nachricht und wirkt eher wie Nörgelei als hilfreich.
Derzeit gibt es keine sitzungsweite Einstellung, um dies zu deaktivieren oder zu verschieben. Um es zu entfernen, muss ein Administrator jede E-Mail-Vorlage einzeln unter Admin → E-Mail → Vorlagen bearbeiten.
Auf der aktuellen latest-release (ich bin auf latest-release +17) sollte es möglich sein, dies zentral mit einem Rails-Skript für Vorlagen zu beheben, die bereits Datenbank-Overrides haben, z. B. indem %{header_instructions} entfernt wird, wenn es am Anfang des Textkörpers erscheint. Dieser Teil ist unkompliziert und verwendet das EmailTemplate-Modell.
Die Anwendung derselben Änderung auf alle Standardvorlagen (einschließlich derer ohne bestehende Overrides) würde das Erstellen von Overrides erfordern, indem die Standardvorlagentexte über interne Nachschlage-APIs abgerufen werden. Das ist machbar, hängt aber von den internen Mechanismen von Discourse ab und müsste von einem Maintainer überprüft/validiert werden, bevor es breit empfohlen wird.
Das zugrunde liegende Problem ist also nicht nur der Inhalt von %{header_instructions}, sondern dass es sich effektiv um globales Boilerplate ohne eine Umschaltmöglichkeit auf Admin-Ebene handelt, und das Entfernen oder Verschieben erfordert manuelle Arbeit pro Vorlage oder nicht unterstütztes Skripten.
@Ethsim2 danke, das ist wirklich großartig. Aber warum hat sich das plötzlich geändert? Ich bin kein Experte darin, Änderungsprotokolle zu lesen oder überhaupt zu finden.
Das „plötzlich“ kommt daher, dass %{header_instructions} nichts ist, was Sie lokal geändert haben: Es ist ein von der Kernsoftware bereitgestellter Block, den Discourse in eine Reihe von Benachrichtigungs-E-Mails einfügt. Wenn die Kernsoftware ihre Formulierung ändert oder entscheidet, wann dieser Block enthalten ist, werden alle dies sofort bemerken, selbst wenn keine Admin-Einstellungen geändert wurden.
Ich möchte hier keine falschen Behauptungen aufstellen, ohne einen spezifischen Commit-Verweis, aber die wahrscheinlichste Ursache ist eine kürzliche Änderung im Kerncode des Standardtextes, zu dem %{header_instructions} für „Beobachtete-Themen“-Benachrichtigungen erweitert wird (zum Beispiel das Hinzufügen der Zeile „Jemand hat auf ein Thema geantwortet, das Sie beobachten.“), oder eine Änderung, wann dieser Block in den E-Mail-Text aufgenommen wird.
So können Sie bestätigen, woher es kommt:
Gehen Sie in Admin → E-Mail → E-Mail-Einstellungen → Vorlagen und sehen Sie sich die Benachrichtigungsvorlagen an, die Ihre Benutzer erhalten (beobachtet / verfolgt / geantwortet / erwähnt).
Wenn der Text mit %{header_instructions} beginnt, ist dies die Quelle des neuen einleitenden Textes.
Wenn Sie diesen entfernen oder ihn unter %{message} / %{context} (oder sogar %{reply_instructions}) verschieben, kehren Sie zum vorherigen „einfachen“ Verhalten zurück.
Unglücklicherweise gibt es derzeit keine systemweite Umschaltmöglichkeit dafür. Jede betroffene Vorlage muss einzeln angepasst werden, weshalb sich dies abrupt und schwer zu kontrollieren anfühlt, wenn sich das Kernverhalten ändert.
Wenn Sie Discourse gehostet nutzen, besteht die praktische Lösung darin, nur die kleine Anzahl von Vorlagen zu bearbeiten, die Ihre Benutzer tatsächlich erhalten, anstatt alle.
In diesem Fall stammt die plötzliche Änderung, die Andro sieht, von der kürzlich hinzugefügten %{email_preview} (PR #36657), was erklärt, warum sie über Nacht ohne jegliche Admin-Änderungen aufgetaucht ist.
Aus Administratorsicht ist der Schmerzpunkt in beiden Fällen ähnlich: Es handelt sich um in den Kern injizierte Inhalte am Anfang des E-Mail-Textes, und es gibt derzeit keinen seitenweiten Schalter, um diese zu deaktivieren oder neu zu positionieren. Die einzige heutige Umgehung besteht darin, die betroffenen E-Mail-Vorlagen zu bearbeiten und %{email_preview} zu entfernen oder zu verschieben (genau wie %{header_instructions}).
Insbesondere für gehostete Kunden fühlt sich dies deshalb abrupt an – Standardwerte wurden geändert, aber es gibt keine unterstützte globale Steuerung.
Die Vorschau-Strings können auch überschrieben werden – Sie können nach dem spezifischen String oder .preview suchen und dann mit Strg+F nach user_notifications suchen, um sie zu finden.
Aus der Commit-Nachricht:
Bei HTML-E-Mails wird dieser Vorschautext mit display: none ausgeblendet, um zu verhindern, dass er im Hauptteil der E-Mail erscheint. Bei der reinen Textversion der E-Mail wird er im Hauptteil der E-Mail angezeigt.
Bei welchen Benutzern wird diese Nachricht angezeigt? Das sollte nicht der Fall sein.
In meinem E-Mail-Client sehe ich im Quellcode:
<div> class="email-preview" style="display:none"> <p>Jemand hat Ihnen eine PN gesendet.</p> </div>
und es ist sowohl in Thunderbird als auch in Gmail (Web) ausgeblendet.
Als Referenz, so wird der neue Vorschautext für mich in Outlook für iOS angezeigt – es ist nicht nur ein Snippet aus dem Posteingang; es wird zur ersten sichtbaren Zeile, die mit der Nachricht verbunden ist, worauf die Benutzer reagieren.
Dies scheint konsistent mit der kürzlich hinzugefügten %{email_preview} zu sein: Selbst wenn sie als versteckter Preheader-Text für HTML-E-Mails gedacht ist, ist sie in der Praxis für Benutzer (zumindest in einigen Clients/Zustellpfaden) sehr sichtbar, was die plötzlichen Beschwerden erklärt.
Das ist wahrscheinlich beabsichtigt, da es den Grund für die E-Mail in der Nachrichten-Vorschau anzeigt. Ich würde vermuten, dass die Nachrichten-Vorschau ohne diese Angabe im Allgemeinen nicht sehr nützlich ist?
Das ergibt Sinn, und ich stimme zu, dass es im Allgemeinen nützlich ist, etwas aussagekräftigen Vorschautext zu haben.
Das Problem, auf das die Benutzer anscheinend reagieren (zumindest in Outlook für iOS und ähnlichen Clients), ist, dass dieser Vorschautext nicht nur den Snippet im Posteingang beeinflusst – er wird visuell als Teil des Nachrichtentextes selbst gelesen und erscheint vor dem eigentlichen Inhalt. In der Praxis wirkt das eher repetitiv und störend als hilfreich.
Es gibt auch eine gewisse Spannung in der aktuellen Formulierung: Die anonyme Formulierung („Jemand hat geantwortet…“) ist aus Gründen des Datenschutzes und des Teilens von Screenshots hilfreich, aber im täglichen Gebrauch ist sie weniger informativ als vorschau-Texte, die den Absender berücksichtigen, da Benutzer hauptsächlich wissen wollen, wer geantwortet hat und ob dies Aufmerksamkeit erfordert.
Es geht also weniger darum, ob Vorschautext überhaupt existieren sollte, sondern darum, ob die aktuelle, ziemlich starre Implementierung das Leseerlebnis in einigen Clients oder Zustellpfaden beeinträchtigt. Ein client-sensitiver Ansatz oder eine unterstützte Möglichkeit, ihn neu zu positionieren oder zu deaktivieren, würde wahrscheinlich die meisten Beschwerden beheben, ohne den Vorteil verbesserter Vorschauen zu verlieren.