Don't trigger digests on migration?

[dandv (Dan Dascalescu)]

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?

[codinghorror (Jeff Atwood)]

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.

[dandv (Dan Dascalescu)]

Thanks. This is what I see right now:

and

[dandv (Dan Dascalescu)]

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?

[gerhard (Gerhard Schlager)]

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
https://github.com/discourse/discourse/commit/de167165e3c133436397e122ab3348985aa582f9

which has been discussed in

Ning import script

It would be an improvement if the script would set the imported users default email settings to be the same defaults as any new user. Specifically the digest = weekly. At the moment, the import leaves the digest setting unselected. It’s asking a lot of the users in a migration to have to proactively change settings and opt-in to the digest.

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.

[neil (Neil Lalonde)]

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.

[elberet (Jens Maier)]

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)

[pgr]

これは古いスレッドだと承知していますが、ちょうどこの問題に遭遇しました。その結果、テスト目的のみで用意された移行サーバーからユーザーにメールが送信されてしまいました。

まずお伺いしたいのは、近年この点について変更があったかどうかです。

もう一つの課題は、ここで採用すべき最善の戦略がわからないことです。すべてのメール送信やダイジェストを無効にすることは可能ですが、一方でDiscourseの管理者向けメールを受け取りたいと考えています。また、チームのメンバーにDiscourseを試してもらい、特にログイン、ユーザーのメール認証、移行された古いパスワードをより複雑なものに変更する必要があるといった要件など、ユーザーエクスペリエンスを適切に整えたいと考えています。これらにはメール機能が必要です。

それが達成できれば、次には少数のユーザーに対してテスト用のメールダイジェストを送信し、その表示やオプション、デザインの調整を試してみたいと考えています。

つまり、不要なメールは阻止しつつ、移行を適切に評価するために必要なメールだけは受け取れるようにする方法は何か、というご質問です。ご助言をいただき、ありがとうございます。

私がここで言いたいのは、移行中に強制できるメールアドレスのホワイトリストをどのように設定（あるいは「ハック」）すればよいか、ということだと思います。

[codinghorror (Jeff Atwood)]

移行に何らかの問題があるようです。なぜなら、当社のすべてのツールは長年、サイトを「メール送信なし」または「スタッフ限定メール送信」モードに設定するように設計されているからです。

[pgr]

kunena3.rb スクリプトをベースにしたスクリプトを使用していますが、私が変更した部分はメールとは関係ありません。そのスクリプトの数ヶ月前のバージョンを使用している可能性はありますが、数年前のバージョンを使用しているわけではありません。

ログには以下が表示されています。

これは、アクティベーションフラグのような個々のユーザーに関連する問題でしょうか？それとも、システム全体のオプションのことをおっしゃっているのでしょうか？

ありがとうございます。

[codinghorror (Jeff Atwood)]

はい、メールを完全に無効にするか、スタッフのみが使用できるようにする単一のサイト設定があります。移行では、常にこの設定が適用されます。

その設定が何かを確認するには、トピックを上にスクロールしてください↑ ↑

[pgr]

さて、これがその内容です…

またはコードから:

SiteSetting.disable_emails = "non-staff"

私がアクセスした時点での設定は no（無効化しない）つまり enabled（有効）でした

しかし、私のスクリプトはこの設定を変更していません。また、base.rb では yes に設定されています。そのため、なぜメールが有効になったのか（あるいは無効化されなかったのか）、今のところ説明がつきません

使用している唯一のプラグイン discourse-migratepassword のコードも確認しましたが、このオプションに関する言及はありませんでした。

返信は不要です。問題は解決しましたので、ありがとうございます。何が起きたのかは気になりますが、現時点ではさほど重要な問題ではありません。