Revo Security - look but don't touch

I'm trying to set up the Security to the Manager on my Revo install (2.1.3), and something that was available on Evo doesn't seem to be achievable on Revo.

I've got a resource group with some 2nd level resources (ie., "web" (context) > "Home" > "2nd lvl item"), and added the to my Editors user group, with the minimum Role of "Editor - 100". My intent is that the Editors can access the 2nd lvl items to edit, save, create, etc, but not be able to edit the 1st lvl items. At the moment, all of the resources under the web context are hidden in the manager.

In Evo it was a matter of changing the "Show Protected Pages" of the Config Settings. I can't seem to find a parallel setting in Revo; and I can't unhide only the resources I need to make available to the Editors. How do I get around this?

Don't use Roles. Assign the permissions to Members (authority = 9999) unless you need more granular permissions within a User Group (i.e. this person has a Role of "Super User" in my "Special" Group). Unless your users have the Role you assigned (or one with a lower authority value, which means more authority, 0 having the most) they will not have the permissions you intended unless they have the Editor Role within the Editors Group. Adding the Editors Role just complicates things unnecessarily. You just need Members of the Editors User Group from what I can tell.

You also have to apply this by assigning a Policy with the permissions you want to give the Members of the User Group for the Resource Group.

You might find these helpful:

http://bobsguides.com/revolution-permissions.html


http://bobsguides.com/revo-security-tutorials.html

Thanks for those. @BobRay: I was working from the first link you posted, and thought I had done everything that you specified. I'll take a look again through it, and will also have a look at the other link. Am still trying to get my head around Revo perms, Evo was much easier to get a handle on.

@OpenGeek: So what you're saying is that each member should NOT have a role assigned to them other than Member-9999, and then the ACL for the User Group will take care of what the user can or can't see/do in the Manager? If that's the case, what role do Roles play in the revo perms structure?

Just to clarify - i'm trying to lock user groups into being able to view only particular resource groups and then be able to edit only specific resources within those viewable groups within the Manager. Front end remains open.

@BobRay - I've tried implementing the tutorials to Control Access and Hide Resources, but neither of them is restricting my Editor user from viewing and accessing the restricted areas, and the roles are not restricting the actions. I don't know what's wrong, I've set up everything like your tutorial.

The function of roles in Revolution is very different than in Evolution. The only use of roles in Revo is to assign authority levels to users. That's only useful when you need to have different users in the same user group with different permissions (which I still can't tell if you need or not -- probably not).

The way to hide resources from specific users is to connect the resource group of the resources to a user group that those users don't belong to with a Resource Group Access ACL entry.

Remember that resources can belong to more than one resource group.

So one way to do it is to put *all* the resources you want to protect in any way into a resource group and attach that resource group to the Administrator User Group with a Resource Group Access ACL entry. None of the "Editors" should belong to the Administrator group.

That should hide all those resources from all non-members of the Administrator group.

For your other group(s), you'll need to create a Context Access ACL entry with a context of mgr (so they can log in) and another one with a context of 'web' (so they have the potential to see resources in the 'web' context).

At this point, they still shouldn't see any of the protected resources.

Put the resources they should be able to see but not edit in a resource group and connect that to the user group with a Resource Group Access ACL entry with a policy of 'load, list, and view.' If that doesn't give them enough rights, you can use a duplicate of the 'Resource' policy, with some permission unchecked.

Put the resources they should be able to see *and* edit in another resource group and connect it to the user group with a Resource Group Access ACL entry with a policy of 'Resource'. As OpenGeek says, they don't need to have a role of "Editor" for this. They could have the "member" role as long as you won't have other Manager users who have even less authority, and even then, those users could be in different user groups and get different policies.

It's not clear to me from your message if you need to have some Editors who can do things with the same resources that others can't. If so, there are two ways to go. You can create another user group (e.g., JuniorEditors) and use the same steps described above, or you can have group members with different roles where the users with the lower-authority-number role get the 'load, list, and view; policy and the others get the 'Resource' policy (or something similar using your own policies).

I would lean toward separate user groups since it allows finer control if you use Form Customization.

Hope this makes sense.

Right. That makes a whole bunch of sense, and it's what I was thinking I should be heading towards. Let me see if I have this right: to hide/restrict a resource/element from one user group requires an equal and opposite enabling for another user group of a higher authority level. Is that a correct statement?

Maybe I should have outlined this at the beginning. The plan I have to follow is to divide the resources into particular areas along the 2nd lvl resources. For each area there will be 2 types of users (roles): Editors who create/edit/save/move resources, but don't (un)publish or (un)delete; Area Managers, who create/edit/save/move/delete, but not (un)publish; lastly, Publishers will have all of those permissions including publish, but they aren't restricted by area, and can move resources between areas.

Then above the Publishers is the SysAdmin (totally different access permissions), then the Site Owner (inherits all other access plus some, but still not full), then me as Site Admin. On top of this, I'm using multiple contexts. Because it wasn't complex enough already ! But I can see how your explanation just now will work for that, so I'll give it a shot and see if I can get my head around it.

One question I still have tho; how do the access permissions for particular contexts work with all of this? It would be great to minimise the visibility of some of my contexts, both in the front end and in the manager.

Lastly, there's no specific documentation on the actions listed in the default policies and policy templates. So for instance, the Load, List and View policy is obviously the policy needed to only allow viewing of a resource, but there's no comments or online documentation to denote this. Can that documentation be added to Dashboard?

Ok, have managed to start putting this all together. Have done those 3 things:

• Restricted all page views to the Admin only;
• Made specific areas only viewable to a specific user group; and
• enabled some of those viewable pages to be editable.

Question: When I make an area Viewable Only, the resource that I put into the Resource Group is restricted from editing, but the children are not. With Evo's Docmanager you could add a resource and its children to a resource group automatically, is there a way of doing that in Revo? Or do I have to go and add each of the resources to the group?

I think you still have to add the children manually, but remember that in Revo, you can do this with drag-and-drop.

About hiding Contexts, you can basically hide them with a Context Access ACL entry connecting each context you want to hide to the Administrator resource group (and not creating a similar ACL entry for other groups , except those that should see the context).

Ok, should I do that by editing the context itself, or in the "Update User Groups" section?