Revolution Permissions

Quote from: BobRay at Dec 21, 2009, 03:28 PM

So is it correct to say that it’s possible to create different roles with the same authority number, but it shouldn’t be done?

It shouldn’t be done unless you intend to use different Role names within different User Groups. I think we should aim to enable an option to be able to limit the selection of Roles based on the User Group at some point to make interacting with the management interface more intuitive.

Do anonymous (not-logged-in) users in the front end have an authority number?

I’m wondering how to restrict editing of resources in the front end while still having them viewable by anonymous users.

Quote from: BobRay at Dec 21, 2009, 04:08 PM

Do anonymous (not-logged-in) users in the front end have an authority number?

Policies attached to anonymous users are always evaluated with an authority of 9999.

Quote from: BobRay at Dec 21, 2009, 04:08 PM

I’m wondering how to restrict editing of resources in the front end while still having them viewable by anonymous users.

Simple, put them in a Resource Group and only attach a Policy to the mgr context. You can also explicitly attach a Policy to Anonymous users in the web context (or any other context), though in this simple case that is not necessary.

Quote from: OpenGeek at Dec 21, 2009, 04:14 PM

Quote from: BobRay at Dec 21, 2009, 04:08 PM

I’m wondering how to restrict editing of resources in the front end while still having them viewable by anonymous users.

Simple, put them in a Resource Group and only attach a Policy to the mgr context. You can also explicitly attach a Policy to Anonymous users in the web context (or any other context), though in this simple case that is not necessary.

I wouldn’t have thought that would restrict editing them in the front end.

me thinks that this stuff is too complex. ...

ok.. i m out.

Quote from: zi at Dec 21, 2009, 11:59 PM

me thinks that this stuff is too complex. ...

ok.. i m out.

It is somewhat complex, but don’t base your decision on my confusion -- I’m easily confused.

OTOH, I would feel somewhat better if others were confused as well.

I think i’m more confused than you bob

Quote from: BobRay at Dec 21, 2009, 04:19 PM

I wouldn’t have thought that would restrict editing them in the front end.

Sorry, I didn’t understand the question then; but editing in the front-end with what? At the current time there is no front-end editing capability/component for Revo.

Regardless, to do so, you would give anonymous users access to the Resource Group with a minimal Resource Policy (i.e. load, list, view), and assign both a Context policy to the Admins in the context in question for giving them permissions to the processors required for editing as well as the Resource Group policy that includes the save permission in that context. It’s really not that complex once you understand that Context policies control both the basic permissions to access a context as well as global permissions to perform content management activities from a specific Context (i.e. delete_chunk, publish_document, save_category), and that Resource Group policies give more granular permissions to control access to/work with the specific Resources in a context (i.e. add_children, move, create, etc.).

Yes it is a little more involved than Evo permissions, but the capabilities are infinitely more flexible and more granular. Once we all better understand these, we can pre-define entire security models, package them up, and make them installable from the repository so users who do not need to understand all the power of the system can simply apply the packaged Policies as needed for their site.

And can ask if you don’t have a specific question or input that you avoid posting "I’m confused" messages that do nothing to help anyone’s understanding. We know this is not explained well or intuitive enough yet, and we are doing our best to help alleviate this as quickly as possible.

I’m definitely getting closer to understanding it, but don’t want to make any more suggestions until I’m sure.

Here’s a concrete example that will probably show where I’m still confused.

I have a user, Joe Blow, (let’s say a salesperson with a profile page on the web site) that I want to be able to edit just his own page. In order to see it in the tree, he needs "list" permissions for the docs in the tree above it.

I have three Resource Groups: Public (all pages), ViewOnly (the ones above his page), and JoeBlowRG (his page).

I have two resource policies: Resource and ResourceViewOnly.

I have three Manager policies: Administrator, AdministratorLite (pretty much limited to resource/TV stuff), and AdministratorRestricted (mgr access but no other rights).

I have a role called SalesPerson with an authority of 9996.

I have three user groups: Administators (at present, just me), Viewers (Joe and the other salespeople), and JoeBlowUG (he’s the only member).

The Viewers UG is easy and obvious (I hope):

Context Access: mgr, 9996, AdministratorRestricted
Resource Access: ViewOnly, mgr, 9996, ResourceViewOnly

Here’s where I get confused.

The JoeBlowUG currently has this setup:

Context Access: web, 9996, AdministratorLite
mgr, 9996, AdministratorLite

Resource Access: JowBlowRG, 9996, Resource, Mgr


This all seems to work -- Joe can edit his own page and can see, but not edit, the pages above it and can’t see any other documents in the tree.

I’m still not confident it’s the best way to do this. Should I, for example, put Joe in the Admin users group and give him some of his rights there? Let’s assume that he’ll never do anything but edit his own page.

So my questions boil down to:

1. Is it better to put all Manager users into the Admin group with different roles or to assign their mgr and web permissions in the other user groups they belong to? It seemed wrong to put all the salespeople in the admin group with the same role (salesperson - 9996).

2. Do you see anything else wrong with how I’ve set this up?

Quote from: BobRay at Dec 22, 2009, 03:23 PM

1. Is it better to put all Manager users into the Admin group with different roles or to assign their mgr and web permissions in the other user groups they belong to? It seemed wrong to put all the salespeople in the admin group with the same role (salesperson - 9996).

This really depends on your overall security model, but the way you’ve given them specific permissions in their specific UserGroup is a valid way to do this. However, if you have a common Policy that will be applied to many different UserGroups, it might be better to approach this by creating a sub-administrative Role within the Administrators group, and give all of these users membership in your Administrators group as well. Or even simpler might be by creating a separate UserGroup for Sales (or Subadministrators) to which you can apply the Policy.

I’m not sure which approach is better, but IMO, using UserGroups unless you absolutely need the granularity of new Roles would be my rule of thumb. The two built-in Roles (Member and SuperUser) should provide enough granularity to keep most security models satisfied.

Quote from: BobRay at Dec 22, 2009, 03:23 PM

2. Do you see anything else wrong with how I’ve set this up?

Not from your description no; I think you are starting to understand it, and I’m getting a better picture of what is not intuitive about it (besides it’s boundless flexibility ).