Revolution Permissions

Quote from: BobRay at Dec 16, 2009, 03:38 PM

Ok, I’ve got what I want, more or less in terms of the tree. The user can see and not see what I intend in the tree and the docs are visible in the front end. But I can’t seem to give the user the ability to log in to the Manager (permission denied) unless I put him in the administrator user group too, with a role of super user (in which case he can edit his own permissions and change them).

You need to create a limited Context Policy for your sub-administrators, taking away whatever permissions you don’t want them to have. Then apply that to the mgr context for their User Group.

Will do.

Am I correct (or even close) in saying that when creating/updating a user group:

1. Policies on the Context Access tab should be based on the Administrator policy.

2. Policies on the Resource Group Access tab should be based on the Resource policy.

??

Quote from: BobRay at Dec 17, 2009, 01:37 PM

Am I correct (or even close) in saying that when creating/updating a user group:

1. Policies on the Context Access tab should be based on the Administrator policy.

2. Policies on the Resource Group Access tab should be based on the Resource policy.

That’s exactly correct.

Quote from: OpenGeek at Dec 18, 2009, 10:46 AM

Quote from: BobRay at Dec 17, 2009, 01:37 PM

Am I correct (or even close) in saying that when creating/updating a user group:

1. Policies on the Context Access tab should be based on the Administrator policy.

2. Policies on the Resource Group Access tab should be based on the Resource policy.

That’s exactly correct.

I guess there’s a first time for everything.

Ok, a few more questions:

1. When a situation is covered by more than one permission setting (e.g. doc in more than one resource group, user in more than one user group), does the most restrictive case apply or the most permissive one?

2. What exactly does ACL refer to in the Manager? I’m assuming it’s the Context Access tab in Update User Group and the Resource Group Access tab. It’s confusing when the docs focus on ACLs and there’s no reference to an ACL anywhere in the Manager.

3. When we say that a role inherits roles/policies with higher authority numbers, that means just in that particular ACL, right, not all roles/policies with higher authority numbers anywhere on the site?

Quote from: BobRay at Dec 21, 2009, 11:59 AM

1. When a situation is covered by more than one permission setting (e.g. doc in more than one resource group, user in more than one user group), does the most restrictive case apply or the most permissive one?

Most permissive.

Quote from: BobRay at Dec 21, 2009, 11:59 AM

2. What exactly does ACL refer to in the Manager? I’m assuming it’s the Context Access tab in Update User Group and the Resource Group Access tab. It’s confusing when the docs focus on ACLs and there’s no reference to an ACL anywhere in the Manager.

An access control list generically refers to any set of access control entries, i.e. User Group -> Policy -> Context or User Group -> Policy -> Resource Group -> Context. In the future there may be other ACL’s that set permissions on Elements directly, Menus, or any other object that extends the modAccessibleObject base class.

Quote from: BobRay at Dec 21, 2009, 11:59 AM

3. When we say that a role inherits roles/policies with higher authority numbers, that means just in that particular ACL, right, not all roles/policies with higher authority numbers anywhere on the site?

That’s correct, the roles/policies are tied together by a single access control entry and the user will inherit all the apply to the User Groups they are in with a role which provides an authority number equal to or greater than their membership role in the User Group.

Quote from: OpenGeek at Dec 21, 2009, 12:46 PM

Quote from: BobRay at Dec 21, 2009, 11:59 AM

Quote from: BobRay at Dec 21, 2009, 11:59 AM

2. What exactly does ACL refer to in the Manager? I’m assuming it’s the Context Access tab in Update User Group and the Resource Group Access tab. It’s confusing when the docs focus on ACLs and there’s no reference to an ACL anywhere in the Manager.

An access control list generically refers to any set of access control entries, i.e. User Group -> Policy -> Context or User Group -> Policy -> Resource Group -> Context. In the future there may be other ACL’s that set permissions on Elements directly, Menus, or any other object that extends the modAccessibleObject base class.

There is no User Group -> Policy in the current SVN (It’s User Group -> Context Access and User Group -> Resource Group Access), but I get what you mean. Thanks.

One more question:

If two roles have equal authority numbers, are the policies/permissions inherited from one to the other on an ACL, or does the authority # have to be greater to be inherited?

Quote from: BobRay at Dec 21, 2009, 02:01 PM

One more question:

If two roles have equal authority numbers, are the policies/permissions inherited from one to the other on an ACL, or does the authority # have to be greater to be inherited?

There is no true inheritance here, the access control entries stored per user are evaluated starting with the lowest authority first, so the policy attached to a Role with the lowest number is evaluated first. Having two Policies for Roles with the same authority in the same group does not make sense and the first record would apply; the whole purpose of a Role is to give users more or less Permissions than others in a particular Group.

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?