Don't trigger digests on migration?

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.

Thanks. This is what I see right now:

and

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.

This is happening since @neil commited

which has been discussed in

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:

SiteSetting.disable_emails = true

and you’ll probably have other setting you’ll want to change.

Still, once emails are enabled, users will get digest emails right away. Couldn’t we add something like this to ImportScripts::Base#create_user:

opts[:last_emailed_at] = opts.fetch(:last_emailed_at, Time.now)

Понимаю, что эта тема старая, но я только что столкнулся с этой проблемой: письма пользователям отправлялись с тестового сервера миграции.

Сначала хочу спросить: не изменилось ли что-то в этом отношении за последние годы?

Далее, ещё одна проблема: я не уверен, какую стратегию лучше выбрать. Я могу отключить все письма и сводки, но с другой стороны мне нужны административные письма от Discourse, а также возможность для некоторых членов моей команды начать работать с Discourse. В частности, я хочу обеспечить правильный пользовательский опыт в плане входа в систему, подтверждения email-адресов пользователей, требований к смене старых мигрированных паролей на более сложные и т. д. — а для этого нужны письма.

После этого, думаю, я также хотел бы получать тестовые сводки писем для небольшой группы пользователей, чтобы посмотреть, как они выглядят, и поэкспериментировать с настройками и дизайном.

Итак, как предотвратить нежелательные письма, но при этом иметь возможность получать некоторые письма для правильной оценки миграции? Заранее спасибо за любые советы.

Кажется, о чём я говорю здесь, так это о способе обойти белый список адресов электронной почты, который можно было бы применять во время миграции…

Что-то не так с вашей миграцией, так как все наши инструменты уже много лет всегда переводят сайт в режим без рассылки писем или только для сотрудников.

Я использую скрипт, основанный на kunena3.rb, и внесённые мной изменения не связаны с электронной почтой. Возможно, я использую версию этого скрипта, которой несколько месяцев, но точно не ту, которой несколько лет.

Вот что я вижу в логах:

Может ли это быть связано с отдельными пользователями, например, с флагом активации? Или вы имеете в виду системные настройки?

Спасибо.

Да, существует одна настройка сайта, которая полностью отключает электронную почту или разрешает её только для сотрудников. При миграциях это всегда устанавливается.

Прокрутите тему вверх, чтобы узнать, что это за настройка ↑ ↑

Итак, вот что…


Или из кода:

SiteSetting.disable_emails = "non-staff"

Моя настройка по приезде была no отключено, то есть включено :scream:

Но мой скрипт не затрагивает эту настройку; а в base.rb она установлена в yes. Так что у меня пока нет объяснения, как письма оказались включены (или не были отключены) :thinking:

Я даже проверил код единственного используемого мной плагина discourse-migratepassword, но и там упоминания об этой опции нет.

Ответ не нужен — моя проблема решена, спасибо. Меня остаётся лишь удивлять, что произошло, но это сейчас уже не так важно.