Revolution Permissions

I’ll be jumping into the mix sometime this week. I have a site I am working on which will be split into contexts with ACLs attached.

Under EVO I simply cheated by creating ajax plugins which only loaded when a snippet validated the owner was on his own page. While on some else’s page the snippet would simply load other ajax icons such as: report, respond, etc.

I only allowed the ajax connectors to load the content I wanted -- they were all dynamic -- i.e. the jQuery calls themselves were only put in the pages if conditions were met when the snippet was ran.

In a since I had already figured out "contexts" in evo. The same page would simply load one of four ajax menus based solely on: anonymous (join now!), owner (extend time, cancel item, etc.), other client (respond, report, watch), or Admin (feature item, make permanent, etc.) In the case an Admin was looking at their own page they got both the owner and admin menus.

If I make heads or tells of the context in REVO, I will write up and provide simple samples during the process.

Might as well put those 9 degrees to good use for something...

Quote from: goldsky at Jan 11, 2010, 08:15 PM

Bob,
have you figured this out?
I’m waiting your guide on this. :p

I believe I have, and I think OpenGeek is right that it’s not as complicated as I’ve been making it sound. I hope my confusion hasn’t been contagious.

I still haven’t figured out how best to explain it, however.

You may have to wait for my book.

OpenGeek: The important point being if you create ACLs to Contexts other than mgr, don’t use the included Context Policy. Instead, you should either create a new Context Policy with just the "load" permission or understand that you are giving Users in that group permission to perform all content management operations defined in the default Policy from that Context. This will be clearer once some front-end editing solutions are developed for Revo.

I need some clarification here. Are you talking about Context Access ACLs or Resource Access ACLs, or both?

By "included Context Policy" do you mean the standard Administrator policy or the standard Resource policy?

I’m guessing that you mean Resource Access ACLs and the standard Resource policy, but thought I’d better make sure.

Quote from: BobRay at Jan 19, 2010, 12:47 AM

OpenGeek: The important point being if you create ACLs to Contexts other than mgr, don’t use the included Context Policy. Instead, you should either create a new Context Policy with just the "load" permission or understand that you are giving Users in that group permission to perform all content management operations defined in the default Policy from that Context. This will be clearer once some front-end editing solutions are developed for Revo.

I need some clarification here. Are you talking about Context Access ACLs or Resource Access ACLs, or both?

By "included Context Policy" do you mean the standard Administrator policy or the standard Resource policy?

I’m guessing that you mean Resource Access ACLs and the standard Resource policy, but thought I’d better make sure.

I’m talking only about Context ACLs here, i.e. "...if you create ACLs to Contexts...", and the Administrator Policy (which is a Context Policy, since Context Policies define permissions to content management activities, and not to specific Resource Groups).

Ok. You’re answer implies (to me anyway) that if you give someone access to the web context with the standard administrator policy, they will have full access to all actions in the manager even though another context ACL gives them access to the mgr context with a much more limited access policy. I know that’s not the case so I’m not sure what you *do* mean.

Quote from: BobRay at Jan 19, 2010, 09:38 PM

Ok. You’re answer implies (to me anyway) that if you give someone access to the web context with the standard administrator policy, they will have full access to all actions in the manager even though another context ACL gives them access to the mgr context with a much more limited access policy. I know that’s not the case so I’m not sure what you *do* mean.

I mean the policy attached to the web context would give them permission to the content management actions from code in the web context; think front-end editing add-ons. It would not affect permissions to actions taken from the mgr context, only if taken from the web context.

Ah, that makes sense.

Am I correct in assuming that the "web" context access ACL would only apply to actions that alter resources, not to other actions (e.g. changing security settings using some front-end tool)?

Along the same lines, I’m also wondering about actions taken by snippet and plugin code triggered by a page visit in the front end. I’m assuming that ACLs govern whether the code can perform actions from the front end like clearing the cache, creating a new user, etc., but would that be affected by a web context access ACL or a mgr context access ACL, or both in different situations?

I hope this question makes sense.

May I interrupt for a sec?
Does Revo also allows grain permissions for individual Component?
I assume that component is similar with module in evo, which at the current release doesn’t have any individual permission attached to each module.

I guess your discussion here can be explained that both of front-end and back-end have a very flexible permission. This particular back-end permission improvement should be applied since MODx Revo’s back-end will have more customization, too. no?
Am I wrong to state that ACL and RGL (Resource Groups List) is about many to many relationship?

Quote from: BobRay at Jan 20, 2010, 09:48 PM

Am I correct in assuming that the "web" context access ACL would only apply to actions that alter resources, not to other actions (e.g. changing security settings using some front-end tool)?

No, policy permissions applied through the Context ACL are global permissions that apply to any action taken by the user in that Context. Changing security settings is controlled by the permission access_permissions and applies to the user and the action taken from any Context.

Quote from: BobRay at Jan 20, 2010, 09:48 PM

Along the same lines, I’m also wondering about actions taken by snippet and plugin code triggered by a page visit in the front end. I’m assuming that ACLs govern whether the code can perform actions from the front end like clearing the cache, creating a new user, etc., but would that be affected by a web context access ACL or a mgr context access ACL, or both in different situations?

Both in different situations. It’s determined by the context ACL attached to the context they are taking the action from; so if it was a tool in the web context that called the clear cache processor, it would check the empty_cache permission to determine if that action was allowed for the user.

Quote from: goldsky at Jan 20, 2010, 10:59 PM

Does Revo also allows grain permissions for individual Component?
I assume that component is similar with module in evo, which at the current release doesn’t have any individual permission attached to each module.

Yes, you can design policies with custom permissions that relate to custom Component actions. These can then be attached to contexts just like any other Context policy.

Quote from: goldsky at Jan 20, 2010, 10:59 PM

I guess your discussion here can be explained that both of front-end and back-end have a very flexible permission. This particular back-end permission improvement should be applied since MODx Revo’s back-end will have more customization, too. no?
Am I wrong to state that ACL and RGL (Resource Groups List) is about many to many relationship?

The Context ACL links User Group members with Contexts and the permissions they have in each Context; this replaces User Roles and the permissions Users were granted via their Roles in Evo. The Resource Group ACL links User Group members with Resource Groups in a particular Context; this is pretty much the same as Evo’s Resource Groups tied to Web Permissions and/or Manager Permissions, except we can and have defined more granular permissions (via Policies) for these Resource Group access controls, such as defining if a User Group is allowed to add_children to a Resource that is in the Resource Group.

Ok, let me see if this will fly.

A user group has a context access ACL that gives mgr context access and a policy without access_permissions
The same user group has another context access ACL that gives web context access *with* access_permissions.

Those users can’t access permissions in the Manager but can do so using a front-end tool?