Is there a way to allow editing access to just one user group, but without putting every resource in another user group? In other words, I want to create a group for one user to edit, but all the other resources have no group at all assigned. I created a group and assigned a user, but that user can see everything.
You put resources in a resource group, and user in a user group.
You can give a user group permissions to a resource group (which then restricts access to the resource group for other user groups).
If a resource is not in a resource group, then access to this resource is not restricted.
Resource groups were primarily designed for restricting front-end access controls to specific groups of Resources such as members-only pages and content. To restrict access to edit/view access in the Manager, you will need to have all restricted Resources in a group and then optionally have the accessible Resources in their own group.
The esiest way to handle this is to use a plugin to put all new resources into a default user group and then others (say under a specific parant Resource) into another user group that this user Group will have access to.
See: DefaultResourceGroup - DefaultResourceGroup | MODX Documentation and Bob's Guides | DefaultResourceGroup Plugin
OK, I was wondering whether DefaultResourceGroup would do that, but if I install it, will it automatically add all existing resources to the default group?
It won’t, but a fairly simple utility snippet will do it for you.
Put this tag in a resource:
[[AddUsersToGroup]]
Create a snippet called AddUsersToGroup with this code:
<?php
/* AddUsersToGroup Snippet */
$docs = $modx->getCollection('modResource');
foreach ($docs as $doc) {
$doc->joinGroup('GroupName', true);
} // No need to save here
Then, just view the resource to run the snippet.
This would be a somewhat faster version:
$doc->joinGroup(12); // replace 12 with the ID of the user group.
If you have a whole lot of resources, try using getIterator() instead of getCollection().
Thanks, saved me having to write my own script!
OK, assigned all resources to a default group, but now I can delete them but can’t purge them from the deleted files, even though that permission is assigned to my user group (Administrator) and the default user group (“Editors”) is included in the Administrator ACL settings for User Group Access. I even made a new access policy called “Resource with Empty Trash”, a duplicate of Resource with “purge_deleted” added, and used that context when adding the default group to the Administrator permissions.
I can purge resources if I turn on “sudo” in my user settings or remove a resource from all user groups.
This is in MODX 2.8.8
Arg. Now when someone logs in who belongs to a new user group, when saving a resource, it gets saved but there is an endless Saving message, with the follow console error:
Uncaught
Object { message: “JsonReader.read: Json object not found” }
ext-all.js:21:339294
read ExtJS
handleResponse /manager/assets/modext/util/utilities.js:360
ExtJS 5
(Async: EventListener.handleEvent)
F /manager/assets/ext3/adapter/ext/ext-base.js:21
addListener /manager/assets/ext3/adapter/ext/ext-base.js:21
ExtJS 6
createDelegate /manager/assets/ext3/adapter/ext/ext-base.js:21
(Async: setTimeout handler)
defer /manager/assets/ext3/adapter/ext/ext-base.js:21
ExtJS 2
submit /manager/assets/modext/widgets/core/modx.panel.js:92
handleClick /manager/assets/modext/core/modx.component.js:291
ExtJS 2
(Async: EventListener.handleEvent)
F /manager/assets/ext3/adapter/ext/ext-base.js:21
addListener /manager/assets/ext3/adapter/ext/ext-base.js:21
ExtJS 14
S /manager/assets/ext3/adapter/ext/ext-base.js:21
S /manager/assets/ext3/adapter/ext/ext-base.js:21
Toolbar ExtJS
ActionButtons /manager/assets/modext/core/modx.component.js:124
create ExtJS
load /manager/assets/modext/core/modx.js?v=f8cf0b93:86
_loadActionButtons /manager/assets/modext/core/modx.component.js:41
Component /manager/assets/modext/core/modx.component.js:11
UpdateResource /manager/assets/modext/sections/resource/update.js:33
create ExtJS
load /manager/assets/modext/core/modx.js?v=f8cf0b93:86
/manager/?a=resource/update&id=2002:207
ExtJS 10
The new user group has exactly the same ACL access policy permissions as the Editor group, which works fine.
Most likely there is a plugin that runs on the event OnDocFormSave that throws an error. (The AJAX request doesn’t seem to return the expected JSON.)
Try to find out what plugin causes the error. There may be an error message in the PHP error log.
I tried disabling all plugins using the load OnDocFormSave, then clearing browser cache and logging out and in, and none of those made any difference.
Open the developer tools in the browser and go to the “Network” tab.
Then save a resource in the MODX manager. A new request should get added to the list in the “Network” tab (parameter “action” = “Resource/Update”). What is the response of this request.
“No reponse data available for this request”
And what’s the HTTP response status code? 500?
My best guess is still that a fatal error occurs in one of the plugins.
Is there maybe a plugin attached to OnBeforeDocFormSave or OnResourceCacheUpdate?
Also, try the CacheClear extra to make sure the cache is fully emptied.
Yes, 500, right after this:
POST: … /connectors/index.php
I don’t get it, because the group uses exactly the same permissions as the group that works, including the same access policy. The only difference is the resource group that can be accessed.
I manually deleted all files in the cache folder. No change.
Try to locate the PHP error file on the server.
With the specific error message and a stack trace it will be possible to identify the cause of the error.
I looked for PHP errors and couldn’t find any.
It’s a long shot, but the endless save can be a sign of mod_security not liking something in a resource field. That would explain the fact that the setup works for one group but not another. The diagnostic would for the problem group member to save an empty resource with an innocuous title.
Another long shot is an anti-bot or anti-spam rule in .htaccess that’s being triggered by part of the URL.
My next-to-last resort with debugging mystery MODX problems is to insert this line into the relevant MODX core code and move it around until it stops executing.
$modx->log(modX::LOG_LEVEL_ERROR. 'Made it to here: __FILE__ : __LINE__`);
My absolute last resort is to start Xdebug and launch index.php. Then step through the MODX code line by line, alternating between the MODX Manager, and the debug console until it breaks. It’s torture, but it can work. I do it inside PhpStorm. I goes a lot better if you can put a break point ahead of, but near, the problem code (e.g., the top of the modResource save() method). When Xdebug hits a break point, it throws you back to the debug console.
ModSecurity is turned off for this site.
People in the new group get the same endless saving message when creating a new resource with little text and a normal title. Also, the resource in the new resource group is also accessible by the admin group, who can save this page without issue.
So it’s not either of those. This is pretty baffling. The only similar things I’ve seen have been due a permission issue with a TV attached to the resource’s template, when the user doesn’t have permission to update, edit, or save the TV even though they have full permission for the resource.