Need Ability to have Contextual Admins for Users

Hey all,

I've been using MODx since pre 1.0 EVO, so I'm not new to the system, but I'm new to the forums. Anyways, I apologize if this has been covered, but I didn't see anything directly addressing it. I've got a question about users and contexts. I'm highly interested in using the multi-site concepts used in Revo by various folks, but I'd like to take it a step further and control the users based on contexts as well. Essentially I'd like to have various sub-admins who have specific ability to only edit or create users within a certain context, thereby making them the site-admin for the portion of their context including resources and users. What would be the best way to go about this?

For starters, there's no easy way to control which users an admin user can have access to or create. They either have the right to perform an action on users or not, and it applies to all users.

It might be possible to create a plugin to check a custom permission against the Context access credentials of an about-to-be-edited user (possibly in OnUserFormPrerender) and forward the admin somewhere else if they didn't have the permission, but it wouldn't be easy.

Worse yet, since Users don't have a Context setting, that couldn't stop them from creating users, so you'd have to have code that acted when they tried to save a Context Access ACL entry giving users access to a particular context. If you tried to give users a Context setting (say, as an extended field in the User Profile), they could change it themselves.

That would probably mean extending the modUser object and adding a context_access field that only certain admins could edit.

Good luck.

Thanks I was afraid that this might be the case. That said... I've done a bit more research in the files and I've noticed the "OnHandleRequest" event. From what I can tell this would be the scenario in which I could write a custom plugin that would catch request for listing user data then adding "usergroup" to the post data to limit the users in the list to only one group. Also, I could catch the request for the group list as well and limit that to only list the groups that Admin would be in.

This would work... however the "modConnectorRequest" which extends "modManagerRequest" overrides the default handleRequest function and unfortunately does not invoke the request event that it's parent does. This seems like it would have been something to keep in the code for cases like this.

Anyone have any other thoughts on doing this without extending modUser or modConnectorRequest classes? Unless of course this is the best way to go, though I'm still not clear on that.

I haven't looked, but IIRC, the connector parent class has a permission check, so you might be able to add a set of custom permissions.

I've done some more testing and from what I can tell there is no event triggered when a connector is used. This doesn't seem right. I'd think there would at least be a couple normal events that trigger when a connector is used such as an init. Am I doing something wrong here? Is anyone familiar with the behavior of connectors and whether events are triggered when using them?

Thanks!

Sorry I've answered my own question. I found this in the documents.

"Connectors are locked down to receive requests only from authorized sources, to prevent internal hacking."
http://rtfm.modx.com/display/revolution20/MODx+Revolution+Framework+Structure+Ideology

I'm not 100% on why this is, but I'm going to assume it is to force people to extend classes rather than hacking with Plugins. Though honestly it seems this is exactly what Plugins are good for. Just my thoughts though. Looks like I'm on to working on a new modx user manager page and a custom modx extension of modUser.

Quote from: joncox at May 30, 2013, 12:03 AM

I've done some more testing and from what I can tell there is no event triggered when a connector is used. This doesn't seem right. I'd think there would at least be a couple normal events that trigger when a connector is used such as an init. Am I doing something wrong here? Is anyone familiar with the behavior of connectors and whether events are triggered when using them?

Thanks!

I wouldn't think you'd need to extend modUser unless you have extra data to store in the user object. If not, you might be able to do it by just calling $user->isMember('SomeUserGroup').

BTW, the upcoming version of MyComponent will install a fully functional CMP as part of the Example project that you might find useful. I hope to release it soon.

Right, I was hoping to avoid extending the modUser class as I didn't need to add any data really. I'm building a multi-site based on contexts, so the users would be members of specific user groups to access the resources for specific contexts. The only part that is really frustrating is that the ajax connectors aren't triggering any events. Anyways, I'm still not sure on the best practice on overriding these connectors. I'm thinking about just extending the connector and processor class for the user / group list. That way I can just add in the override code in there. Then I'll create a new user list CMP and connect it all in the menu. Just one event prior to processing and I could do what I needed the easy way.

I'm looking forward to seeing your new release. From what I read on your site MyComponent seems quite extensive.

It's typical in a CMP to create your own connector.php file. It can fire any events you want (including custom events you create yourself).

Here's the one from the Example CMP for MyComponent:




If necessary, you can also extend the MODX Request class and call your own request handler's handleRequest() method in the code at the end. In your request handler, you could fire the appropriate event(s) then call parent::handleRequest().

BobRay,

I know this isn't ideal, but I ended up shortcutting for now and added the request event call to the connector request class. From there I was able to restrict what data can be viewed via connector requests in a plugin. It was one line and it at least keeps me moving along with developing the rest of this system, though I know it is something I will have to address for upgrade concerns. Worst case I keep adding that one line.