Manage outgoing emails while testing imported site


(Stefano Maffulli) #1

I’m importing a large forum from myBB to Discourse, using @pfaffman updated importer. Correctly, the importer blocks all outgoing emails but that also blocks emails for new account creation and password restores. In my tests, I need to have users signup after the old content is imported. More importantly, I need to test the process for old users to restore their access to the new forums (since the old passwords won’t work).

At the same time I don’t want to send out any other emails, like the digest emails or any other. Does anybody know if it’s possible and how to manage email settings in a more granular way than the crude SiteSetting.disable_emails=true?


(Jay Pfaffman) #2

Hey, @smaffulli! Did I miss an email? I just got back to my desk and still need to run some back-to-town-after-2-weeks-away errands.

Yes, the importer suspends all users (which I know that you needed, but probably no one else does & I should fix that).

It’s safe to set SiteSetting.disable_emails=false. Only users who’ve un-suspended their accounts will get mail (e.g., summaries) and you can let new users sign in normally.

If you have any more questions, please feel free to email me and I’ll make sure this gets worked out.


(Stefano Maffulli) #3

(you haven’t missed an email… I thought this was general-purpose enough that a public thread would be useful).

I noticed yesterday that a lot of users were emailed with a digest (I have received one and I can see the logs in Admin/Email/Sent). I am not sure why/how that happened, I can’t really reconstruct the series of events that triggered the send. All I know for sure is that I ran the import script again, with an updated database dump before receiving the digest. Maybe re-running the import scripts modifies the last access date for users? Anyway, I’d rather stay safe while testing this stuff and disable everything else but the signup and restore password.


(Jay Pfaffman) #4

A thousand apologies. I looked too quickly at the code & remembered wrong.

I thought I’d included this function in the script, but I didn’t (which, as I said is good since you’re the only one who needs it).

  def deactivate_all_users
    User.where("active = true").update_all(active: false)
  end

What you probably want to do is just

cd /var/discourse
./launcher enter app
rails c
User.where("active = true").update_all(active: false)
exit
exit

That will suspend all users (I think it won’t suspend admins), so you can enable sending mail.


(Stefano Maffulli) #5

I think that disables something crucial: the site is not working after launching that command :slight_smile:


(Jay Pfaffman) #6

Hmm. That’s strange. What happens when you try to access the site?

The only thing that I could think of is that the command also disabled your admin account and you need to rake admin:create to re-enable it.


(Stefano Maffulli) #7

the symptom is that the admin interface doesn’t load:

For the rake admin:create command do I need to create one from scratch? Isn’t there a way to enable users selectively from rails console?


(Jay Pfaffman) #8

Does it seem that the User.where... command completed? Perhaps the server’s just swamped finishing that up?

Do other pages render correctly and just the admin page isn’t loading?


(Stefano Maffulli) #9

no page loads and it seems like the query finished quite quickly too. I have reset the admin password using the rake command (first time I used it) and the site is now loading at least… but I forgot to enable sending emails first :slight_smile: I’ll sort this out, thanks.