class Developer < ActiveRecord::Base has_many :games end
class Game < ActiveRecord::Base end
I'm trying to grant permission to read a developer IF that user can read any of the developers games.
something like
has_permission_on :developers, :to => :read do if_permitted_to :read, :games end
However, that does not work. And I am having to re-define each of the "game" permissions again as related to the developers (this duplicated logic in my rules file)
On Fri, Aug 31, 2012 at 7:28 PM, Edward Rudd <ur...@outoforder.cc> wrote:
> Given this these models
> class Developer < ActiveRecord::Base
> has_many :games
> end
> class Game < ActiveRecord::Base
> end
> I'm trying to grant permission to read a developer IF that user can read any
> of the developers games.
> something like
> has_permission_on :developers, :to => :read do
> if_permitted_to :read, :games
> end
> However, that does not work. And I am having to re-define each of the "game"
> permissions again as related to the developers (this duplicated logic in my
> rules file)
Not sure if that would work, as :games isn't a single game, but a collection. I'll have to do a lot more debugging into the depths of decl_auth and see if I can figure it out.. Right now I have a working, albeit an annoying one.
> On Fri, Aug 31, 2012 at 7:28 PM, Edward Rudd <ur...@outoforder.cc> wrote:
>> Given this these models
>> class Developer < ActiveRecord::Base
>> has_many :games
>> end
>> class Game < ActiveRecord::Base
>> end
>> I'm trying to grant permission to read a developer IF that user can read any
>> of the developers games.
>> something like
>> has_permission_on :developers, :to => :read do
>> if_permitted_to :read, :games
>> end
>> However, that does not work. And I am having to re-define each of the "game"
>> permissions again as related to the developers (this duplicated logic in my
>> rules file)
>> --
>> You received this message because you are subscribed to the Google Groups
>> "declarative_authorization" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/declarative_authorization/-/tCptCcaV4CIJ.
>> To post to this group, send email to
>> declarative_authorization@googlegroups.com.
>> To unsubscribe from this group, send email to
>> declarative_authorization+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/declarative_authorization?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "declarative_authorization" group.
> To post to this group, send email to declarative_authorization@googlegroups.com.
> To unsubscribe from this group, send email to declarative_authorization+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/declarative_authorization?hl=en.
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296
It seems like what you described makes sense as the default behavior
for your syntax above. It would be consistent with the nested
'if_permitted_to' syntax:
# if_permitted_to associations may be nested as well:
# if_permitted_to :read, :branch => :company
#
# You can even use has_many associations as target. Then, it is checked
# if the current user has the required privilege on *any* of the
target objects.
# if_permitted_to :read, :branch => :employees
> Not sure if that would work, as :games isn't a single game, but a
> collection. I'll have to do a lot more debugging into the depths of
> decl_auth and see if I can figure it out.. Right now I have a working,
> albeit an annoying one.
> --
> You received this message because you are subscribed to the Google Groups
> "declarative_authorization" group.
> To post to this group, send email to
> declarative_authorization@googlegroups.com.
> To unsubscribe from this group, send email to
> declarative_authorization+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/declarative_authorization?hl=en.
> Edward Rudd
> OutOfOrder.cc
> Skype: outoforder_cc
> 317-674-3296
> --
> You received this message because you are subscribed to the Google Groups
> "declarative_authorization" group.
> To post to this group, send email to
> declarative_authorization@googlegroups.com.
> To unsubscribe from this group, send email to
> declarative_authorization+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/declarative_authorization?hl=en.
On Sep 5, 2012, at 17:25, Eric Hu <e...@lemurheavy.com> wrote:
> It seems like what you described makes sense as the default behavior
> for your syntax above. It would be consistent with the nested
> 'if_permitted_to' syntax:
> # if_permitted_to associations may be nested as well:
> # if_permitted_to :read, :branch => :company
> #
> # You can even use has_many associations as target. Then, it is checked
> # if the current user has the required privilege on *any* of the
> target objects.
> # if_permitted_to :read, :branch => :employees
Hmm, then I may have found a bug, as I'm not checking a nested association below games, but games itself and it is not working. I'll write up some test cases in the decl Auth code and see if I can narrow it down.
>> Not sure if that would work, as :games isn't a single game, but a
>> collection. I'll have to do a lot more debugging into the depths of
>> decl_auth and see if I can figure it out.. Right now I have a working,
>> albeit an annoying one.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "declarative_authorization" group.
>> To post to this group, send email to
>> declarative_authorization@googlegroups.com.
>> To unsubscribe from this group, send email to
>> declarative_authorization+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/declarative_authorization?hl=en.
>> Edward Rudd
>> OutOfOrder.cc
>> Skype: outoforder_cc
>> 317-674-3296
>> --
>> You received this message because you are subscribed to the Google Groups
>> "declarative_authorization" group.
>> To post to this group, send email to
>> declarative_authorization@googlegroups.com.
>> To unsubscribe from this group, send email to
>> declarative_authorization+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/declarative_authorization?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "declarative_authorization" group.
> To post to this group, send email to declarative_authorization@googlegroups.com.
> To unsubscribe from this group, send email to declarative_authorization+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/declarative_authorization?hl=en.
On Wed, Sep 5, 2012 at 2:32 PM, Edward Rudd <ur...@outoforder.cc> wrote:
> On Sep 5, 2012, at 17:25, Eric Hu <e...@lemurheavy.com> wrote:
>> It seems like what you described makes sense as the default behavior
>> for your syntax above. It would be consistent with the nested
>> 'if_permitted_to' syntax:
>> # if_permitted_to associations may be nested as well:
>> # if_permitted_to :read, :branch => :company
>> #
>> # You can even use has_many associations as target. Then, it is checked
>> # if the current user has the required privilege on *any* of the
>> target objects.
>> # if_permitted_to :read, :branch => :employees
> Hmm, then I may have found a bug, as I'm not checking a nested association below games, but games itself and it is not working. I'll write up some test cases in the decl Auth code and see if I can narrow it down.
>>> Not sure if that would work, as :games isn't a single game, but a
>>> collection. I'll have to do a lot more debugging into the depths of
>>> decl_auth and see if I can figure it out.. Right now I have a working,
>>> albeit an annoying one.
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "declarative_authorization" group.
>>> To post to this group, send email to
>>> declarative_authorization@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> declarative_authorization+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/declarative_authorization?hl=en.
>>> Edward Rudd
>>> OutOfOrder.cc
>>> Skype: outoforder_cc
>>> 317-674-3296
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "declarative_authorization" group.
>>> To post to this group, send email to
>>> declarative_authorization@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> declarative_authorization+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/declarative_authorization?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups "declarative_authorization" group.
>> To post to this group, send email to declarative_authorization@googlegroups.com.
>> To unsubscribe from this group, send email to declarative_authorization+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/declarative_authorization?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "declarative_authorization" group.
> To post to this group, send email to declarative_authorization@googlegroups.com.
> To unsubscribe from this group, send email to declarative_authorization+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/declarative_authorization?hl=en.
> has_permission_on :developers, :to => :read do
> if_permitted_to :read, :games
> end
I just checked the test cases. There actually is a similar case that works in authorization_tests#test_attribute_with_has_many_permissions:
role :test_role do
has_permission_on :permissions, :to => :test do
if_attribute :test_attr => 1
end
has_permission_on :permission_children, :to => :test do
if_permitted_to :test, :permissions
end
end
> Am 01.09.2012 04:28, schrieb Edward Rudd:
>> has_permission_on :developers, :to => :read do
>> if_permitted_to :read, :games
>> end
> I just checked the test cases. There actually is a similar case that works in authorization_tests#test_attribute_with_has_many_permissions:
> role :test_role do
> has_permission_on :permissions, :to => :test do
> if_attribute :test_attr => 1
> end
> has_permission_on :permission_children, :to => :test do
> if_permitted_to :test, :permissions
> end
> end
> Or is this somehow different?
That does look to be exactly the same. I'm on vaca until Friday so I'll take a deeper look at it over the weekend and extract out a more detailed error message.
On Thursday, 6 September 2012 06:47:52 UTC-4, steffenb wrote:
> Am 01.09.2012 04:28, schrieb Edward Rudd: > > has_permission_on :developers, :to => :read do > > if_permitted_to :read, :games > > end
> I just checked the test cases. There actually is a similar case that > works in authorization_tests#test_attribute_with_has_many_permissions:
> role :test_role do > has_permission_on :permissions, :to => :test do > if_attribute :test_attr => 1 > end > has_permission_on :permission_children, :to => :test do > if_permitted_to :test, :permissions > end > end
I finally got back around to this project, and I tried, and it's still not quite working. .I've found a slight alteration that got it to work w/o the duplication, but I'm thinking there might be some kind of bug.
has_permission_on :developers, :to => [:read, :read_address] do if_permitted_to :is_member, :games => { :ports => :developer } end
This is what I *assumed* should have been able to work
has_permission_on :developers, :to => [:read, :read_address] do if_permitted_to :is_porter, :games end
However it blows an error that it can't read. the spec test is in specs/roles/porter_role_spec.rb line 37 ('can read including address info for developers with games I am porting')
