Bob's Blog

One of the few weak points of the current version of MODX is that you can't use security permissions to limit which users an authorized user can modify or delete. If a user has the access_permissions permission, they can perform all user operations on any user. They can change the status and even the password of any user, including the admin super user.

Thanks to a brilliant plugin from Bruno Perner (Bruno17), however, there is a way to at least limit the users they can modify to members of their own primary user group.

The Concept

When viewing the user grid in the Manager, there's a drop-down that lets you select the user group to be shown. When you make this selection, only members of the selected user group will be shown in the grid. This is accomplished by setting the $_POST['usergroup'] variable. When the security/user/getList processor sees that the $_POST['usergroup'] variable is set, it limits the users drawn from the database to members of the user group specified in the variable.

This plugin of Bruno's, attached to the OnMODXInit System Event, steps in and modifies the $_POST['usergroup'] variable, replacing its value with the ID of the current user's primary group. All you need to do is create a plugin (let's call it "LimitUserList") with the following code, and attach it to the OnMODXInit System Event.

The Plugin Code

/* LimitUserList Plugin */

/* Only execute in the Manager */
if ($modx->context->get('key') === "mgr") {
    $action = $modx->getOption('action', $_REQUEST, '');

    /* Only execute if the 'action' is to
        call the user getlist processor */

    if ($action == 'security/user/getList') {
        /* Get the ID of the current user's primary user group */
        $group = $modx->user->getPrimaryGroup();

        /* Set the $_POST variable to that user group */
        $_POST['usergroup'] = $group->get('id');
    }
}
return;

Even if a savvy user were to modify the $_POST variable, the plugin would still step in and change it before the variable gets to the security/user/getlist processor.

One drawback of this method is that you often add admin users to user groups so that they'll have access to resources protected by connecting a resource group to the user group with a Resource Group Access ACL entry. Having the admin in the user's primary group would allow any user with that group as their primary group to modify the admin's permissions and password. The solution is to create a separate group for the administrator, create a similar ACL entry for that group, then remove the admin from the user's primary group.

Coming Up

In the next article, we'll look at the modTemplateVarResource object and how to use it.

---

For more information on how to use MODX to create a web site, see my web site Bob's Guides, or better yet, buy my book: MODX: The Official Guide.

Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at Hosting.com (formerly A2 Hosting). (More information in the box below.)