Chris Oliver

Whoops, you're totally right! Thanks for the comment. That was my bad. I knew I was probably overlooking something calling it "send".

Definitely a problem when you don't have the full Rails app to test your refactorings against.

I'll be sure to cover more topics then! Feel free to email me any examples of code you'd like to see refactored and I'll see what I can do.

Check out rolify for database backed permissions. It is pretty flexible and shouldn't cause much if any downtime if you migrate from static permissions to database ones. You'd simply create the role records in the db before deploying the rolify backed cancan config so that there was no trouble.

Definitely wise to have expirations on tokens. Also you will probably want to tell your users to keep the token secret (like don't commit it into a git repo for example). There's not much way around that because any API token is going to let you access the site on behalf of a user since that's what they are designed for. Just want to make sure to educate users to protect their tokens just like they would their password.

That would do it! Sometimes the file permissions or ownership will do that. I've often accidentally run a command as sudo without realizing it would change ownership of my app files and all of a sudden Nginx can't read the Rails app anymore.

Thanks for sharing your solution! :)

That's the plan. Twitter is a bit frustrating because it doesn't give you an email so you can't create Devise users easily with it. Need to store the OAuth hash in the session so you can ask for an email first. I'll be doing an episode on that soon.

Yep! You can make the likes polymorphic if you want them to apply to more than one model. That would let you add likes to Threads and Posts. You'd build it pretty much the same way and that should do the trick.

Hmm, sounds like something wrong there with the config. You definitely just want one line that says passenger_ruby and it should point to the wrapper version of it, not the same as which ruby outputs.

As far as what to check next, look at /var/log/nginx/error.log and see if there is anything in that file (or other files in the same folder) to see what it says when you get the 403. That will probably give you the best idea of what's wrong.

1. It is usually wise to always require an email and optionally do the username. One reason is: how does a user recover their password if you don't have their email?

On a side note, you can easily add usernames to Devise and they definitely can be easier to remember. Check this out if you're interested in sign-in with both. https://github.com/plataformatec/devise/wiki/How-To:-Allow-users-to-sign-in-using-their-username-or-email-address

1. You know how some sites (like Slack.com) use a subdomain for the company? That's basically for exactly that problem and each company gets to choose their subdomain or "username" if you will. You could have two "ABC Widgets" companies but they would have different subdomains.

2. You can use nested model validation to take care of that. If any of the records isn't valid, it will roll them back. You'll want to do nested form for those things. Like a form_for @user with fields_for :company and fields_for :role so that it's all contained properly. More info on that here: http://homeonrails.com/2012/10/validating-nested-associations-in-rails/

I haven't used Pundit with AA, but I was going to mention the adapter. Not quite sure what to suggest from here. Maybe there is a typo in there somewhere causing it to be unable to find it?

You can upload anything with it. You'll want to check out https://zencoder.com/en/ for transcoding. If you set Refile to upload to S3, zencoder can take it from there. https://github.com/zencoder...

Awesome, thanks for the heads up Isaac!

You can do "rbenv rehash" to make the cap executable available like a regular command.

This isn't Devise, but Devise's emails work the same way. It uses your ActionMailer config so it will send them as well.

Yes, because usually I'll have a separate account between development (often disabled or a test account that's a free plan) and production.

Sure can. You could use the counter_cache option to save the count to the model and then you can order by that method.

Thanks Jason! I think at the time they didn't have anything past precise. I'm glad they got Trusty and Utopic in there!

Only difference is you'll want to install Homebrew and then MongoDB through that using "brew install mongodb"

Thanks Stan! :)

I believe with multiple files (at least for separate things) you just say

class User
  attachment :photo
  attachment :resume
end

You may need to modify the Javascript somewhat so that it can tell the difference between the two. That likely is worth doing another episode on, some form of refactoring Javascript to handle this better.

The thing they don't handle right now is uploading multiple files (like User has_many :photos) but that should be coming soon. At least after reading that thread, it seems it should be easy for someone to implement it.

In that case, I would stick to just a string column on the User model for role. That way it can only store one value (and you can add more later easily). No need for a join table here because your User will just contain the role.

# role :string
class User
  def user?; role == "user"; end
  def admin?; role == "admin"; end
  def superadmin?; role == "superadmin"; end
end

You can create some helper methods like that to determine what type of user they are.

Then to restrict who can change that, you can update your controller's strong params code for superadmins to add the role column as allowed for editing. The other types of users won't allow that field, so they can't change user's roles.

You can do that with Pundit pretty easily. First you'll create the policy for the User model and then you can have your controller ask the Policy which params are allowed:

# app/policies/user_policy.rb
class UserPolicy < ApplicationPolicy
  def permitted_attributes
    if user.superadmin?
      [:first_name, :last_name, :role]
    else
      [:first_name, :last_name]
    end
  end
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def update
    @user = User.find(params[:id])
    if @user.update(user_params)
      redirect_to @user
    else
      render :edit
    end
  end

  private

  def user_params
    params.require(:user).permit(*policy(@user || User).permitted_attributes)
  end
end