Ho notato che sotto Admin|Emails|Sent un’email digest non è stata inviata agli utenti, ma hanno tutti ricevuto un’email per user_watching_first_post (secondo un’impostazione predefinita.)
Ho verificato che non sia il caso che questi utenti abbiano visitato di recente, siano oltre l’impostazione “sopprimi email digest dopo giorni” o abbiano modificato le loro preferenze email.
È corretto che un’email di notifica venga trattata come attività dell’utente, causando il salto del digest? Se è così, non è il comportamento che mi aspettavo…
Stiamo usando “watching first post” per un tag specifico per notificare agli utenti argomenti ad alta priorità, ma vogliamo comunque che ricevano il digest regolare delle altre attività del forum.
Questo è piuttosto centrale per la nostra visione — sarei lieto di ricevere qualsiasi input su come renderlo possibile.
Quindi è il caso che ricevere una notifica via email su un argomento impedisca all’argomento di apparire nel riepilogo? Ha senso che tu non voglia ricevere nel riepilogo un messaggio che ti è già stato inviato via email in un altro modo.
È molto più di questo. Ricevere una notifica via email sembra resettare completamente il conteggio in modo che nessun argomento più vecchio della notifica venga inserito nel riepilogo. Questo mi ha sempre infastidito.
In sostanza, se l’utente notificato via email non visita il sito, c’è zero esposizione di argomenti tra il riepilogo precedente e l’ultima notifica via email. E fa sembrare il sito molto più tranquillo di quanto non sia in realtà quando finalmente arriva un riepilogo.
Mi piacerebbe vederlo come suggerisci tu, dove solo gli argomenti notificati vengono soppressi nel riepilogo per gli utenti che ricevono una notifica via email ma non visitano il sito. Sarebbe un enorme miglioramento per i siti che fanno un bel po’ di “default watching”!!
Grazie per la conferma, Nathan. Sì, un digest non è stato inviato nonostante altri argomenti idonei e nuovi.
Se il digest evitasse solo di duplicare l’argomento altrimenti notificato, avrebbe senso, ma quello che sta facendo sembra davvero una svista o un bug che è piuttosto controproducente.
@pfaffman - ti sembra una regola che potrebbe essere modificata in qualche modo? O avrebbe bisogno dell’attenzione degli sviluppatori?
Ci vorrebbe un plugin. Ne ho scritto uno una volta che almeno una volta pretendeva di “aggiungere il numero di nuovi post all’email di riepilogo/digest in 3a posizione (di solito dove si trovano i nuovi utenti)”. Quindi cambia solo quell’intestazione in cima alla pagina.
Sovrascrive l’intero template, quindi è una potenziale soluzione.
Dopo ulteriore riflessione, questo sembra davvero un bug e non qualcosa da risolvere con un plugin. Devo credere che il comportamento non sia intenzionale.
Le impostazioni del sito includono opzioni per sopprimere il digest, ma nessuna riguarda altre notifiche via email:
sopprimi email digest dopo giorni
categorie di soppressione del digest
tag di soppressione del digest
Ancora più importante, la preferenza dell’utente per Email|Riepilogo attività è: “Quando non visito qui, inviami un riepilogo via email degli argomenti più popolari e delle risposte.” – Sì o no, punto. Nessuna relazione con le email di tracciamento è indicata.
Sulla base di queste impostazioni, gli utenti dovrebbero aspettarsi che l’impostazione Riepilogo attività si applichi come descritto e in modo indipendente.
Sopprimere gli argomenti notificati dal digest del riepilogo sarebbe fantastico, ma lo considererei un lusso. Solo rendere il digest ignaro delle notifiche email di tracciamento lo porterebbe in linea con le aspettative.
Sto navigando in acque troppo profonde qui, ma per curiosità sto guardando il codice su Github…
Nella sezione digest di app/mailers/user_notifications.rb, topics_for_digest vengono cercati in base a una min_date che considera user.last_emailed_at
riga 227:
min_date = opts[:since] || user.last_emailed_at || user.last_seen_at || 1.month.ago
# Fetch some topics and posts to show
digest_opts = {
limit: SiteSetting.digest_topics + SiteSetting.digest_other_topics,
top_order: true,
}
topics_for_digest = Topic.for_digest(user, min_date, digest_opts).to_a
if topics_for_digest.empty? && !user.user_option.try(:include_tl0_in_digests)
# Find some topics from new users that are at least 24 hours old
topics_for_digest =
Topic
.for_digest(user, min_date, digest_opts.merge(include_tl0: true))
.where("topics.created_at < ?", 24.hours.ago)
.to_a
end
(Modifica: vedo che last_emailed_at è anche referenziato in app/jobs/scheduled/enqueue_digest_emails.rb e spec/jobs/enqueue_digest_emails_spec.rb tra le altre cose.)
Questo mi fa pensare che un digest semplicemente non venga generato per gli utenti il cui user.last_emailed_at è troppo recente.
Non sono riuscito a capire quali email contano per last_emailed_at. Evidentemente include notifiche basate sulle impostazioni di Tracking, ma i messaggi privati, ecc..?
Il digest non dovrebbe occuparsi solo di user.last_seen_at?
Attualmente, quando la modalità mailing list è abilitata, almeno a livello di preferenze utente (vedi post successivo), l’interfaccia chiarisce che le impostazioni del digest vengono sovrascritte.
Quindi, forse l’unica cosa da aggiungere sarebbe un “invia sempre”, ad esempio:
Riepilogo attività:
Invia sempre un digest via email
Invia un digest via email solo quando non visito qui
(Menu a tendina): ogni 30 minuti | ogni ora | giornalmente | settimanalmente | ogni mese | ogni sei mesi
Ma considererei l’opzione “invia sempre” come un “nice-to-have”. Solo rendere il digest indipendente dalle altre email sembrerebbe farlo funzionare come previsto.
(Nota a margine: se avessi un forum di grandi dimensioni, potrei desiderare che gli intervalli di tempo disponibili fossero configurabili dall’amministratore. Troppe persone che scelgono “invia sempre… ogni 30 minuti” potrebbero aumentare i costi delle email.)
Questo è secondario rispetto al problema segnalato, ma si collega alla preoccupazione di Sam riguardo alla modalità Mailing List vs. Riepilogo Attività…
È interessante notare che quando l’amministratore abilita la “modalità mailing list email predefinita” e “disabilita la modalità mailing list” (Scenario A), non è chiaro cosa succeda. L’utente non vede nulla riguardo alla modalità Mailing List e può apparentemente ancora abilitare il Riepilogo Attività e altre email.
Le due impostazioni dell’amministratore sembrano essere indipendenti, quando forse c’è una dipendenza… “impedire agli utenti di abilitare la modalità mailing list” ha la precedenza su “modalità mailing list predefinita”?
Tuttavia, se l’amministratore lascia deselezionata l’opzione “disabilita modalità mailing list”, l’utente vede che è stato impostato per default su “Modalità mailing list abilitata”. Questo sembra abbastanza chiaro.
Quindi sembra mancare qualcosa nello Scenario A che indichi se la modalità Mailing List è effettivamente attiva. (A meno che non sia io a non vederla.)
Grazie per l’aggiornamento, Sam. Vorrei avere le capacità per sviluppare e offrire una PR.
Dato il numero di correzioni e miglioramenti nelle note di rilascio, posso solo immaginare come sia il backlog. Ma spero che questo meriti attenzione: gli utenti non hanno motivo di sospettare che il riepilogo non li terrà aggiornati in modo affidabile.
Ehi @ToddZ — mi scuso per il silenzio da parte mia. Grazie per aver sollevato la questione.
Concordo con @sam sul fatto che ricevere una notifica non dovrebbe contare come una visita che ti impedirebbe di ricevere un’email di riepilogo delle attività. Lavorerò con il team per risolvere il problema e ti farò sapere una volta che avremo risolto la questione, anche se al momento non ho una data di consegna da condividere.
