User access levels / User Accounts assistance

[robcarey]

Howdy all!

Does anyone have any good extras or documentation that clearly and easily* explains how to set up different user level accounts in MODX?

I’ve been building sites in MODX for over 12 years now, but I STILL struggle with getting the most basic of access levels accounts created. Things like an account I can create that can be used to just see pages not yet published - so a basic front end reviewer type account. Also would love to know how to create an account for a user level that can create and edit resources, but perhaps not publish.

This may sound trivial, bit I’m not exaggerating when I say I have wasted hours and hours in trying to get these to work in easy to understand and use manner. The last two sites I built I quite literally crashed the sites just creating new user groups/access policies. I have no idea how or why - but the only way to get the site live again was to delete the new user group. Why does doing this have that kind of repercussion?

This type of thing really (really) needs to be MUCH easier to do. We all build sites for people that should not have the full keys to the kingdom in their hands, yet this ability is about as convoluted as I’ve ever seen in a UI/tool.

I’ve been looking for the “a-ha” moment to this aspect of ModX for over a decade. Anyone else find it?

[NuzyWeb]

These helped me a lot when I setup permissions…

Making Member-Only Pages - Security Tutorials

User Groups - Security (ACLs)

Permissions - Policies

Roles - Security (ACLs)

Policies - Security (ACLs)

The summary is that you can assign users to groups and groups can have roles with different policies.

It can get tedious if you have a lot of variations between user access requirements, but it can also be very easy going because it’s straight-forward to get setup.

[robcarey]

Thanks - I have gone through these before, and I still don’t have a clear understanding of the simple use case of a user account to be able to just view unpublished pages for example.

Do I need a new user group? A new role? A new security policy? All of the above?

[markh]

Policy has a group of enabled permissions. For example view_unpublished, edit, save, etc. Policies are based on Policy Templates which defines all possible permissions a policy can check, and are grouped by what they affect (access to the context/manager, access to a media source, etc). Third party extras may define additional policy templates and policies for their specific functionality.

The User Group is then associated with any number of Policies, most commonly on the Permissions > Context Access tab. Remember that the manager is a context, so to restrict what someone can do in the manager you assign context policies for the mgr context.

So add your policy that includes view_unpublished to your editor user group, as well as any other policies you’d like them to have.

Ignore roles entirely. When adding a policy to a usergroup, or a usergroup to a user, just always use the role member/9999. There’s no need to make things more complex by adding different roles within a user group, at least not for 99.5% of use cases.

Finally, remember MODX uses “Public, unless”, meaning all actions or information is public until a usergroup has been given specific access to it, in which case other usergroups are blocked from accessing/performing it until they also have the specific access. Typically that’s easiest to wrap your head around and accomplish limited access accounts by having a full administrator usergroup with ALL permissions, to ALL contexts and ALL media sources, etc, and a separate user group that only has the access they should have.

Also if you restrict anything that anonymous users must have access to (including contexts, media sources to access elements inside them, and categories containing elements executed in the front-end), then make sure to also give that access to the (anonymous) usergroup.

[robcarey]

So…

Step 1. Create access policy template. In this example just check “view_unpublished” since that’s the only additional thing I’d like them to have access to beyond publicly accessible resources.

Step 2. Create access policy and assign the previously created template?

Step 3. Create user group and assign the previously created access policy?

[markh]

@robcarey

Step 1. Create access policy template. In this example just check “view_unpublished” since that’s the only additional thing I’d like them to have access to beyond publicly accessible resources.

Step 2. Create access policy and assign the previously created template?

No - you do not have to separately create a policy template. The permission you’re trying to use is already part of a policy template. (Of the top of my head, I think that’s in the AdministratorTemplate?) Only if you’re creating new permissions for an extra or whatever, then you’d need to think about creating a new policy template.

Skip directly to step 2 to create the policy you want to use, and to add to the user group (step 3).

I’d generally suggest having a single policy per user group/context/policy template that has all the permissions for that combination over using a default policy and then a one-permission policy, but both approaches should work because permissions do get merged. That said, there is a reported edge case on GitHub, where having small compounding policies can actually not work as expected depending on how those are checked (by the core), reported as affecting some resourcegroup related permissions but that could potentially affect other checks too.

[robcarey]

Quick follow up - so I’ve done what you suggested above just now to give it a try - thanks for the clarifications

I created a new access policy called previewer based on the administrator policy template. I left all 182 of 182 checked for testing - didn’t change anything.

I then created a new user group called Previewers: web as context, Manager Policy of “previewer”.

I then added a new user to that new group. I get a permission denied when trying to log in this user to the manager - I assume because the context is web and not manager, however I thought perhaps the login would still set the session levels for a previewer as I moved through the front end - which does not seem to be the case, as I can not view any unpublished pages if I try to access them directly after trying this.

Am I right in assuming I just need now to build in a front-end accessible login form using login that accesses the web context and I’d be good?

TIA

[robcarey]

Never mind - I answered my own question. Built a front-end login and it works as expected. - I appreciate your help on this. Definitely helped slide me closer to the “a-ha” end of the scale
Cheers!

[markh]

Glad you got it sorted

In my experience/opinion, people overthink the complexity. People hear how awful they are and already dread it before starting.

Yes, ACLs have a bunch of different concepts and you need to understand the basics of how they work in order to not shoot yourself in the foot (I sure have in the past!), but if you focus on the policy and what it gets applied to, it doesn’t have to be a nightmare.