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.
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.
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:
Je me rends compte que ce fil est ancien, mais je viens de rencontrer ce problème, qui a entraîné l’envoi d’e-mails aux utilisateurs depuis un serveur de migration qui n’était censé servir qu’à des tests.
Ma première question est de savoir si quelque chose a changé à cet égard au cours des dernières années.
Ensuite, un autre problème est que je ne suis pas sûr de la meilleure stratégie à adopter ici. Je peux désactiver tous les e-mails et les résumés, mais d’un autre côté, je souhaite recevoir les e-mails d’administration de Discourse et permettre à certains membres de mon équipe de commencer à utiliser Discourse. En particulier, je veux garantir une bonne expérience utilisateur en matière de connexions, de validations d’adresse e-mail des utilisateurs, d’exigences pour modifier leurs anciens mots de passe migrés vers des mots de passe plus complexes, etc. — et cela nécessite l’envoi d’e-mails.
Une fois cela réalisé, je pense que je voudrai également recevoir des résumés d’e-mails de test pour un petit groupe d’utilisateurs, afin de voir à quoi ils ressemblent et d’expérimenter les options et le design.
Alors, comment puis-je empêcher l’envoi d’e-mails indésirables, tout en conservant la possibilité de recevoir certains e-mails afin de pouvoir évaluer correctement la migration ? Merci d’avance pour vos conseils.
Je pense que ce dont je parle ici, c’est d’une méthode pour contourner une liste blanche d’adresses e-mail qui pourrait être appliquée pendant une migration…
Quelque chose ne va pas avec votre migration, car tous nos outils placent systématiquement le site en mode « sans e-mail » ou « e-mail réservé au personnel » depuis des années.
J’utilise un script basé sur le script kunena3.rb, et les modifications que j’ai apportées ne sont pas liées aux e-mails. Il se peut que j’utilise une version de ce script vieille de quelques mois, mais certainement pas vieille de plusieurs années.
Cela pourrait-il être lié à des utilisateurs individuels, comme un indicateur d’activation ? Ou faites-vous référence à des options à l’échelle du système ?
Oui, il existe un paramètre de site unique qui désactive complètement les e-mails ou les limite au personnel uniquement. Les migrations le définissent toujours.
Faites défiler vers le haut dans le sujet pour voir quel est ce paramètre ↑ ↑
Ma configuration, quand je suis arrivé, était no pour désactiver, ce qui signifie activé
Mais mon script ne modifie pas ce paramètre ; et dans base.rb, il est défini sur yes. Donc, je n’ai actuellement aucune explication sur la façon dont les e-mails ont été activés (ou n’ont pas été désactivés)
J’ai même vérifié le code du seul plugin que j’utilise, discourse-migratepassword, mais aucune mention de cette option non plus.
Pas besoin de répondre — mon problème est résolu, merci pour cela. Je me demande toujours ce qui s’est passé, mais c’est une préoccupation mineure à ce stade.
