error on nested attributes

[dgm]

Have I specified someting wrong in my DSL?

role :staff do
has_permission_on [:people], :to =>
[:index, :show, :edit, :update, :create, :new] do
if_attribute :user => is { user }
end
has_permission_on [:phone_numbers], :to =>
[:index, :show, :edit, :update, :create, :new] do
if_attribute :people => {:user => is { user }}
end

end

Permission denied: Error when calling user on [#<Person id:
1180170431, title: "Mr", first_name: "Joe", middle_name: "G",
last_name: "Dokes", common_name: "", updated_at: "2009-11-19
18:24:07", created_at: "2009-09-20 21:56:46">] for validating
attribute: undefined method `user' for #<Array:0x26581f8>


The model is set up such that:

Person has_one User, User belongs_to Person
Person has_many phone_numbers through personal_phone_numbers
PhoneNumber has_many people thorough personal_phone_numbers


It looks to me like it needs something like:

if_attribute :people => contains {:user => is { user }}

but that's not valid DSL.

[Mark Swardstrom]

Have you tried

if_attribute :people => contains { user }

?

--

You received this message because you are subscribed to the Google Groups "declarative_authorization" group.
To post to this group, send email to declarative_...@googlegroups.com.
To unsubscribe from this group, send email to declarative_author...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/declarative_authorization?hl=.

[dgm]

Doesn't work, and if I understand this right, I would not expect it
to... Wouldn't that describe the Person object as being the same as
user?

On Nov 19, 5:40 pm, Mark Swardstrom <swa...@gmail.com> wrote:
> Have you tried
>
> if_attribute :people => contains { user }
>
> ?
>

> > declarative_author...@googlegroups.com<declarative_authorization%2Bunsu...@googlegroups.com>
> > .

[Steffen Bartsch]

Am Donnerstag, 19. November 2009 schrieb dgm:
> has_permission_on [:phone_numbers], :to =>
> [:index, :show, :edit, :update, :create, :new] do
> if_attribute :people => {:user => is { user }}
> end
>
> end
>
> Permission denied: Error when calling user on [#<Person id:
> 1180170431, title: "Mr", first_name: "Joe", middle_name: "G",
> last_name: "Dokes", common_name: "", updated_at: "2009-11-19
> 18:24:07", created_at: "2009-09-20 21:56:46">] for validating
> attribute: undefined method `user' for #<Array:0x26581f8>

The authorization rules should work fine. How are you calling the
permitted_to? method? Are you maybe calling it with an Array as object?
Those methods expect a single object.

Steffen

[dgm]

On Nov 20, 4:01 am, Steffen Bartsch <sbart...@tzi.de> wrote:
> The authorization rules should work fine.  How are you calling the
> permitted_to? method?  Are you maybe calling it with an Array as object?  
> Those methods expect a single object.

I have a method I was using to narrow the search scope: (I think
_id_equals is a searchlogic plugin, it returns
ActiveRecord::NamedScope::Scope)

def get_scope(access)
scope = PhoneNumber.with_permissions_to(access)

case
when params[:person_id] then scope.people_id_equals params
[:person_id]
when params[:household_id] then scope.household_id_equals params
[:household_id]
when params[:organization_id] then scope.organization_id_equals
params[:organization_id]
else scope
end
end

The error is happening when I call it to update:

def update
@phone_number = get_scope(:update).find(params[:id], :readonly =>
false)
if @phone_number.update_attributes(params[:phone_number]) # Error
is here
#.....
end
end


and here's the full stack (minus some attributes in the Person
object):

Authorization::AuthorizationUsageError (Error when calling user on

[#<Person id: 1180170431, title: "Mr", first_name: "Joe", middle_name:

"L", last_name: "Dokes">] for validating attribute: undefined method
`user' for #<Array:0x23d2ba4>):
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:535:in
`object_attribute_value'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:428:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/reader.rb:60:in `all?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `each'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `all?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:438:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/reader.rb:60:in `all?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `each'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `all?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:427:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:374:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/reader.rb:60:in `any?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:372:in `each'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:372:in `any?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:372:in `send'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:372:in `validate?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:174:in `permit!'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/reader.rb:60:in `any?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:174:in `each'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:174:in `any?'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/authorization.rb:174:in `permit!'
vendor/gems/declarative_authorization-0.4/lib/
declarative_authorization/in_model.rb:131:in `using_access_control'
app/controllers/phone_numbers_controller.rb:43:in `update'

[Steffen Bartsch]

Am Freitag, 20. November 2009 schrieb dgm:
> and here's the full stack (minus some attributes in the Person
> object):

Those could be important here, though. Are there nested attributes in your
params[:phone_number]? From that stack I don't see why the stack needs to be
this deep. One explanation could be that there are nested attributes of which
each update need to be authorized. Is that the case?

Steffen

[dgm]

Submitted:

Parameters: {"commit"=>"Submit", "authenticity_token"=>"......",
"phone_number"=>{"phone_type"=>"", "private"=>"0",
"phone_number"=>"481-1303", "updated_by"=>"", "note"=>"sss"},
"id"=>"1999522681", "person_id"=>"1180170431"}

Error:

