Chris Oliver

The goal is not to use passwords for ssh so it is more secure. You'll just need to copy your ssh public key to the deploy user with ssh-copy-id. Double check that you can ssh into deploy without a password so Capistrano can too.

Does your update_url data attribute point to /sections/sort?

Ah ha! That's sending to your create action, but you have a sort action for sorting. You'll need to update your JS to point to the sort sections route.

You would have to have an API endpoint for user creation that doesn't require an API key. It would be just like having a form on a website more or less. Check this out for a decent example on how to build an endpoint like this: http://stackoverflow.com/a/...

Oh duh. You probably don't need strong_params for this. Your original logs were calling section_params so I was thinking about fixing that.

Your sort method should work fine like that unless the update_all query needs to get different parameters in the new ActiveRecord versions but you should be good.

That's a good idea. I'll hook that in soon.

You don't have to run it manually like you do in development. When you run Capistrano, it runs bundler which installs the Rails gem. Then, Nginx is always running and it fires up Passenger which starts your Rails app for you. So basically Nginx is the thing that runs your Rails app in production and all you need to do is make sure Nginx is running.

Since that user can add access to other users specific to that post, you'll probably want to create a join table between the two and then use CanCanCan to verify if they are the owner or an editor.

Right now you probably have this:

class Post
  belongs_to :user
end

class User
  has_many :posts
end

And if you refactor so that the users are stored in a join table, you can have multiple users with access to a post:

class Post
  has_many :post_users
  has_many :users, through: :post_users
end

class PostUser
  belongs_to :post
  belongs_to :user
end

class User
  has_many :post_users
  has_many :posts, through: :post_users
end

When you create a post, you'll want to add @post.users << current_user so that the person who created the post is in the users list.
You can add another action to give access to another user which just accepts a user_id and does something like the following:

def add_user
  @user = User.find(params[:user_id])
  @post.users << @user
  redirect_to @post, notice: "#{@user.name} can now edit the post"
end

Then you can simply use CanCanCan to check if the user is in the users array for a post. If they are they can manage the post; if they aren't they can't manage the post.

Does that make sense for what you want?

Oh that's a good point. It's not formatted properly for strong_params, so you'd have trouble with it accepting things. I'll definitely plan on covering an update to that to how to do it formatted a little more standardized for strong_params.

In the meantime, you should be able to change your require & permit to just this:

def order_params
  params.permit(section: [])
end

Note that you'll only want to use this on the sort action and not the rest of the regular crud actions.

Maybe they aren't using something as friendly as Ruby on Rails. ;-)

Exactly! Devise uses a "reset_password_token" that gets sent over email to you. When you click the link, the token is in the url and then gets put in the new password form. When you submit the form, it looks up your user by that token and then updates your password and signs you in.

<3

Here's a first episode on the topic! :) https://gorails.com/episodes/api-tokens-with-devise-token-authenticatable

API tokens in Redis would be useful for accessing them very quickly without hitting the database. Performance would be the primary reason here and you could also have them autoexpire using the built in Redis expiration functionality

Paste a Github gist of your code and the HTML it generates and I'll take a look for ya!

Check out the gem documentation for some more info on I18n https://github.com/basecamp...

Oh I bet that's the case. I would guess that the jquery-ujs script listens to the form's submit event and since you aren't firing it, it won't happen.

It seems you could probably call the jquery-ujs methods to disable the elements in your callback. https://github.com/rails/jq...

It looks like when I change it to type="button" the form does not submit which means the JS won't fire either.

Hmm. I've got this on the login page here on GoRails:

<button class="btn btn-success btn-lg btn-block" data-disable-with="&lt;i class='fa fa-spinner fa-spin'&gt;&lt;/i&gt; Signing in..." name="button" type="submit">Sign in</button>

Only other thing I can think of is maybe your jquery-ujs isn't being loaded successfully and so it never gets triggered on click.

You won't use it with <input> at all because neither <input type="submit"> nor <input type="button"> allow for HTML inside of it. You'll have to use the <button></button> tag to use this.

I'm super happy to hear that! :) Let me know if you've got any other topics you'd like me to explain!