Vorrei richiedere una o due impostazioni del sito che permettano di configurare una “finestra temporale” e “giorni di digesto” quando le attività di invio dei digesto vengono messe in coda.
Il motivo di questa richiesta è che per la maggior parte dei siti, incluso il nostro, esiste un’area geografica predominante per gli utenti; ad esempio, il nostro è gli Stati Uniti, mentre altri potrebbero essere la Corea, il Brasile, la Germania, l’Australia o qualsiasi altra regione del pianeta.
L’invio delle email di digesto sarebbe più efficiente se potesse avvenire durante gli orari e i giorni lavorativi normali (per la principale base di utenti). Molti siti pagano per servizi di invio massivo come MailGun o SendGrid per inviare le email di digesto; quindi, far sì che queste email arrivino nella casella di posta dei membri “intorno alle” ad esempio “10:00 di lunedì” è molto meglio che arrivarci alle “3:00 di sabato”.
Queste attività vengono messe in coda, quindi avere una o due variabili di configurazione come “finestra temporale di coda per il digesto” e “giorni consentiti per la coda del digesto” renderebbe più efficiente la spesa sostenuta per l’invio delle email di digesto.
Ho cercato nel codice principale su GitHub e non ho trovato alcun modo per impostare questi parametri importanti. Li ho forse persi?
Grazie per aver preso in considerazione questa richiesta!
Di default, Discourse invia il sommario alla stessa ora in cui l’utente completa un periodo di inattività di 7 giorni, il che significa che l’email sarà allineata a un periodo in cui l’utente era attivo sul sito. Questo è ottimo perché si adatta automaticamente a ogni utente e fuso orario.
Un problema molto comune riguarda le importazioni, in cui gli amministratori dimenticano di disabilitare i sommari per gli utenti importati o dimenticano di importare l’ultima ora di attività nei dati importati, impostando tutto a mezzanotte.
LOL. Hai centrato il problema alla perfezione! I nostri utenti importati avevano l’ultima attività impostata al momento dell’importazione in Discourse dal nostro vecchio sito vB.
Nel nostro caso, gli script di Discourse che abbiamo utilizzato non lo facevano; e non possiamo “dimenticare” di fare qualcosa di cui non avevamo la minima idea in primo luogo, LOL.
Come si dice, la saggezza arriva sempre in ritardo.
Non credo che la maggior parte degli utenti che migrano per la prima volta a Discourse da un forum legacy possa “dimenticare” le funzionalità dei digest di Discourse prima ancora di conoscerne i dettagli
Non è una grande cosa. Ma come dici tu stesso:
Quindi, la funzionalità che sto richiedendo aiuterebbe a mitigare il problema per i forum migrati, quelle “anime senza supporto” che si trovano nel cyberspazio e che generalmente sono “da sole” quando migrano un forum su Discourse
Dato che, immagino, questo “problema comune” non verrà risolto, potresti per favore postare un link al codice nel repository dove posso scrivere un plugin per applicare una patch a questo problema per noi anime perse nella migrazione che “abbiamo dimenticato di fare qualcosa” prima ancora di “sapere che avevamo bisogno di farlo”?
O forse, meglio non preoccuparsene: invece di applicare una patch, scriverò uno script Ruby per modificare semplicemente l’orario dell’“ultima attività” degli utenti migrati, impostandolo su un orario durante l’orario di lavoro normale (basta aggiungere 10 ore alla mezzanotte ed è fatto!)
Ho appena aggiornato tutti questi utenti legacy in modo che le loro date/orari last_seen_at corrispondano alle 10:00 EST.
In base a come ho interpretato la tua risposta, questo metterà in coda le email di sommario per circa quell’ora del mattino, le 10:00.
Corretto?
Aggiornamento:
Hmmm. Non sembra funzionare. Dopo aver impostato le date-orari last_seen_at alle 10:00 EST, sidekiq sta mettendo in coda i sommari ora, poco dopo la mezzanotte EST; e i log di invio email del pannello di amministrazione mostrano che i sommari vengono inviati anch’essi ora.
Questa “allineamento magico dell’ultima attività” all’ora in cui vengono inviati i sommari non sembra funzionare come descritto sul mio sistema.
