Permissions, multiple contexts, read only and context managers

andreasz · June 20, 2025, 10:15am

Summary

Setting up permissions for a user results in completely unexpected behavior. My suspicion is that only one policy is active at a time and permissions aren’t added according to matching authority, as stated in the documentation.

Step to reproduce

On a 2.8.8 install, I have a large page with 30 different language contexts. A common practice for those kind of pages is that there is a main-franchise website that other franchisees are supposed to inherit and/or modify existing content based on that. So:

Install babel
link resources in different contexts accordingly
setup a user group with basic admin permissions (load, list, view, frames, etc.)
setup context user groups with specific permissions per-context (save_document, edit_document, view_unpublished, etc.)
assign a user to the basic admin and to a specific context

Observed behavior

Now if logged on with that particular user, the context will show “locked” even though the permissions for that context are setup correctly.

For the EN context, this is expected behavior. The user is in the basic admin group and should be able to see this context and view the resources, but only be able to save and edit in the NL context.

The above is unexpected behavior. The user is in the correct group:

Here’s the affected permissions summary when editing the context. Looks good to me:

And here’s how those permissions are setup:

No matter what I do, the one and only permission profile that seems active is the one for the basic manager and MODX seems to completely ignore anything context-specific.

Also: The user with the Basic Admin profile is able to see all contexts, even though they should be restricted to just the ones they have access to. I don’t know why they’re seeing all of them.

When I added the save_document permission to the mgr context, it applies globally for all contexts, also the ones that the user is not supposed to have access to. I don’t really know if this is expected.

Expected behavior

The user should be able to have full edit permissions, save, move, delete, etc. and read-only permissions on the main franchise context. They should only see the four contexts I gave them permission to and only have CRUD permissions on those.

Environment

MODX 2.8.8, running in a docker environment with current Apache and nginx reverse-proxy. Everything else is current, I don’t think any of the infrastructure underneath is really relevant for this behavior.

So, to cut a long story short: What am I missing? I logged out/in, cleared cache, etc. etc. - I am lost.

halftrainedharry · June 22, 2025, 7:27am

The “Locked” button implies that the user doesn’t have the save permission.
The save permission doesn’t seem to be part of the “Franchisee CRUD” policy.

From what other user group or access policy should the user get the save permission in the context “web-nl”?

andreasz · June 26, 2025, 8:29am

Hey,

yeah, that’s not the problem. The save_document permission is more granular and should unlock this permission. However, it will only be working if it’s in the mgr profile and not in the context-specific one.

So… Long story short: No takers?

halftrainedharry · June 26, 2025, 4:26pm

When you work in the MODX manager, the current context is “mgr”, and when you save a resource, it is only checked if you have the save_document permission for the “mgr” context (no matter in what context the resources was created).

Having the save_document permission in another context (like e.g. “web-nl”) would only be relevant, if you accessed the resource on the front-end and then (for example) checked this permission in a snippet ($modx->hasPermission('save_document')).

I think the only way to restrict a certain user in the manager from editing resources in a certain context, is to not give them any permission to that context.