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:
Percebo que este é um tópico antigo, mas acabei de me deparar com esse problema, que fez com que e-mails fossem enviados aos usuários a partir de um servidor de migração que era apenas um teste.
A primeira coisa que gostaria de perguntar é: algo mudou a esse respeito nos últimos anos?
Outro problema é que não tenho certeza sobre a melhor estratégia a adotar aqui. Posso desativar todos os e-mails e também os resumos, mas, por outro lado, quero receber os e-mails administrativos do Discourse e permitir que alguns membros da minha equipe comecem a usar o Discourse. Em especial, quero garantir uma boa experiência do usuário no que diz respeito a logins, validação de e-mails de usuários, exigência de alteração das senhas antigas migradas para algo mais complexo, etc. — e isso requer e-mail.
Uma vez que isso seja resolvido, imagino que também gostaria de receber resumos de e-mail de teste para um pequeno grupo de usuários, para ver como eles se apresentam e brincar com as opções e o design.
Então, como posso evitar e-mails indesejados, mas ainda assim ter a possibilidade de receber e-mails para avaliar adequadamente a migração? Agradeço antecipadamente qualquer conselho.
Acho que o que estou falando aqui é uma maneira de criar uma lista branca de endereços de e-mail que possa ser aplicada durante uma migração…
Algo está errado com sua migração, pois todas as nossas ferramentas sempre colocam o site no modo ‘sem e-mail’ ou ‘apenas e-mail para equipe’, e isso vem acontecendo há anos.
Estou usando um script baseado no kunena3.rb, e as alterações que fiz não estão relacionadas a e-mails. Posso estar usando uma versão desse script com alguns meses de idade, mas certamente não uma versão de anos atrás.
Sim, existe uma única configuração do site que desabilita completamente o e-mail ou o define apenas para a equipe. Migrações sempre definem essa configuração.
Role para cima no tópico para ver qual é essa configuração
Minha configuração, quando cheguei lá, era no para desativar, ou seja, ativado
Mas meu script não mexe nessa configuração; e em base.rb ela está definida como yes. Então, atualmente, não tenho explicação para como os e-mails foram ativados (ou falharam em ser desativados)
Até verifiquei o código do único plugin que estou usando, discourse-migratepassword, mas não há menção a essa opção lá também.
Não é necessário responder — meu problema está resolvido, obrigado por isso. Fico apenas me perguntando o que aconteceu, mas isso é uma preocupação menor no momento.
