I have created a custom group for a client that allows them to control most things on their site, but not blocks, prefs, module installs etc.

I need to give them access to the 'edit user' admin controls so they can set up users manually and move them into specific groups... but I don't want them to be able to put themselves, or any new members into the 'webmaster' group.

Anyway I can hack this?

-- Edit --

Actually, I just realised I will need to give them access to 'groups' too, otherwise they cannot allocate users to groups in the 'edit user' screen.

So... I also need to remove 'system admin rights' from the 'groups' screen for all but webmasters.

Gonna try hacking system templates, but if anyone has already locked down their admin in a similar way, any advice would be appreciated!

This is an issue I've had with a few sites I admin on ... at the moment there's no way to limit permissions down to more explicit things ... and it is something that could do with being enhanced for future core releases...

Something for a 2.4 wishlist perhaps?

Thx davidl2. If I can hack anything to good effect I'll report back.

Ideally, I need to have a 'superuser' that can control everything (and not be deleted or have their password changed) and then a 'webmaster' group for the site operator.

The site operator should be able to create users and put them into custom groups, but not install modules or fiddle with the prefs, blocks or templates (a.k.a. breaking the site!).

OK. Your mission (should you decide to accept it) is:

1) Allow a custom group, e.g. 'executives' to have access to 'edit user' in admin so they can:

* Add users manually
* Edit user details
* Put users into different groups

the tricky part will be, to...

2) Prevent the exec group from accessing the 'groups' control panel - or - allow them access BUT prevent them from creating new groups with any system admin rights.

3) Prevent the exec group from adding themselves, or any new users, to the webmaster group.

4) Prevent the exec group from changing the user details or password of users in the webmaster group. At present they can do this - which will effectively lock webmasters out!.

If this were possible, you (as webmaster) could retain control of those aspects of a XOOPS site that you are qualified to manage as a professional designer. You could give your client, or members of their staff, the ability to add a new sales manager to the 'sales' group without giving them access to things they are likely to break.

I'm going to have a go at this, but any assistance would be welcome. For any web designers offering XOOPS services, I'm confident a hack that achieved this would remove a lot of 'client-related' headaches.

This post will self-destruct in 10 seconds...

that's if a moderator doesn't get to it first!

Well, I made a start

In admin/users/users.php

Adding the following entry directly under:

function updateUser($uid, $uname, $name,....



1) Stops anyone editing the webmasters account.

2) Stops moving a new user into the webmaster group.

Unfortunately, this includes the webmaster, so I need another conditional statement that checks if the current user is in the webmaster group and if so, allow the update to take place.

I now removed the 'User name '.$uname.' is the webmaster' bit from the echo, so it just says 'You cannot edit or add members to the webmaster account.

Mission objectives 1), 3) and 4) complete!

Replace the above suggested code addition with:



This allows THE webmaster (UID = 1) only to edit webmaster group user details or add users to that group.

Will tackle the groups CP access issue tomorrow.

Wow thats a heck of an improvement already. Im going to need these features myself.

I already have sites built for clients. That it was very hard to give control over to. I do not have time for mistakes by other people just myself.


Great Work!


bookmarked

This could have some use in the demo site @ calibernation..

My only thought to all this is that the functionality would probably be better served if someone (I know, I know, who has the time?) created a module that did nothing but allow people to edit groups/users on the front side of the website. Creating this module would probably involve copying and modifying a lot of the code already on the admin side of the XOOPS core.

The advantage of this method would be that you wouldn't have to hack the XOOPS core at all. You could install/un-install this feature in a couple of minutes at will. Finally, it would be great if you could configure the new module quickly and easily so that you could specify *who* could access the module. Maybe even specify who could add/remove folks from groups on a group-by-group basis.

And in fact, I know the recent move was to pull out any default modules that came with Xoops. But I think modules like the old "members" module (and this one), would make sense to have back in the XOOPS core install package again. Specifically, those modules that simply extended admin features/functions to the front side of a XOOPS site could (should?) be included in the default XOOPS package, IMO.

It'd probably take some time and thought to get worked out right, but it'd really be pretty neat in the end...

Mission accomplished!

This is only for situations where you do not want clients creating groups and messing with the site. It is a hack (only two files changed) but you will need to re-apply for future upgrades of Xoops.

* Create a new group, e.g. 'executives'.
* Give the group system admin rights for 'Groups' and 'Edit Users'.
* Add the following hacks (backup first of course).

This will enable member(s) of the executives group to:

* Create new users and change their groups via the 'Edit Users' screen.

It will prevent the executives group from:

* Changing the webmaster details or password.
* Moving the webmaster into another group and removing them from webmaster group.
* Creating a new group with system admin rights.


Lock the Webmaster (UID 1) details

modules/system/admin/users/users.php

Part 1) Add as the first entry in 'function updateUser($uid, $uname, $name.....'



Part 2) Around line 232 look for:



Add directly below this:





Lock access to Groups except for the Webmaster

modules/system/admin/groups/groups.php

Add the following at the top of the page:



Please note: There is a bug in XOOPS 2.0.16 that prevents a NEW user from being added to a custom group when the user is first added in the 'Edit Users' screen. Once the user has been created, you must 'edit' the user details, select the appropriate groups, then save again.

Apparently, this issue is being addressed.

I agree this functionality would be better served via a module or system prefs. In the meantime I hope this is helpful. If you spot any errors or have any improvements, please post them here.