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

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، وأرغب تحديدًا في ضمان تجربة مستخدم صحيحة من حيث تسجيل الدخول، والتحقق من عناوين البريد الإلكتروني للمستخدمين، ومتطلبات تغيير كلمات المرور القديمة المحولة إلى كلمات مرور أكثر تعقيدًا، وما إلى ذلك - وهذا يتطلب البريد الإلكتروني.

بمجرد تحقيق ذلك، أعتقد أنني سأرغب أيضًا في الحصول على ملخصات بريد إلكتروني تجريبية لمجموعة صغيرة من المستخدمين، لأرى كيف تبدو ولأستكشف الخيارات والتصاميم.

إذًا، كيف يمكنني منع الرسائل غير المرغوب فيها مع الحفاظ على إمكانية تلقي بعض الرسائل الإلكترونية لتقييم عملية الهجرة بشكل صحيح؟ شكرًا مقدّمًا على أي نصيحة.

أظن أن ما أتحدث عنه هنا هو طريقة لاختراق قائمة بريد إلكتروني بيضاء يمكن فرضها أثناء الهجرة…

يبدو أن هناك مشكلة في عملية الهجرة الخاصة بك، حيث أن جميع أدواتنا تضع الموقع دائمًا في وضع عدم إرسال البريد الإلكتروني أو وضع البريد الإلكتروني للموظفين فقط، وقد فعلت ذلك لسنوات.

أنا أستخدم سكريبتًا مبنيًا على سكريبت kunena3.rb، والتغييرات التي قمت بها لا تتعلق بالرسائل الإلكترونية. قد أكون أستخدم إصدارًا من ذلك السكريبت يعود إلى بضعة أشهر، ولكن بالتأكيد ليس إصدارًا يعود إلى سنوات.

هذا ما أراه في السجلات

هل يمكن أن يكون الأمر متعلقًا بمستخدمين فرديين، مثل علامة تفعيل؟ أم أنك تشير إلى خيارات على مستوى النظام؟

شكرًا لك.

نعم، يوجد إعداد موقع واحد يعطل البريد الإلكتروني تمامًا أو يحدده للموظفين فقط. عمليات الترحيل دائمًا تقوم بتعيين هذا الإعداد.

مرر للأعلى في الموضوع لمعرفة ما هو هذا الإعداد ↑ ↑

إذًا، ها هو الأمر…


أو من خلال الكود:

SiteSetting.disable_emails = "non-staff"

كان إعدادي عند وصولي هو لا تعطيل، مما يعني تم التفعيل :scream:

لكن سكريبت الخاص بي لا يلمس هذا الإعداد؛ وفي base.rb مضبوط على نعم. لذا، ليس لدي حاليًا أي تفسير لكيفية تفعيل البريد الإلكتروني (أو فشله في التعطيل) :thinking:

حتى قمت بفحص كود الإضافة الوحيدة التي أستخدمها، وهي discourse-migratepassword، لكن لا يوجد ذكر لهذا الخيار هناك أيضًا.

لا حاجة للرد - تم حل مشكلتي، شكرًا على ذلك، وأنا ما زلت أتساءل عما حدث، لكن هذا مصدر قلق ثانوي في هذه المرحلة.