Add confirmable to User

[invacuo]

Description

• Added confirmable module to devise users
• Added necessary migration
• Added letter_opener gem in development environment to make testing easier
• Added after_party gem to update the newly added confirmed_at column in the database to current timestamp so that the existing users don't have to confirm their email
• The after_party gem would need the deployment script updated to run the rake task after deploy. The details can be found at https://github.com/theSteveMitchell/after_party#usage
• Alternatively, the deployer can manually run User.update_all ["confirmed_at = ?", Time.now] in rails console on production

Fixes #88

Developer Checklist

You can mark items off by replacing [ ] with [x] or in the rendered markdown, you can simply check the checkbox.

• [x] I have read and followed the contribution guidelines.
• [x] All specs and linters pass (including Code Climate)
• [x] I have followed the style of nearby code
• [x] The build on Semaphore is successful
• [x] I have gone through my changes by hand, either in the browser or terminal, which ever makes sense

Maintainer Checklist

• [ ] Run migrations (if necessary) in production after deployment
• [ ] Review issues and update labels

Screenshots

Warning that a user will see after 1 day

After clicking Didn't receive confirmation instructions?

Confirmation email copy (via letter_opener)

After confirming email

[crawfoal]

Thanks for your help! I have a few questions:

• Why did you decide not to add specs for this? I usually add them even for Devise related stuff, just to make sure things are configured properly, but I know that other people might consider this overkill.
• What configuration will need to be done to get this working in production? We don't have any mailers set up yet, so I know we'll definitely need to set that up. I was planning on doing that in the first PR that sets up a mailer, but we could do it in a separate one if you think that would be better. I was going to follow this article by Thoughbot because I don't have much experience with mailers. I have a separate issue (#91) for setting up ActiveJob.

[invacuo]

• I did not add any specs as I did not add any special business logic besides the devise configuration stuff. I don't mind adding some feature specs for now as we don't have mailers and ActiveJobs set up.
• The Thoughbot article looks pretty good. I would do the mailer setup independent of this PR as that will give us better control and understanding in case something goes wrong.

[invacuo]

Sorry, I forgot to pull your changes in so I accidentally removed the newline fix commit you had.

[crawfoal]

Things look good here, I'm just thinking about how I want to set up the different environments. I have Heroku pipelines set up, so in addition to the typical dev and test environments, there are review apps and a staging app. The review and staging apps are all running in the production Rails environment. They are also all automatically populated with sample data where the users have fake email addresses.

Right now, I'm thinking about creating a staging Rails environment and having the review apps and the current staging app run in this environment. Then I could create another staging app that runs the production Rails environment and doesn't have sample data. We could create users in there with our real emails and then when we want to test stuff with mailers, we'd use this new staging app.

Do you have any input on this?

[invacuo]

• For managing environment variables, dotenv-rails has been my go to gem.
• I am a little unclear about the preview and staging environment differences. If we have real emails in the preview app, isn't there a risk of accidentally spamming people?
• One thing we've done at work for staging is setup an email intercept to ensure we only send emails to the emails that have our company domain in them. A simple regex filter.

[crawfoal]

I think that accidentally sending emails to real users is only a concern if you copy the production database to a staging or preview app.

Right now, the staging app creates sample data with fake emails (e.g. "user1@example.com"). For the other environment I'm thinking of creating, we would create users and other data by hand. We'd use our own email addresses so that we could make sure everything is configured correctly, so we'd only ever be at risk of emailing people who have created test users.

[crawfoal]

I've thought about this more and decided not to create another Rails environment. I'm just going to do something like what you mentioned earlier - whitelist email addresses that can be mailed to.

Also, I created a spec for the deploy task and I was thinking it was silly to test something so simple, but then it didn't pass. Am I missing something here?

require 'rails_helper'

RSpec.describe 'rake after_party:confirm_existing_users', type: :task do
  it 'marks existing users as confirmed' do
    user = create :user

    task.execute

    expect(user).to be_confirmed
  end
end

[invacuo]

Is there a stack trace or an output that you can paste?

[crawfoal]

Sorry for the delayed response 😕

I looked back over this and realized that it was just because the user record needed to be reloaded before the expectation.

I've added this spec and modified the deploy task to use the Rails logger instead of puts (mostly so that we don't have output in the middle of the RSpec run). I pushed these changes to a branch on my remote (I also merged in master). If these changes look good to you, then either one of us can merge them into this PR and then I'm ready to merge this PR in (that sounds overly complex now that I'm typing, but I didn't want to merge those changes directly into your branch without asking first 🙂 ).

[invacuo]

Just left one comment about keeping the puts. Besides that it looks good! Feel free to merge the changes into my branch if that's easier.

Thanks! 😄