How do I detect Manager User in a Plugin?

I want to write a plugin that hides certain resources/branches in the tree based on individual user settings. Looking at the Event Parameters for the OnManagerPage[Before|After]Render events, it is unclear to me how to even access the user ID. How would I do this?

Also, once I can get the user and get their settings (and presumably find a JSON list of resources to hide in the tree), my plan was to use regClientStartupScript or regClientStartupHTMLBlock to include some extJS or other javascript that would hide the specified resources. Is this going to work in a manager plugin? Or is there some other method I should try?

In a plugin, you have the $user variable available, which is the user ID. Or you can simply ask MODx for everything on the current user

Why can't you just use resource groups for this? Assign all the resources you don't want the limited users to see to a resource group that's connected to the Admin user group.

Quote from: sottwell at Aug 05, 2013, 10:53 AM

In a plugin, you have the $user variable available, which is the user ID. Or you can simply ask MODx for everything on the current user

$user = $modx->getObjectGraph('modUser', array('Profile' => array()));

Why can't you just use resource groups for this? Assign all the resources you don't want the limited users to see to a resource group that's connected to the Admin user group.

A good question. I do make use of resource groups to restrict various sub-sites to their respective user groups. I'm actually writing this plugin FOR the admin group. I of course want the admin group to be able to access ALL of the resources in my MODX installation. But 1) our tree is getting cluttered up with dozens of root-level resources, 2) the behavior of the tree seems to grow ever-quirkier, with random branches expanded even though you haven't had them open recently, weird sort-order changes, etc.

My thought was to write a plugin for admin users that lets them specify a list of root-level resources that they DON'T wish to see. They can block all but the small handful of sites that they might be actually working on during a given week. Then they'd still have *access* to the rest of the sites, but they wouldn't have their tree view constantly being cluttered-up by them.

Maybe this would just make the existing tree issues even worse, I don't know. But I'm at the point where I feel I have to try something.

One solution for a cluttered Tree:

http://rtfm.modx.com/display/ADDON/MIGXdb.Manage+Child-Resources+in+a+grid-TV+with+help+of+MIGXdb

Thanks, I will definitely look in to that.

I'd still like to know how to query the user in a manager plugin though, even if I don't end up pursuing that plugin. Or have it explained to me why this is a fundamentally unsound concept for a plugin(if it is).

The getObjectGraph() function will return an array with all of the user's information from the "users" table and the "user_attributes" table. If you have BobRay's book, this is explained on page 321. This will work in a plugin as well as in a snippet.

Quote from: sottwell at Aug 05, 2013, 12:56 PM

The getObjectGraph() function will return an array with all of the user's information from the "users" table and the "user_attributes" table. If you have BobRay's book, this is explained on page 321. This will work in a plugin as well as in a snippet.

The thing I don't understand is how to get the ID of the active user to even use getObjectGraph in this way. In some plugin events, you have access to a $user object; in snippets for use on front-end pages, you can access the $modx->user object. But neither of those work with the events I'm trying to use this on. Maybe there's a different event I should be calling this on, but I want to make sure it only runs on Manager pages, not front-end pages.

getObjectGraph('modUser'...) will automatically go for the current user. In that sense, it's much like the $modx->user object, with the addition of the Profile object, taken from the user_attributes table.

This might do it:



FYI, trying to customize the Manager in code can be really unpleasant because almost everything is created on the fly in modExt and the part you want to modify is often not there when your code runs. [ed. note: BobRay last edited this post 13 years, 1 month ago.]

By "almost everything is created on the fly in modExt" we mean it's all done with AJAX from the browser. If you do a view source on the page in your browser, you'll see it doesn't have a lot in it. In fact, once you get past the main menu, all you'll see on a resource editing page is