While using using_access_control :include_read => true,
I have rules similar to this :
using_access_control :include_read => true
has_permission_on :projects, :to => :read do
if_attribute :public => true
has_permission_on :'projects/experiments', :to => :read do
if_permitted_to :read, :project
This works fine when retrieving the records with with_permissions_to(:read). However, when I start looping through the experiments, I get the following error :
read not allowed for #<User id: 1, email: "firstname.lastname@example.org"> on #<Projects::Experiment id: 1>
I have tracked down the error to https://github.com/stffn/declarative_authorization/blob/master/lib/declarative_authorization/authorization.rb#L453
It seems declarative authorization removes the attributes somewhere, making it impossible to retrieve the project. The project attribute properly exists though, and it should be able to load it and check the authorization on it.
I don't think you are on the right track here. decl_auth shouldn't remove any of your attributes. I'd need a failing test case in the decl_auth test suite to look into it, though...
Ok, my bad. It seems kaminari is the one doing the select.
My bad. It appears when using kaminari. But it seems to be caused by any use of limit(xx) on a scope.
This occurs because of rails' #count method, which retrieves the primary key of all records.
But, in construct_limited_ids_condition, loops through all of them and therefore raises an error, as declarative authorization can't authorize properly the object.
We have an acceptable workaround for us at 0d9142 (see the commit message for the details).
I'm not sure that I fully understood the issue. But isn't this a bug in AR if it calls after_find in a count statement? I'd expect after_find only to be called on a fully instantiated object.