Diagnosing MODX Revolution Permission Problems

MODX logoWhen I first thought of the snippet below, I thought it was a brilliant idea. On further reflection, I have to confess that it’s a lot less useful than I thought. I hope, though, that it’s still useful for helping people understand Revolution permissions. You may find it helpful in specific situations.

One issue with MODX Revolution permissions is knowing whether a user has a particular permission or not. Users can get permissions in various places and if they’re granted a particular permission somewhere, they may have it in places you wouldn’t expect them to.

This can be especially confusing in your permission system is complex. It can be very difficult to be sure whether a user has, or doesn’t have, a permission in a given situation. I’ve spent some time wondering why taking away a certain permission didn’t prevent the user from performing a certain action, only to find out after a lot of frustrating debugging, that I hadn’t actually taken away the permission in the first place.

In this article, we’ll look at a simple utility snippet that will tell you whether a user has a permission or not. If the user has the permission, the snippet will also report the type of policy that contains the permission.

Policy Types

Before we look at the snippet, we need to take a short detour to consider the two types of policies used in MODX Revolution: context and object policies. Remember that a policy is just a list of specific permissions. Each permission is either checked (granted) or unchecked (not granted) on the policy.

Permissions in context policies determine what the user can do and see in a particular context. If the user has save_document in the Manager (‘mgr’ context), they have it throughout the Manager. The master list of context policies is the default Administrator Policy installed during the initial setup of MODX Revolution.

Permissions on object policies determine what the user can do and see with a particular object such as a resource or element. More correctly, they determine what the user can do with a particular group of objects such as a resource group or category. The master list of object policies is the default Resource Policy installed during the initial setup of MODX Revolution.

The reason it’s important to understand this distinction is that MODX tests the permissions in two different ways. Context policy permissions are tested with $modx->hasPermission('permission_name'). Object policy permissions, such as add_children, however, are tested with $object->checkPolicy('permission_name'), where $object is the object the user might want to do something with. The object is most often a resource. For the current resource, you’ll often see code like this: $modx->resource->checkPolicy('some_permission').


Selecting a Method

As you’ve probably guessed, if we want to select a method to see whether a user has a specific permission, we can consult the policies. If the permission is listed on the Administrator Policy, you check with $modx->hasPermission(). If, on the other hand, it’s listed on the Resource Policy, you use something like $resource->checkPolicy().

Is There a Simpler Way

As a matter of fact, there is. You wouldn’t want to do this in production code because it’s inefficient, but in our utility snippet, there’s no harm in using both methods. If one or the other returns true, the user has the permission.

The Code

Put this tag on a page where you’d like to see the report:

[code language=”html”]
[[!CheckPermission? &permission=`permission_name`]]

Paste this code into a snippet called CheckPermission:

[code language=”php”]
/* CheckPermission Snippet */
$type = ”;
$perm = $modx->getOption(‘permission’, $scriptProperties, ”);
$hasPermission = false;
if ($modx->hasPermission(trim($perm))) {
$hasPermission = true;
$type .= ‘ (Context)’;

if (! $hasPermission) {
if ($modx->resource->checkPolicy($perm)) {
$hasPermission = true;
$type .= ‘ (Object)’;

$result = $hasPermission? ‘YES’ . $type : ‘NO’;

$output = ‘<p> Checking Current user for permission: ‘ . $perm . ‘ — ‘ . $result . ‘</p>’;
return $output;


You can put the snippet tag in the content of any page, then log in as the user you want to check the permission for and view the page. Remember to use a different browser where you’re not logged into the Manager when you view the page.

You can also put the snippet in a template and view multiple pages that use that template.

How it Works

First, we get the name of the permission to check for in line 2 and we set the value of $hasPermission to false. If either check is successful, $hasPermission is changed to true. If not, it remains false. Finally, we generate a statement listing the permission being checked and whether the user has it or not. If the user has the permission, we also append the type (Context or Object) to the message.

Notice that the snippet is called uncached (with the !). This is important because we don’t want the cached value of the snippet, which could be incorrect in the current situation.


Of course our snippet is no use at all if the the resource is hidden from the user or the user doesn’t have permission to view it, and it won’t do us any good in the Manager.

Our snippet also won’t work well in a plugin (where returned output usually doesn’t appear on the screen) and it won’t work with elements. Fortunately, most permission checking involves resources and a snippet works fine with them as long as the user can see them. If you need to check permissions in a plugin or during the execution of another snippet, you can try using echo to display the results. It may or may not work, and on a busy Manager page, it may take you a while to spot the output. Another way to go is to create a chunk called “Debug” an write the output to the chunk with this code, then use QuickUpdate to look at the chunk’s content:

[code language=”php”]
/* CheckPermission code above goes here */
$chunk = $modx->getObject(‘modChunk’, array(‘name’ => ‘Debug’));

Another limitation, though not a serious one, is that you can’t use the snippet to check permissions when running PHP code from the command line or in your code editor. In those cases, MODX bypasses the permission system entirely, so every user has every permission.

Wrapping Up

Once you know for sure whether a user has, or doesn’t have, a specific permission, you can spend your time trying to figure out why the user has the permission or not and what to do about it. After each change you make, you can recheck the user’s permission status to see if you’re making progress.

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 quality MODX Web Hosting? Look no further than Arvixe Web Hosting!

Tags: , , , | Posted under MODX, MODX | RSS 2.0

Author Spotlight

Bob Ray

Bob Ray is the author of MODX: The Official Guide and over 30 MODX add-on components. He hosts Bob's Guides, a source of valuable information for MODX users, and has been very active in the MODX Forums with over 19,000 posts.

Leave a Reply

Your email address will not be published. Required fields are marked *