I am currently making some local enhancements for ActiveRBAC and I was
wondering what the idea is behind the naming of static_permissions.
It seems there used to be a permissions data model in the version 1
schema, but it appears that is no longer being used. So my question
is, what advantage is there of calling it "static permissions" as
opposed to just plain "permissions"?
Thanks,
Peter
They are called static because they are global to the whole
application. They are not bound to specific records as local or
contextual permissions would be. For example:
"User with this role may create new articles"
is a static, global permissions.
"Users with this role may create articles within Folder #3"
is a local, contextual permission.
The table for a static permission looks like this:
(id, identifier)
A contextual permission table would look as follows:
(id, identifier, context-object-class, context-object-id)
or if you have a table for each record class that may have contextual
information:
(id, identifier, context-object-id)
Bests,
Manuel
Thanks for your reply. I think I understand what you are calling
static (global) permissions. Where I am still confused is how you
would implement non-static permissions with ActiveRBAC.
The only place I can find any reference to using non-static
permissions is in the documentation for "RBAC schema level 1".
Although, it's not entirely clear if it is the developer's
responsibility to implement the non static permission methods and
model relationships?
I also see that acts_as_anonymous_user_test.rb is using an OpenStruct
to define permissions. Is this an example of how to use non-static
permissions in ActiveRBAC, or can this only be used for an anonymous
user?
I guess what I am really wondering is why not represent all
permissions with the same model/table, possibly with an "is_static"
field to tell them apart if desired. It seems the developer should be
able to query a user or role for permissions, and it should look at
both static and non-static permissions, like this...
global_edit = new Permission(:identifier => 'edit').save!
address_edit = new Permission(:identifier =>
'address.edit', :controller => 'address').save!
admin = Role.new(:identifier => 'administrator').save!
user = User.find_by_login('larry')
user.roles << admin
admin.permissions << address_edit
larry.has_permission?('edit')
=> false
larry.has_permission?('address.edit')
=> true
admin.permissions << global_edit
larry.has_permission?('edit')
=> true
larry.has_permission?('address.edit')
=> true
Possibly I still do not understand?
Peter
>
> Hi Manuel,
>
> Thanks for your reply. I think I understand what you are calling
> static (global) permissions. Where I am still confused is how you
> would implement non-static permissions with ActiveRBAC.
>
> The only place I can find any reference to using non-static
> permissions is in the documentation for "RBAC schema level 1".
> Although, it's not entirely clear if it is the developer's
> responsibility to implement the non static permission methods and
> model relationships?
Yes, it is the developer's responsibility right now. I have not
needed and thus not implemented contextual roles yet.
> I also see that acts_as_anonymous_user_test.rb is using an OpenStruct
> to define permissions. Is this an example of how to use non-static
> permissions in ActiveRBAC, or can this only be used for an anonymous
> user?
Oh, this is just so the tests are a bit more isolated from the databse.
> I guess what I am really wondering is why not represent all
> permissions with the same model/table, possibly with an "is_static"
> field to tell them apart if desired. It seems the developer should be
> able to query a user or role for permissions, and it should look at
> both static and non-static permissions, like this...
<snip>
Contextual roles were more meant to work like this (note that I just
made this example up - a real implementation should maybe think about
better names):
article = Article.new(:title => 'test').save!
editor = Role.new(:identifier => 'roles.editor').save!
create_perm = StaticPermission.new(
:identifier => "permissions.articles.create").save!
update_perm = ContextualPermission.new
update_perm.context_class = 'article'
update_perm.context_object_id = article.id
update_perm.action = 'update'
update_perm.save!
editor.contextual_permissions << update_perm
john = User.find :email => 'd...@example.com'
john.roles << editor
Now John and all other editors can edit the article "test".
Bests,
Manuel