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)

Mir ist bewusst, dass dies ein alter Thread ist, aber ich bin gerade auf dieses Problem gestoßen, das dazu führte, dass E-Mails an Benutzer von einem Migrations-Server gesendet wurden, der eigentlich nur als Test gedacht war.

Als Erstes möchte ich fragen, ob sich diesbezüglich in den letzten Jahren etwas geändert hat?

Ein weiteres Problem ist, dass ich mir unsicher bin, welche Strategie hier am besten ist. Ich kann zwar alle E-Mails und auch Zusammenfassungen deaktivieren, aber andererseits möchte ich E-Mails von der Discourse-Administration erhalten und einigen Mitgliedern meines Teams ermöglichen, Discourse auszuprobieren. Besonders wichtig ist mir, dass die Benutzererfahrung in Bezug auf Anmeldungen, E-Mail-Validierungen und die Anforderung, alte migrierte Passwörter durch komplexere zu ersetzen, korrekt funktioniert – und all das erfordert E-Mails.

Sobald das erreicht ist, würde ich gerne auch Test-Zusammenfassungen für eine kleine Benutzergruppe erhalten, um zu sehen, wie diese aussehen, und um Optionen und das Design auszuprobieren.

Wie kann ich also unerwünschte E-Mails verhindern, aber dennoch die Möglichkeit haben, E-Mails zu erhalten, um die Migration ordnungsgemäß zu bewerten? Vielen Dank im Voraus für jeden Rat.

Ich vermute, worum es mir hier geht, ist eine Möglichkeit, eine Whitelist für E-Mail-Adressen zu implementieren, die während einer Migration erzwungen werden kann…

Etwas stimmt mit deiner Migration nicht, denn all unsere Tools setzen die Website seit Jahren automatisch in den Modus ‘keine E-Mails’ oder ‘nur E-Mails an Mitarbeiter’.

Ich verwende ein Skript, das auf dem kunena3.rb-Skript basiert, und die Änderungen, die ich vorgenommen habe, haben nichts mit E-Mails zu tun. Möglicherweise verwende ich eine mehrere Monate alte Version dieses Skripts, aber definitiv keine Version von vor Jahren.

Das ist es, was ich in den Logs sehe

Könnte es etwas mit einzelnen Benutzern zu tun haben, wie zum Beispiel einem Aktivierungsflag? Oder beziehen Sie sich auf systemweite Optionen?

Danke.

Ja, es gibt eine einzelne Site-Einstellung, die E-Mails komplett deaktiviert oder sie nur für Mitarbeiter freigibt. Migrationen setzen dies immer.

Scrolle im Thema nach oben, um zu sehen, was diese Einstellung ist ↑ ↑

Also, hier ist es…


Oder aus dem Code:

SiteSetting.disable_emails = "non-staff"

Meine Einstellung, als ich dort ankam, war no (deaktiviert), was enabled (aktiviert) bedeutet :scream:

Aber mein Skript greift diese Einstellung nicht an; und in base.rb ist sie auf yes gesetzt. Also habe ich derzeit keine Erklärung dafür, wie E-Mails aktiviert wurden (oder warum sie nicht deaktiviert wurden) :thinking:

Ich habe sogar den Code des einzigen Plugins überprüft, das ich verwende, discourse-migratepassword, aber dort wird diese Option ebenfalls nicht erwähnt.

Keine Antwort nötig – mein Problem ist gelöst, danke dafür. Ich frage mich zwar noch, was passiert ist, aber das ist zu diesem Zeitpunkt ein geringes Anliegen.