How can a “group leader” administrate his group ?

[Hansueli]

Dear Joomla Team
I have 12 group of users and each them has a “group leader”.
This “group leader” should have admin rights for his group.
Meaning: He can add; edit and delete users in his group.
How can I install this?
Thank you
Hansueli

I am using 3.1.1 sorry ! wrong Forum

------------------------------------------------------
geniuses are lonely - sometimes I'm lonely - unfortunately increasingly rare

[rcarey]

As I understand your request, you are asking for a special set of user manager roles where each of these roles is restricted to managing just those users who belong to a particular group. Joomla does not provide this out-of-the-box, but it can be accomplished through overriding the layout file for the user manager. So the solution does require some coding.

Let me first explain the challenge and approach. Joomla’s ACL allows one either to be a user manager or not. And Joomla’s ACL allows us to assign actions such as create, delete, edit, edit state, etc. But (aside from preventing a non-super user from editing a super user) it does not provide for selecting which users one can edit. So what we need to do is grant these special user manager groups all the permissions that are needed, and we add extra code to restrict which users are editable by one of these user manager groups.

My suggested solution involves two steps: First, configure your ACL. Second, override the screen that lists the users that can be edited.

[1: ACL Configuration]
It sounds like you have the groups already in place. (You mentioned 12 of them.) Create another group and call it “Restricted User Manager.” (Or you could call it “Group Leader” if that has more meaning for you.) Make this new group inherit from public.

For each group leader, assign them to this new group as well as to whatever group or groups that contain the users that he/she is be able edit.

For this new “Restricted User Manager” group, go to System->Global Configuration->Permissions and Allow this new group Admin Login. Then go the UserManager->AccessLevels and add your new group to the Special access level. (This last setting allows this user group to see the admin menu.)

[2: Overriding the layout for the user manager screen]
Copy this file
/administrator/components/com_users/views/users/tmpl/default.php
And put it here…
/administrator/templates/<your admin template>/html/com_users/users/default.php
You probably will need to create the latter two directories, and it is this new file that you will be editing.

I have created a short PHP class for you to add to the bottom of this file. It performs the logic of determining if the current user manager should be allowed to edit any given user. So just copy this code to the bottom of this file that you are overriding.

Code: Select all

<?php
class ConstrainedUserMgr{
    protected $_isRestricted = false;
    protected $_canEditTheseGroups = array();

    function __construct($mgrGroup,array $allowedGroups){
        $mgr = JFactory::getUser();
        $mgrAuthorizedGroups = $mgr->getAuthorisedGroups();
        $this ->_isRestricted = in_array($mgrGroup,$mgrAuthorizedGroups);
        if($this->_isRestricted){
            $this->_canEditTheseGroups = array_intersect($allowedGroups,$mgrAuthorizedGroups);
        }
    }

    public function canEdit($userId){
        if(! $this->_isRestricted){
            return true;
        }
        $userObject = JFactory::getUser($userId);
        return count(array_intersect($userObject->getAuthorisedGroups(),$this->_canEditTheseGroups));
    }
}
?>

Next, add this line of code around line 22 (such as right after the line with $loggeduser)

Code: Select all

$userMgr = new ConstrainedUserMgr(13,array(11,12));

However, you will want to change the numbers in this function to correspond to the group ids in your system. The first number (here as 13) should be the id of the group “Restricted User Manager” (or whatever you called that group). The second set of numbers (here as 11,12) are the ids of each of your 12 groups, each having a group leader who can edit only members of that group.

The last piece of code should be placed around line 88 (immediately after the foreach line)

Code: Select all

if(!$userMgr->canEdit($item->id)){    continue;     }

This line calls the instance we created in line 22 and if it determines the user cannot edit this user, then the logic will not list this user and “continue” on to the next user.

That should work for you. This is code that I tested on 3.1, and I would expect it to work for 2.5.x.

additional details to be aware of

