Member Login: fine-tune permissions within Security>Manage Users

I have successfully installed the Login component, etc to create a member login system on a test site that works great. At this time, the system can:

1. Login registered users
2. Register new members with all opt-in requests
3. Present certain pages only to registered users
4. Log users out
5. Present all pertinent pages to thank or prompt users through the process
Etc., etc.

Great, but now I noticed that if a site editor (my client) wants to administer the names of registered users, they're going to need access to the Security>Manage Users area.

That means that they're going to be able to change login information to all registered users, including the Super Admin. As you can imagine, that can not be allowed to happen.

At this time, I always disallow lower level editors from being able to even see the Security menu item, let alone the pages it houses. So, how do you go about allowing lower level admins (editors) to see and administer all registered users except for users above a certain level (especially the Super User)?

MODx v2.2.2 [ed. note: waizen last edited this post 14 years, 1 month ago.]

Anyone know of any components or something that allow lower-level users to see/administer certain site members but not give them access to upper-level members' permissions? I can't believe that the Security>Manage Users area would be the only place that can do this without basic ability to protect the Super Admin. At least, be able to block lower level editors from making changes to the Super Admin info/passwords, etc. This should be a basic capability, no?

Unless it's right in front of my face, I cannot see where to fine-tune permissions so that editors can see/administer permissions to only a certain group, but not others (super admin, for instance).

Please understand, I'm not talking about basic permissions regarding being able to see certain things, like saving, or seeing the menu item at all...I can and usually do that through the ACL, but actually be able to see or edit for some members but not others. At least keep editors' fingers away from changing anything regarding the Super Admin. It seems that the ACL permissions (the checkboxes) will either allow or not allow (for a certain group) to either see or not see a function completely. Does that make sense?

Man, I can't believe I can't find anything about this on the web. I can't be the only one out there who has wondered about this. Or, maybe I'm just phrasing all this incorrectly? [ed. note: waizen last edited this post 14 years, 1 month ago.]

Oh, crap. I found this post:

https://forums.modx.com/thread/29969/creating-users-with-limited-access


Is this correct? It cannot be done?

Well, I guess this answers my question. Seems like this would be crucial to most any member/editor/manager user administration scheme.

I need a limited editor, who has rights to add (edit/delete) members for a web context only resource and user group. These editor users should not be able to delete users with more permissions than them, manager users, nor especially, admin users (sudo even!). That's not ok.

In this case (volunteer editors, volunteer sudo admin, volunteer everyone), these editor users absolutely should have rights to add or edit/delete site members under their specific area. Otherwise they're gonna call me... and I don't wanna.

Shouldn't this be a feature request then if it simply can't be done right now?

Definitely, but I suspect it already is one -- in which case you could vote for it.

The problem is that there's are no user-group-specific permissions at this point.

It might be possible to do something with a plugin attached to OnUserFormPrerender, but it would be tricky, and all users would still appear in the grid.

The user getlist.php code does accept a property specifying the user group to show, but even if you could set that, I think the user could just remove the filter in the grid and see all the users again.


A built-in solution may not appear until MODX3.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Wow... this is not a small thing.


You mean, up to now, any site that employed a member login system has had to deal with this potentially disastrous flaw? We're, what, at Revo version 2.2.4 at the time of this writing, with the Login extra having been around since 2009 and this hasn't been addressed up to this point? I (and you, Bob and Frogabog) can't be the only ones in the world who have noticed this, right?

Seems highly improbable. But insofar as search results... not much speak of it 'round these parts.

Search terms are finicky though, maybe I'm just not searching properly.

It'd be great if we could tag posts and replies with categories so people can find them someday.

It can all be done in the front end if you make a form and use UpdateProfile portion of Login, more secure and the user won't need to access the manager at all.

I recently accomplished this a few weeks ago all I used was Login and FormIt you just need to think outside the box a bit and see how you can use both of these to accomplish what you want to achieve.

Care to elaborate? How would you show/search for users, and furthermore show results from only certain user group(s)?

Some of us are still stuck digesting the regular Login and FormIt boxes. Outside thinking is scary and confusing :~}

Frogabog sorry forgot to mention PeopleGroups extra in my previous post.

What I did was create a form using FormIt in conjunction with PeopleGroup that would let you select your the user you want to edit this would then take me to a page with the UpdateProfile form where it would get all of the information for the selected user. In this page you can edit all the user details and then save the changes.

So look into PeopleGroups extra and just explore how you can get these 3 extras working with each other and make sure to post if you get stuck.

I will make a tutorial in the future on CMSTricks but I have some other tutorials to finish before I get to this one.

Good luck.