Revolution Permissions

I thought I was beginning to get this -- maybe not.

I tried to set up permissions for a user who could only see and edit his own page in the Manager.

The user is JoeBlow.

I set up role called JoeBlow with an authority level of 9998.
I set up a resource group called JoeBlow and added his page to it.
I set up a user group and added him to it with a role of JoeBlow.

Under Context Access, I gave the user group Mgr context access with a mininmum role of 9998 and assigned the standard Resource policy.

Under Resource Group Access, I added the resource group with a context of Mgr, a minimun role of 9998, an Access Policy of Resource, and a Context of Mgr.

The result is that JoeBlow gets a permission denied error on logging in and, when logged in as the superadmin, I can no longer see his page.

Any clues appreciated.

[Update] by changing the Resource Group Access to have an Access Policy of Administrator (rather than Resource) I can log in as Joe Blow and see the Manager, but with no resources showing in the tree. I tried adding the docs in the path to Joe Blow’s page to the Resource Group, but it had no effect.

Bump . . .

You need to add the Context policy for web context in addition to the mgr context, or the user will not have permission to "load" the web context containing the Resources.

Got it. Thanks.

In Evo, it was easy to restrict access to documents in the Manager without affecting access to them in the front end by creating Manager Resource Groups. What’s the Revo equivalent?

Everything I’ve tried makes them unauthorized in the front end.

Quote from: BobRay at Dec 15, 2009, 09:50 PM

Got it. Thanks.

In Evo, it was easy to restrict access to documents in the Manager without affecting access to them in the front end by creating Manager Resource Groups. What’s the Revo equivalent?

Everything I’ve tried makes them unauthorized in the front end.

Don’t attach Resource Group access controls to the web context; attach them only to the mgr context to restrict access in the backend.

Quote from: OpenGeek at Dec 16, 2009, 10:23 AM

Quote from: BobRay at Dec 15, 2009, 09:50 PM

Got it. Thanks.

In Evo, it was easy to restrict access to documents in the Manager without affecting access to them in the front end by creating Manager Resource Groups. What’s the Revo equivalent?

Everything I’ve tried makes them unauthorized in the front end.

Don’t attach Resource Group access controls to the web context; attach them only to the mgr context to restrict access in the backend.

I got that far, but when I do that, the admin can no longer see the documents in the tree, even though he is a member of the user group attached to the resource group with a role of super user.

TBH, I’ve been working on understanding Revo permissions for over a month now and I feel like I know less now than when I started. :’(

Quote from: BobRay at Dec 16, 2009, 10:37 AM

I got that far, but when I do that, the admin can no longer see the documents in the tree, even though he is a member of the user group attached to the resource group with a role of super user.

Did you flush permissions after changing the access controls? All permissions are cached in the user session until you do this.

Quote from: OpenGeek at Dec 16, 2009, 11:25 AM

Quote from: BobRay at Dec 16, 2009, 10:37 AM

I got that far, but when I do that, the admin can no longer see the documents in the tree, even though he is a member of the user group attached to the resource group with a role of super user.

Did you flush permissions after changing the access controls? All permissions are cached in the user session until you do this.

Yes -- several times.

What should the context access be for the user group?

Quote from: BobRay at Dec 16, 2009, 11:39 AM

What should the context access be for the user group?

They must be able to "load" the web Context (or whatever Context the Resources are in), so create a policy with a single "load" permission and assign the policy to the web Context for that user group. Do not assign the Context policy with all the Context-specific permissions to the web context unless you are giving these users permission to perform all the content management functions they have in the mgr context, from the web context.

It might also help to understand that "load" is a base permission which determines if objects (either Context objects or Resource objects) can be loaded from the database at all.

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).