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:
Me doy cuenta de que este es un hilo antiguo, pero acabo de toparme con este problema, que provocó que se enviaran correos electrónicos a usuarios desde un servidor de migración que solo estaba destinado a pruebas.
Lo primero que me gustaría preguntar es si ha habido algún cambio al respecto en los últimos años.
Otro problema es que no estoy seguro de cuál es la mejor estrategia a adoptar aquí. Puedo desactivar todos los correos electrónicos y también los resúmenes, pero, por otro lado, quiero recibir los correos electrónicos administrativos de Discourse y permitir que algunos miembros de mi equipo comiencen a usar Discourse. En particular, quiero que la experiencia del usuario sea adecuada en cuanto a inicios de sesión, validaciones de correo electrónico de usuario, requisitos para cambiar sus contraseñas antiguas migradas por otras más complejas, etc., y todo esto requiere correo electrónico.
Una vez logrado eso, supongo que también me gustaría obtener resúmenes de correo electrónico de prueba para un pequeño grupo de usuarios, para ver cómo se ven y experimentar con las opciones y el diseño.
Entonces, ¿cómo puedo evitar correos electrónicos no deseados, pero aún así tener la posibilidad de recibir algunos para poder evaluar correctamente la migración? Gracias de antemano por cualquier consejo.
Creo que lo que estoy planteando aquí es una forma de crear una lista blanca de direcciones de correo electrónico que pueda aplicarse durante una migración…
Algo no está bien con tu migración, ya que todas nuestras herramientas siempre han puesto el sitio en modo sin correo electrónico o solo para correo de personal, y así ha sido durante años.
Estoy usando un script basado en el kunena3.rb, y los cambios que realicé no están relacionados con los correos electrónicos. Es posible que esté usando una versión de ese script de hace varios meses, pero definitivamente no de hace varios años.
Sí, hay una configuración del sitio que desactiva por completo el correo electrónico o lo establece solo para el personal. Las migraciones siempre configuran esto.
Desplázate hacia arriba en el tema para ver cuál es esa configuración
Mi configuración al llegar era no deshabilitado, lo que significa habilitado
Pero mi script no modifica esta configuración; y en base.rb está establecida en yes. Así que actualmente no tengo explicación de cómo se habilitaron los correos (o por qué no se deshabilitaron)
Incluso revisé el código del único plugin que estoy usando, discourse-migratepassword, pero tampoco hay mención de esta opción allí.
No es necesaria una respuesta: mi problema está resuelto, gracias por ello. Me queda preguntándome qué pasó, pero eso es una preocupación menor en este momento.
