Should importers import users with invalid email addresses by default?

Re-running an import with a bunch of invalid emails is a drag since it has to re-try adding each block of 1000 users if one of them is bad.

I don’t see a down side to importing users with bogus email addresses with a random one rather than throwing an error and think that all importers would benefit from creating those users rather than have their messages owned by @system. Is there something I’m missing?

Should I add something like this to base.rb?

          unless opts[:email].match(EmailValidator.email_regex)
            opts[:email]= "invalid#{SecureRandom.hex}@no-email.invalid"

Arguably it should still print a warning. . .


Sounds like a good idea!


Sure, go ahead and submit that, but I would store the original email in a custom field or something in that case.


I would too, but I was too lazy to figure out how to add a custom field. Thanks for the push; I’ll figure it out. The tension between getting an import job done and making the code better is high.

Done. Thanks for the push.


Hey, @zogstrip (who accepted the PR above), it looks like something has happened to the email validator (?) such that it no longer thinks that no-email.invalid is a valid domain, so now importers claim to be producing accounts with the new bogus email, but in fact, are not.

At least that’s what it looks like. I re-run an importer and get the same “creating with bogus email address” for the same names over and over. Or maybe I’m doing something silly.

1 Like

Are you sure the error is on the email? I just tried this on the rails console and it worked fine

User.create!(email: "invalid#{SecureRandom.hex}@no-email.invalid", username: "random")
1 Like

Darn. Apparently I am not.

I know that it silently failed to create those users (because subsequent runs would all claim to create them with the be bogus address) and then when I changed the bogus address to it created them. This was on three imports with two different importers.