It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
hi @joebuhlig and @pfaffman,
thanks for your replies. but i don’t really get it and maybe you can help me out:
what settings would I need to change to change the current behaviour (ALL topics are included in the daily summary even if the reached the user already during the day because the watch the category)?
thanks in advance,
etienne
If I understand correctly, all you need to do is turn off the mailing-list-mode-daily-summary plugin.
The thiing is that the summary might not include ALL of the posts for the day, it chooses just the top 5 or something. You can see what the normal summary looks like at (something like) /admin → email → summary.
ah - now i get what you are telling me.
as we need ALL messages to get to our users in the daily summary using the build-in function is not an option. it does not send out all messages.
thats why we are using the mailing-list-mode-daily-summary plugin in the first place.
but now we are getting comments from users about getting messages twice: first as mail during the day because they are watching a topic and then later in the mlm-daily-summary again.
but probably it is not consistent with the idea of a daily SUMMARY to exclude certain messages (that have been send to the user already). so users have to get used to getting things twice i guess.
If your users watch the categories that they want they will get all of the messages. They do get each one individually rather than a single message with all of them.
People who watch a category or visit the site regularly don’t need mailing list mode or the plugin.
Sounds like you have a conflict between the staff’s desires and the users’ desires. Staff wants everyone to see everything, but the users only want to see a summary.
I’m guessing you’ll need to rectify that discrepancy first.
yes, you are right @joebuhlig. we’ll decide on that in the team.
as for your proposal of paying 200$ for the bugfixes: we are discussing that tomorrow in a team-meeting. will let you know.
hi @joebuhlig,
sorry - i forgot to tell you earlier: i couldnt bet through with my proposal of paying you guys for fixing the bug. so we would wait for you and your team to find time to fix it.
we are looking forward to seeing the bug fixed.
best, etienne
Ciao @joebuhlig e agli altri che utilizzano questo plugin: sta riscontrando problemi anche qualcun altro con questo plugin dalla versione 2.3.0 di Discourse? Quando il nostro hosting ci ha aggiornato alla versione 2.3.0 un paio di settimane fa, le email giornaliere hanno smesso di essere inviate. Inoltre, quando visito la schermata delle preferenze email di un utente, la casella di controllo per questa opzione email non viene salvata. Puoi cliccarla e salvare, ma quando ricarichi la pagina, risulta deselezionata. Sono solo curioso di sapere se qualcuno ha trovato un modo per risolvere questi problemi. Grazie mille se qualcuno ha qualche indicazione!
Ciao Leah, controlla il mio post precedente del 29 gennaio e verifica se anche il tuo problema potrebbe essere correlato alla voce in user_custom_fields? Saluti, Etienne
Ho alcune novità e mi piacerebbe sapere da chiunque altro stia usando questo plugin come funziona al momento. Abbiamo centinaia di persone iscritte alle email giornaliere, quindi siamo ottimisti di riuscire a far funzionare di nuovo questo plugin.
@etienne, grazie per aver condiviso le tue osservazioni su true/false (vero/falso). Abbiamo fatto analizzare la cosa da qualcuno e ha detto che il codice sembra gestirlo correttamente. Quindi, per la nostra situazione, sono ancora confuso sul perché alcuni utenti non ricevano le email giornaliere mentre altri le ricevano solo ogni pochi giorni. Abbiamo sicuramente nuovi argomenti e nuovi post ogni giorno, quindi questa email dovrebbe essere inviata ogni giorno.
Il nostro sviluppatore WordPress (che non è davvero un esperto di Discourse/Ruby, per così dire, ma solo qualcuno disposto a esaminare il problema) è riuscito a risolvere l’errore JS lato front-end che causava problemi al salvataggio della casella di controllo.
Un’altra cosa che vorrei sapere da chiunque stia usando questo plugin è questa: sospetti che ci siano problemi con questo plugin che causa crash e blocca tabelle in modo problematico? Abbiamo un altro misterioso problema con il nostro forum e una teoria è che questo plugin possa esserne la causa a causa di tabelle bloccate che non vengono sbloccate, ma non abbiamo ancora accertato questo con certezza.
Ehi,
Ho aggiornato il mio Discourse alla versione 2.4.0 beta2. Da allora, questo plugin non funziona più.
Al momento, il mio codice di errore in Sidekick è
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined methodapply_notification_styles’ for #UserNotifications:0x00007f1437382668`
Spero che questo plugin venga riparato presto.
Anche noi stiamo riscontrando questo problema.
Probabilmente perché stiamo unificando tutti gli stili delle email per renderle più personalizzabili, grazie a @neil.
Ho appena ricostruito, quindi questo è con l’ultima versione v2.4.2.beta2 di Discourse:
Ieri abbiamo disabilitato il plugin mlm-daily e svuotato la coda dei tentativi. Continuiamo a vedere errori in /logs e i tentativi continuano ad accumularsi in Sidekiq:
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined method 'apply_notification_styles' for #<UserNotifications:0x00007f6f971b9168>
Sembra che questo riguardi tutte le notifiche, non solo i riassunti giornalieri. Esiste una soluzione alternativa che possiamo implementare fino al completamento della revisione degli stili delle email?
Grazie,
Gunnar
Ciò è dovuto a un plugin di terze parti che stai utilizzando. Dovrai aggiornare quel plugin o disabilitarlo.
Anche nella nostra installazione (2.4.0 beta4) vediamo questo errore. C’è qualcosa che devo aggiornare per risolvere il problema?
Inoltre, quando gli utenti cercano di abilitare la Modalità Mailing List nelle loro impostazioni personali, la modifica viene salvata (almeno l’interfaccia lo indica), ma quando si riapre la finestra delle impostazioni, la casella di controllo viene di nuovo deselezionata. Di conseguenza, non riusciamo più a far inviare a questo plugin le email di riepilogo giornaliere. Non sono sicuro che questo abbia a che fare con il messaggio Jobs::HandledExceptionWrapper menzionato sopra, ma immagino di no.
C’è qualcosa che potrei fare per risolvere il problema?
Dirk
Qualcuno deve aggiornare il plugin per risolvere il problema. Puoi leggere gli argomenti howto dello sviluppatore del plugin o pubblicare nel Marketplace se hai un budget.
Ciao @joebuhlig.
Sei ancora disposto a lavorare su questo plugin, aggiornarlo per la prossima versione di Discourse 2.4 e correggere il bug descritto in precedenza a pagamento? Se ci comunichi un prezzo (avevi indicato 200$ per la correzione del bug all’inizio di quest’anno), ne discuteremo nel nostro team.
Grazie per avercelo fatto sapere.
Etienne
Questo non è davvero un aggiornamento per il Plugin, ma piuttosto una correzione rapida. Non corregge effettivamente il plugin per farlo funzionare con il nuovo sistema, ma integra invece parti che erano state rimosse nel Plugin. Non è progettato per il futuro. E di certo non risolverà il fatto che il team di Discourse abbia considerato i riassunti giornalieri un caso limite non necessario, piuttosto che una parte importante per mantenere aggiornati gli utenti che preferiscono le e-mail. Discourse non può più essere utilizzato come sostituto di una mailing list e, se possibile, dovreste spostarvi. Non risolverà nemmeno la questione del “non abbiamo bisogno di documentazione o note di rilascio corrette”.
Detto questo, lo stiamo utilizzando in produzione e sembra funzionare. Non è buono, ma tant’è.
Ora puoi effettivamente riattivare di nuovo il pulsante dell’interfaccia utente.
def apply_notification_styles(email) email.html_part.body = Email::Styles.new(email.html_part.body.to_s).tap do |styles| styles.format_basic styles.format_html end.to_html email
Nota che la funzione originale (vedi il commit che ha rotto tutto per approfondire) utilizzava styles.format_notification invece di styles.format_html, dato che _notification è stato rimosso, stiamo semplicemente utilizzando _html. È una buona idea? No. Funziona? Sembra di sì. Ehi, almeno abbiamo una leggera possibilità che non venga rimosso con il prossimo aggiornamento.
Ho anche avvolto l’intero file mailing_list.html.erb in un tag Div con la classe summary-email e disabilitato il tema per le e-mail di riassunto nelle impostazioni. Questo era solo un tentativo disperato all’inizio e non ha prodotto risultati. Probabilmente starai bene senza di esso, ma non toccherò più questo pasticcio a meno che non si rompa di nuovo. Quindi, se incontri problemi di formattazione, sentiti libero di provare questa soluzione.
Spero che questo aiuti