Chris Oliver

I think that's because on the index you want an array of records, but on show you just want a single record.

When you pass in the array into policy_scope, it's going to call the .where(company_id: X) method on it. This works when you return Item.all but when you pass in just an Item record, that does not have a where method because it's a single instance of the Item class.

In your show action, you can change it to:

def show
    @item = Item.find(params[:id])
    authorize @item
end

And this will load the record and Pundit will know to authorize it against the right method in the policy without hitting the Scope.

I'm using pygments.rb inside of Github's html-pipeline with a handful of other gems to improve the Markdown parsing:

gem "html-pipeline", "~> 1.9.0"
gem "rinku", "~> 1.7.3"
gem 'github-linguist', '~> 3.1.2'
gem "github-markdown", "~> 0.6.4"
gem 'pygments.rb', '~> 0.6.0'

Awesome find! Thanks for sharing this.

Updated. It got eaten in my markdown parser I believe. :)

This looks awesome. I'd love to see this stuff standardized and included in Rails core. Is the plan for this shipping with Rails 5?

Glad to help and thanks for the kind words. :-)

So on GoRails, I do this inside my episodes/show.html.erb:

<script>
  wistiaEmbed = Wistia.embed("<%= @episode.video_identifier %>")
</script>

Yeah if you need multiple levels of access more than global and individual then you will need another tier. You can put the access level on the items and the users or you can put them in a join table.

You want a has_one :company, through: :product on the Option to make that work. belongs_to is only used when you have an _id column on the model.

If you're scoping activity to things which a user owns, you'll need to store the user_id on the records anyways otherwise how can you know who created it? Because of that, it seems that identities overcomplicate things a bit and you'll end up with an unclear mess of things (and likely open yourself up for a lot of security holes). If you simply add a user_id on everything, you can know if the current user can manage that item or not. If you add a role to the User model, you can give them higher levels of access that can skip the lower user_id checks to allow them company level access instead.

Ha! That will do it. :)

I'd suggest using a string column for those since they aren't simple integers.

Your database will be the one handling those writes and generating the IDs. In most cases like that, you don't need to worry about that but consistency can become a problem when your set up gets a lot larger.

Basically, you need to run a mail server somewhere in either case. Mandrill serves as that whether you just use it for SMTP or you hit their API instead to send the emails without using SMTP.

Your problem is:

/usr/local/include is not writable.

I think that should be owned by your user. Mine is

drwxr-xr-x  232 chris  admin   7888 Sep 26 14:24 include

I imagine fixing permissions and reinstalling mysql will do the trick.

Ah yep! Pretty much anytime someone (like myself) mentions a file without giving a full path, they mean inside your Rails app's directory like that.

Yep! I think you can even have it automatically parse the XML if you have the multi_xml gem installed.

Haha! Glad it's working for you. I think you're right about the join table not needing a primary key, but I think when you do that in Rails, it assumes you don't create a model for it. Since we're interacting with that join table a bit differently than normal, it seems like it probably is a good case to have it. In general, a ID column doesn't really add any noticeable overhead to your database, so you don't have to worry about that in the future.

Another possibility is you might try generating the model named singularly instead as "Favorite" instead of "Favorites". That is also something that Rails often wants a certain way and deviating can cause it to do some unexpected things once in a while.

Always happy to help! :) Plus, weekends are when I record screencasts anyways.

When you use a route module, it just means to put the controller in a folder of that name. If you say module: :locations then it will look in app/controllers/locations for the favorites_controller.rb file. It doesn't affect your models at all.

The thing here I noticed is that you have create_table without an ID column. That could be affecting the query. It shouldn't matter, but Rails usually wants a primary key to look up the records quickly. Try generating the table again with the ID column and see what happens.

That looks correct to me. You may want to run this in your Rails console to verify it is working outside of your action. I can't think of what would cause it to generate the WHERE without a column name there, but it has to be something revolving around your database, associations, or query.

Another thing, have you verified that @location.favorites works correctly? When you hit the create, it makes the record correctly including the user_id?