I’ve just migrated a large number of posts from MyBB and there were many jobs scheduled. I was using Gmail’s SMTP to send emails (our forum is low volume). The migration seems to have triggered digest email jobs ({"type"=>"digest", "user_id"=>4889, "current_site_id"=>"default"}), and this triggered Gmail’s STMP rate limiting:
Job exception: Wrapped Net::SMTPAuthenticationError: 454 4.7.0 Too many login attempts, please try again later. ow2sm11059574pdb.14 - gsmtp
Would it be possible to not trigger the digest after migration, since it doesn’t exactly make sense to email users of all the “new” posts?
I don’t recall having this problem for other migrations we’ve done for customers, so I am not convinced this is a “bug”. But we’ll take a look, I guess.
Digests have been actually triggered. I’m receiving autoresponders from people on vacation etc. Glad I was using Gmail and didn’t spam absolutely everyone.
I’ve just checked disable digest emails but that should be a big warning before migration. Maybe add it as a comment in the migration script?
The digest mails aren’t sent during the import, they are sent after the import.
During the import all emails are disabled, but as soon as the import is finished and Discourse is started, it sees a bunch of users that haven’t visited the forum for a certain amount of time and begins to send digest emails.
A quick solution would be to not automatically enable emails after the import (still it would send the digest mails as soon as emails would be enabled). A better solution would be some sort of grace period after an import where no digest emails should be sent, but I guess that’s not possible at the moment.
I don’t run imports on production servers with sidekiq running, emails being sent, etc. You definitely want to see what the imported data looks like before going into production with it. Every import is a special snowflake with its own surprises and requirements.
If you are running an import onto a live production site, disable emails in settings, or add this to the initialize method of your script:
Mi rendo conto che questo è un thread vecchio, ma ho appena riscontrato questo problema, che ha causato l’invio di email agli utenti da parte di un server di migrazione destinato solo ai test.
La prima cosa che vorrei chiedere è se ci siano stati cambiamenti in questo senso negli ultimi anni.
Un altro problema è che non sono sicuro della migliore strategia da adottare. Posso disabilitare tutte le email e anche i riassunti, ma d’altra parte voglio ricevere le email amministrative di Discourse e permettere ad alcuni membri del mio team di iniziare a utilizzare Discourse. In particolare, voglio garantire un’esperienza utente corretta per quanto riguarda i login, la convalida delle email degli utenti, l’obbligo di cambiare le vecchie password migrate con password più complesse, ecc. - e tutto ciò richiede l’invio di email.
Una volta raggiunto questo obiettivo, immagino che vorrò anche ricevere dei riassunti di prova per un piccolo gruppo di utenti, per vedere come appaiono e sperimentare opzioni e design.
Quindi, come posso evitare email indesiderate, ma allo stesso tempo ricevere alcune email per valutare correttamente la migrazione? Grazie in anticipo per qualsiasi consiglio.
Penso che quello di cui sto parlando sia un modo per creare una lista bianca di indirizzi email che possa essere applicata durante una migrazione…
C’è qualcosa che non va nella tua migrazione, perché tutti i nostri strumenti mettono sempre il sito in modalità senza email o solo email per lo staff, e lo fanno da anni.
Sto utilizzando uno script basato su kunena3.rb e le modifiche apportate non sono relative alle email. Potrei star usando una versione di quello script di alcuni mesi fa, ma sicuramente non di anni fa.
Sì, c’è un’unica impostazione del sito che disabilita completamente le email o le imposta solo per lo staff. Le migrazioni impostano sempre questa opzione.
Scorri verso l’alto nel topic per vedere quale sia l’impostazione ↑ ↑
La mia impostazione al momento dell’arrivo era no disable, il che significa abilitato
Ma il mio script non tocca questa impostazione; e in base.rb è impostata su yes. Quindi al momento non ho alcuna spiegazione su come le email siano state abilitate (o non disabilitate)
Ho anche controllato il codice dell’unico plugin che sto usando, discourse-migratepassword, ma non c’è alcun riferimento a questa opzione nemmeno lì.
Nessuna risposta necessaria: il mio problema è risolto, grazie per questo. Mi chiedo ancora cosa sia successo, ma al momento è una preoccupazione minore.
