Roles

Can someone spare a bit of time to help me understand roles? Policy templates and policies are a piece of cake. But roles still baffle me. I tend to just give everybody and everything 0 and leave it at that, which is not really the Way Things Are Done.

Let's take an example where I suspect roles would play a part.

Each user belongs to two groups, one "common" group and one "userxyz" group. There is also a resource group "userxyz" for the user's resource, and each user has his own resource. This is all generated nicely with a plugin when creating a new user - see MemberPages.

Each user can only see one resource, his own resource. All user resources are under a parent/container resource, "Users".

So far so good. Except the users can all edit the parent/container resource, which belongs to a "common" resource group.

I want the users to be able to edit their own resource, but he must also be able to see, but not edit, the "Users" parent resource, or he can't see its children.

I would presume this would be done with roles - the role of the "common" group being lower (or higher numerically) than that of the "userxyz" group. Or something. At this point I go find something else to do. Yes. My oven needs cleaning.

I would not use roles for this (or anything else, for that matter). Roles in Revo are generally only useful if you want to have users in the same user group who have different capabilities -- but if you want them to have different capabilities, why not just put them in a different User Group?

Having them in different User Groups makes things much easier to understand and troubleshoot, imo.

It sounds like you want the parent/container resource in different Resource Group than its children.

Users who shouldn't edit it go in a separate User Group and that group gets access to the container resource with a Resource Group Access ACL entry with a policy of "Load, List, and View."

The users who *should* be able to edit the container resource go in a different User Group with a similar Resource Group Access ACL entry, but with a Policy of Resource.

Users with access and editing rights to the Resource Group the Children are in get a separate Resource Group Access ACL entry for the children's Resource Group with a policy of Resource.

Then I understand them less than I thought I did.

Quote from: sottwell at Aug 14, 2014, 03:26 AM

Then I understand them less than I thought I did.

In Revo, this is their *only* job:

Users in a user group inherit the policies/permissions of other users *in the same group* whose roles have higher authority numbers.

I think roles could be useful for a site with dozens of user groups and resource groups, but even then, I probably would not use them. I don't think they are appropriate for less complicated sites.

I have argued strenuously and at length for a return to Evo-style role-based security permissions in 3.0. Role-based Systems are much easier to understand and use, imo. I don't know if I have had any effect or not.

That still doesn't make any sense at all to me. Users don't have permissions, groups have permissions. What you just wrote looks to me like you are saying that if user A gets his permissions from group A and group B, then user C who belongs to group A but not group B will inherit user A's permissions from group B?

No, not at all. I'll try to be clearer, though your confusion is exactly why I suggest giving every user on your site the same role (or at least the same authority level number).

Inherit isn't really the right word, but it's much shorter to write than what's really happening. First, though, no user would ever get permissions based on something in another group that they're not a member of. The "inheritance" is only within a particular group.

It's a useful shorthand to think that groups have permissions (and the shorthand concept works well if all users in the group have the same authority level -- granted by the role in their group). But User Groups don't really have permissions.

Policies have permissions (the checked ones), and users have all the permissions granted to them in the various ACL entries that apply to them. Remember, though, that when you create an ACL entry, you specify a minimum role and a Policy.

Anyone in the specified User Group *who has that minimum role* has the permissions granted by that ACL entry's Policy.

So, if you target an ACL entry at users with a particular role level (say 15), a user *in the same user group* with a role that has an authority level of 10 is going to have all the permissions granted by the ACL entry too. They haven't really "inherited" them, but the effect is the same.

BTW, Role names mean absolutely nothing, only the authority level that goes with the role has any effect. You can change role names all over the site and it won't affect anything as long as the authority level doesn't change.


Here's a concrete example of the "inheritance":



User C will only have the permissions checked on the LowAccess Policy.
User B will have those, plus the ones checked on the MediumAccess Policy.
User A will have all the permissions checked on all three policies.

(Remember that when you specify a "Minimum Role" it means that the ACL entry will only apply to users with that authority level number or a *lower number* -- lower number = higher authority).

Typically, as you went from the LowAccess to MediumAccess to HighAccess Policy, you would just check more permissions, but it's not required. The three policies could each have any pattern of permissions, but (and this is the main point) -- B is always going to get the permissions C has, and A is always going to get the permissions of both B and C. Only in this group, though, the permissions a user gets from being in another group have no effect on the other members of this group.

Put another way, there's literally no way to give C a permission (via an ACL connected to the Editors User Group), that A and B are not going to get.

Now you see why I say not to use roles for anything. It keeps me from having to try to explain them.

"role" is just the wrong word for what it does. It should be "level" or something like that.

As i understand it, "usergroup" is for topics like "can edit content but not change snippets". "role" would be "can create and edit all content, even delete" (15 or something), "can edit existing content but not create or delete" (10 or so).

So "role" is not a role but more like "boss, employee or boy scout in the same department".

Anyway, its far too complicated. ACL is a lot easier in other softwares.

I agree about the complexity, but if you think of the word 'role' as a label for levels of authority (so you don't have to remember the numbers), it kind of makes sense.