Don't trigger digests on migration?

支持 迁移
1

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?

2

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.

3

Thanks. This is what I see right now:

Pasted image1232×686 52.7 KB

and

Pasted image1255×498 46 KB

4

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?

5

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.

6

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.

7

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)
9

我意识到这是一个旧帖子，但我刚刚遇到了这个问题，导致一封邮件被从本应仅用于测试的迁移服务器发送给了用户。

首先我想问的是，近年来这方面是否有任何变化？

另一个问题是，我不确定这里应采取的最佳策略。我可以禁用所有邮件，也可以禁用摘要邮件，但另一方面，我希望接收 Discourse 的管理员邮件，并让我的团队中的一些成员开始使用 Discourse。特别是，我希望在登录、用户邮箱验证、要求用户将旧的迁移密码更改为更复杂的密码等方面，确保良好的用户体验——而这些都需要邮件支持。

一旦实现这一点，我想我还会希望为一个小群体用户发送测试用的邮件摘要，以便查看其外观并尝试各种选项和设计。

那么，如何既能阻止不需要的邮件，又能保留接收部分邮件的机会，以便我能够正确评估迁移过程呢？提前感谢任何建议。

我想我在这里讨论的是一种方法，可以在迁移期间强制实施一个邮箱白名单的“变通方案”。

10

您的迁移似乎存在问题，因为我们的所有工具多年来一直将网站设置为“无邮件”或“仅限员工邮件”模式。

11

我正在使用基于 kunena3.rb 脚本的脚本，我所做的更改与电子邮件无关。我可能使用的是几个月前版本的该脚本，但肯定不是几年前的版本。

我在日志中看到的是：

image
image1489×139 35.3 KB

这是否与个别用户有关，比如激活标志？还是您指的是系统范围的选项？

谢谢。

12

没错，有一个站点设置可以完全禁用电子邮件，或将其限制为仅限工作人员使用。迁移操作 总是 会设置此项。

向上滚动话题以查看该设置是什么 ↑ ↑

13

所以事情是这样的……

image
image789×110 9.29 KB

或者从代码来看：

SiteSetting.disable_emails = "non-staff"

我接手时的设置是 no 禁用，也就是说 已启用 :scream:

但我的脚本并没有修改这个设置；而且在 base.rb 中它被设为 yes。所以我目前无法解释邮件是如何被启用（或未能被禁用）的 :thinking:

我甚至检查了我正在使用的唯一插件 discourse-migratepassword 的代码，那里也没有提到这个选项。

无需回复——我的问题已经解决了，谢谢。我虽然好奇到底发生了什么，但这目前只是个小问题。