Improvvisamente, dopo l’ultimo aggiornamento, Discourse invia email con:
“Someone replied to a topic you are Watching.” (Qualcuno ha risposto a un argomento che stai seguendo.) a prefazione di ogni email. Tutti i miei utenti si lamentano pesantemente e nessuno ha modificato le impostazioni email.
Tutti dicono che è molto fastidioso.
Quindi, cosa è successo e come possiamo disattivarlo e tornare al normale comportamento semplice? Non penso che sia stato ben implementato e lo sviluppatore non si è nemmeno preoccupato di controllarlo, dato che “watching” è scritto con una W maiuscola non necessaria.
Penso che la fonte di fastidio per i membri della comunità di Andrew sia %{header_instructions}.
Questo token si espande in un blocco di testo standard piuttosto grande (“non rispondere…”, link, istruzioni, ecc.) e appare all’inizio del corpo dell’email in molti modelli di notifica. Per gli utenti esperti, domina il messaggio e suona come un rimprovero piuttosto che come un aiuto.
Attualmente non esiste un’impostazione a livello di sito per disattivarlo o riposizionarlo. Per rimuoverlo, un amministratore deve modificare ogni modello di email individualmente in Amministrazione → Email → Modelli.
Sull’attuale latest-release (sono su latest-release +17), dovrebbe essere possibile affrontare questo problema centralmente con uno script Rails per i modelli che hanno già override nel database, ad esempio rimuovendo %{header_instructions} quando appare all’inizio del corpo. Questa parte è semplice e utilizza il modello EmailTemplate.
Applicare la stessa modifica a tutti i modelli predefiniti (inclusi quelli senza override esistenti) richiederebbe la creazione di override recuperando i corpi dei modelli predefiniti tramite API di ricerca interne. Ciò è fattibile, ma dipende dagli elementi interni di Discourse e richiederebbe la revisione/validazione da parte di un manutentore prima di essere raccomandato in modo diffuso.
Quindi, il problema di fondo non è solo il contenuto di %{header_instructions}, ma il fatto che sia di fatto un testo standard globale senza un interruttore a livello di amministratore, e rimuoverlo o spostarlo richiede un lavoro manuale per modello o uno scripting non supportato.
@Ethsim2 grazie, è davvero ottimo. Ma perché è cambiato improvvisamente? Non sono un esperto nel leggere o persino nel localizzare i registri delle modifiche.
La parte “improvvisamente” è perché %{header_instructions} non è qualcosa che hai modificato localmente: è un blocco fornito dal core che Discourse inserisce in diverse email di notifica. Se il core modifica il suo testo o il momento in cui viene incluso, tutti se ne accorgeranno immediatamente anche se non sono state toccate le impostazioni di nessun amministratore.
Non voglio esagerare senza un riferimento di commit specifico, ma la causa più probabile è una recente modifica del core al testo predefinito a cui %{header_instructions} si espande per le notifiche di argomenti seguiti (ad esempio, l’aggiunta della riga “Qualcuno ha risposto a un argomento che stai seguendo”), o al momento in cui quel blocco viene incluso nel corpo dell’email.
Come confermare da dove proviene:
In Admin → Email → Impostazioni Email → Modelli, controlla i modelli di notifica che i tuoi utenti ricevono (seguito / monitorato / risposto / menzionato).
Se il corpo inizia con %{header_instructions}, quella è la fonte del nuovo testo di prefazione.
Rimuoverlo, o spostarlo sotto %{message} / %{context} (o anche %{reply_instructions}), ripristinerà il precedente comportamento “semplice”.
Sfortunatamente, al momento non esiste un’opzione globale per questo. Ciascun modello interessato deve essere modificato individualmente, motivo per cui questo sembra brusco e difficile da controllare quando il comportamento del core cambia.
Se utilizzi Discourse ospitato, la soluzione pratica è semplicemente modificare la piccola manciata di modelli che i tuoi utenti ricevono effettivamente, piuttosto che tutti quanti.
Quindi in questo caso, il cambiamento improvviso che Andro sta riscontrando deriva dall’aggiunta recente di %{email_preview} (PR #36657), il che spiega perché sia apparso durante la notte senza alcuna modifica amministrativa.
Dal punto di vista dell’amministratore, il problema è simile in entrambi i casi: si tratta di contenuto iniettato nel core all’inizio del corpo dell’email, e attualmente non esiste un’opzione globale per disattivarlo o riposizionarlo. L’unica soluzione alternativa oggi è modificare i modelli di email interessati e rimuovere o spostare %{email_preview} (proprio come %{header_instructions}).
In particolare per i clienti con hosting, è per questo che sembra così brusco: le impostazioni predefinite sono cambiate, ma non esiste un controllo globale supportato.
Anche le stringhe di anteprima possono essere sovrascritte: puoi cercare la stringa specifica o .preview e poi usare Ctrl-F per cercare user_notifications per trovarle.
Dal messaggio di commit:
Per le email html questa anteprima di testo è nascosta con display: none per evitare che appaia all’interno del corpo dell’email. Per la versione in testo semplice dell’email apparirà all’interno del corpo dell’email.
A quali utenti sta apparendo questo messaggio? Non dovrebbe.
Nel mio client di posta elettronica, vedo nel sorgente:
<div> class="email-preview" style="display:none"><p>Someone sent you a PM.</p></div>
ed è nascosto sia in Thunderbird che in Gmail (web).
Per riferimento, ecco come il nuovo testo di anteprima sta apparendo in Outlook per iOS per me: non è solo uno snippet della posta in arrivo; diventa la prima riga visibile associata al messaggio, a cui gli utenti stanno reagendo.
Ciò sembra coerente con l’aggiunta recente di %{email_preview}: anche se inteso come testo di pre-intestazione nascosto per le email HTML, in pratica è molto visibile agli utenti (almeno in alcuni client/percorsi di consegna), il che spiega le improvvise lamentele.
Questo è probabilmente intenzionale poiché fa emergere la ragione dell’email nell’anteprima del messaggio. Mi azzarderei a supporre che senza di essa, l’anteprima del messaggio non sia generalmente utile?
Questo ha senso, e sono d’accordo che avere un po’ di testo di anteprima significativo sia generalmente utile.
Il problema a cui gli utenti sembrano reagire (almeno in Outlook per iOS e client simili) è che questo testo di anteprima non influenza solo lo snippet della posta in arrivo, ma viene visualizzato visivamente come parte del corpo del messaggio stesso, apparendo prima del contenuto effettivo. In pratica, questo risulta ripetitivo e rumoroso piuttosto che utile.
C’è anche una certa tensione nella formulazione attuale: la formulazione anonima (“Qualcuno ha risposto…”) è utile dal punto di vista della privacy e della condivisione di screenshot, ma nell’uso quotidiano è meno informativa delle anteprime che mostrano il mittente, poiché gli utenti vogliono principalmente sapere chi ha risposto e se richiede attenzione.
Quindi, la questione non è se il testo di anteprima debba esistere del tutto, ma se l’implementazione attuale, piuttosto rigida, degradi l’esperienza di lettura in alcuni client o percorsi di consegna. Un approccio sensibile al client, o un modo supportato per riposizionarlo o disattivarlo, probabilmente risolverebbe la maggior parte delle lamentele senza perdere il vantaggio di anteprime migliorate.
![Screenshot della posta di Outlook per iOS che mostra "Qualcuno ha risposto al tuo post." che appare in modo prominente sopra il contenuto del messaggio, con i prefissi FW/[PM] visibili](https://d11a6trkgmumsb.cloudfront.net/original/4X/9/1/f/91f715903dc7d1007a38043b45ed779ae5c6fe6d.jpeg)