First, User Manager screen will attempt to paginate the list of users. So if the pagination is set to 20 and this new code is removing over 90% of the users, then the screen might show multiple pages with only 0 to 3 users listed per page. We can get around this quirk, but it will take more code than what I shared.

Second, by overriding this file, we successfully filtering users from the list of users. This prevents “honest” users from not reaching data they should not be editing. However, a clever user can manipulate the URL to reach the screen for editing a particular user – and set the id to users that he/she should not be editing. If this is a concern, you should be able to override that layout file and reuse the logic of the code I provided to block access to that edit screen if the user manager is not authorized to view that user.

Third, When one of your group leaders is editing a user, we have not applied any restriction to prevent this user manager from adding a user (including himself) to additional groups. This can be a security issue. Again, we can override that edit screen so that the restricted user manager does not have access to set the user group. Or we can override that edit screen to allow the restricted user manager to see only certain groups that can be checked or not checked. Again, this involves additional code.

Finally, my PHP class includes the logic for the set of rules as I understood them. If someone else needs to set up user managers that are to be restricted but according to different rules, then the logic within this class would probably need to change.

I just shared a lot of information. Give it a try, and if you run into some problems, let me know.

[Hansueli]

Thank you!
I will implement it and tell you my experiences.
Hansueli

[Hansueli]

Dear Randy
I have already some results.
I could select a group of users!
But I had to do the changes in:
“/administrator/components/com_users/views/users/tmpl/default.php”

When I copied it to:
“/administrator/templates/<your admin template>/html/com_user/users/default.php”
Or in my case:
“/administrator/templates/isis/html/com_user/users/default.php”
Then nothing happens.
So probably I misunderstand something?
Thank you
Hansueli

[rcarey]

Sorry, I had a typo in that line. The overriding path should be com_users (plural). I will change this in my original post in case someone later tries the solution for him/herself.

Just change the spelling of that directory within your template folder and (if needed) copy the changed file from the core folder to the overriding folder.

Aside from that issue, does it all work as you expected?

[Hansueli]

Hallo !
This was quick and NOT dirty!
It really works as expected.
Thank you very much.
I own you some beer if you visiting Switzerland!
I think I will also make a test, giving the group-leaders an own template and preventing the users to change backend template.
I also use the community builder http://www.joomlapolis.com perhaps I can even use it for this.
Thank you!
Hansueli

[Alex-was-here]

L.S.

Add the code to all admin templates you want to keep on stand-by.

Group leaders can still change the template they (and the members of their group) work on in the back-end, they can do this under Basic Options.

By the way, the solution works without a flaw, thank you Mr Carey !

*****

[rcarey]

If you have applied this soltution to a pre-3.2.2 version of Joomla, you will encounter a problem after upgrading to 3.2.2. Here is the reason and the quick fix...

Symptom: The User Manager screen will be blank (or an error will display).

Reason: The earlier version of the file you overrode made a reference to a class that is no longer accessible. The 3.2.2 version of User Manger replaces that reference with a new class, and that class is (rightfully) shifted out of this layout file and into the view.html.php file. As a result, your overriding file retains that reference to a class that cannot be found, resulting in a runtime error - hence a white screen.

Quick Fix: The quick solution is to edit line 17 (or abouts) to initialize the $canDo variable this way

Code: Select all

$canDo = $this->canDo;

In my tests, this was all that was needed.

Best Solution: Because the core version of this file changed, a better long-term solution would be to take a 3.2.2 copy of
/administrator/components/com_users/views/users/tmpl/default.php
apply the changes suggested above, and replace the current overriding file with this newer version.

If you want to use this solution and are starting with 3.2.2, you will not experience this upgrade issue.

The code that I posted still works as before. The problem is caused by a rare code change in this core tmpl file.

Thanks to Alex Zielhuis who alerted me to this 3.2.2 upgrade problem so I could post a solution here.

[Hansueli]

Thank you!!!