(Error when calling user on [#<Person id: 1180170431, title: "Mr",

first_name: "Joe", middle_name: "L", last_name: "Dokes", common_name:
"", suffix: "", dob: "2009-09-20", gender: "M", tshirt: "XL", email:
"te...@example.nett", updated_at: "2009-11-19 20:55:08", created_at:
"2009-09-20 21:56:46", re_id: nil, maiden_name: "", race: "", dod:
"2004-01-01", dup_of_id: nil, updated_by: nil>] for validating

[Steffen Bartsch]

Am Freitag, 20. November 2009 schrieb dgm:

> Submitted

Ah, OK. I thought you had cut lines from the stack trace.

I'm still wondering why there should be a second permit! in the stack trace.
Do you have one in your authorization_rules.rb? Are there really just the
lines from your initial E-mail in that file?

That could explain why there is a line referring to reader.rb before the
second permit! Else, you could try to add more debugging to the code in the
stack trace, trying to identify where the Array of Persons originates from.

Steffen

[dgm]

On Nov 20, 8:26 am, Steffen Bartsch <sbart...@tzi.de> wrote:


> I'm still wondering why there should be a second permit! in the stack trace.  
> Do you have one in your authorization_rules.rb?  Are there really just the
> lines from your initial E-mail in that file?

authorization do
role :admin do
has_permission_on
[:people, :phone_numbers, :addresses, :application_roles], :to =>
[:index, :show, :new, :create, :edit, :update, :destroy, :delete]
end

role :staff do
has_permission_on [:people], :to =>
[:index, :show, :edit, :update, :create, :new] do
if_attribute :user => is { user }
end
has_permission_on [:phone_numbers], :to =>
[:index, :show, :edit, :update, :create, :new] do
if_attribute :people => {:user => is { user }}
end

end

end

>
> That could explain why there is a line referring to reader.rb before the
> second permit!  Else, you could try to add more debugging to the code in the
> stack trace, trying to identify where the Array of Persons originates from.

How do I get it there? logger is undefined, puts doesn't put anything
in the development log ...

[Steffen Bartsch]

Am Freitag, 20. November 2009 schrieb dgm:

> > That could explain why there is a line referring to reader.rb before the
> > second permit! Else, you could try to add more debugging to the code in
> > the stack trace, trying to identify where the Array of Persons originates
> > from.
>
> How do I get it there? logger is undefined, puts doesn't put anything
> in the development log ...

Rails.logger should always work.

Steffen

[Steffen Bartsch]

OK, I just fixed it and pushed the change to github. Very strange bug. For
some reason, ActiveRecord proxies (e.g. phone_number.people) that normally
behave like Arrays are not === Enumerable, but is_a?(Enumerable) works.

Steffen

[dgm]

On Nov 20, 10:17 am, Steffen Bartsch <sbart...@tzi.de> wrote:
> OK, I just fixed it and pushed the change to github.  Very strange bug.  For
> some reason, ActiveRecord proxies (e.g. phone_number.people) that normally
> behave like Arrays are not === Enumerable, but is_a?(Enumerable) works.

Interesting. Well, that cured that error, but now I got a new one. :P

create not allowed for #<User id: 689986156, login: "dgm", email:
"dgm", person_id: 1180170431, crypted_password: "...", salt: "...",
created_at: "2009-11-19 19:06:11", updated_at: "2009-11-20 19:06:11",
remember_token: nil, remember_token_expires_at: nil, activation_code:
"...", activated_at: nil> on #<PhoneNumber id: nil, phone_number:
"3333", phone_type: "", private: false, note: "", updated_by: nil,
created_at: nil, updated_at: nil>.

The path through d_a is much shorter though:

/Users/dgm/workspace/cumission-rails/vendor/plugins/
declarative_authorization/lib/declarative_authorization/
authorization.rb:175:in `permit!'
/Users/dgm/workspace/cumission-rails/vendor/plugins/
declarative_authorization/lib/declarative_authorization/in_model.rb:
131:in `using_access_control'
/Users/dgm/.gem/ruby/1.8/gems/activesupport-2.3.4/lib/active_support/
callbacks.rb:182:in `call'
/Users/dgm/.gem/ruby/1.8/gems/activesupport-2.3.4/lib/active_support/
callbacks.rb:182:in `evaluate_method'


Would I need to set up permissions on the :through table too?

[dgm]

On Nov 20, 1:17 pm, dgm <morto...@gmail.com> wrote:
> Interesting.  Well, that cured that error, but now I got a new one. :P
>
> create not allowed for #<User id: 689986156, login: "dgm", email:
> "dgm", person_id: 1180170431, crypted_password: "...", salt: "...",
> created_at: "2009-11-19 19:06:11", updated_at: "2009-11-20 19:06:11",
> remember_token: nil, remember_token_expires_at: nil, activation_code:
> "...", activated_at: nil> on #<PhoneNumber id: nil, phone_number:
> "3333", phone_type: "", private: false, note: "", updated_by: nil,
> created_at: nil, updated_at: nil>.

Oh, is this where I need to create the object sequence in a before
filter?

[Steffen Bartsch]

Am Freitag, 20. November 2009 schrieb dgm:

> Interesting. Well, that cured that error, but now I got a new one. :P
>
> create not allowed for #<User id: 689986156, login: "dgm", email:
> "dgm", person_id: 1180170431, crypted_password: "...", salt: "...",
> created_at: "2009-11-19 19:06:11", updated_at: "2009-11-20 19:06:11",
> remember_token: nil, remember_token_expires_at: nil, activation_code:
> "...", activated_at: nil> on #<PhoneNumber id: nil, phone_number:
> "3333", phone_type: "", private: false, note: "", updated_by: nil,
> created_at: nil, updated_at: nil>.

This is the regular permission denied exception. So, most likely no bug :)

Is the phone_number already connected to the user? Does your attribute
condition hold? I.e., is
phone_number.people.any? {|person| person.user == user} true?

Steffen

[dgm]

On Nov 20, 3:44 pm, Steffen Bartsch <sbart...@tzi.de> wrote:
> This is the regular permission denied exception.  So, most likely no bug :)
>
> Is the phone_number already connected to the user?  Does your attribute
> condition hold?  I.e., is
> phone_number.people.any? {|person| person.user == user} true?

I think this is on the create action, so I need to get an object built
before it checks, right?