Roles / Administrators

One thing that is essencial as a core feature, is to have the ability to limit/control user permissions. I wonder why it has not been considered something important so far.

For example, in Joomla, users can be visitors, publishers, editors, administrators, super administrators.

In Elgg there is only, logged in, not logged in, and administrator. And for users like me, that use walledgarden, its only logged in and administrator.

As sites grow, users would want to add more administrators that could not delete users for example.

Uddhava dasa

  • Hello David,

    This is where Elgg can make the difference. In my experience, if we compare both worlds, we can see the problems with each:

    CMS - Joomla -

    • Good for few people publishing content/articles
    • Good for asigning editors/publishers
    • Bad for social awareness, users are isolated, and have very low interaction

    Popular Social Apps - Facebook -

    • Great for meeting people and interacting with other users
    • Great for letting users express themselves
    • Bad in handling static content or editorial content

    What has happened with Facebook, is that it very easily gets lost in the wilderness of user inputs, and since most users are not very expert in editing, or formatting, or anything at all, sites like Facebook are perfect for wasting time.

    Now Elgg, has the best of both worlds:

    • Good for few people publishing content/articles through the Pages plugin for example
    • Good for discussions/forums
    • Great for meeting people and interacting with other users
    • Great for letting users express themselves
    • Bad for user control

    So, the only thing missing, is that Elgg has a little bit of user permissions control. I understand that you feel displeased towards the concept of micromanaging what users can do, like drupal does.

    So, this takes us to a higher discussion, and the very basis of social structures. In the Vedic culture, this is explained very nicely, as social classes, or divisions. There are naturally 4 social orders in every society, and of course, in any social networking environment.

    • Highly Intelligent or Brahminical class
    • Administrators or governmental rules setting class
    • Self interested or Business makers
    • Low intelligence and/or uneducated

    For example, in the case of this site, Cash/Dave are the Highly intelligent, making the best high quality contributions. Then persons who handle groups, and discussions, general rules, form part of the governmental class. Then people hanging around Elgg programming for a living Dhrup/Vazco self interested/business oriented, and then the end users with their very basic install problems, and who rarely contribute useful content.

    With this concept in mind, it easier to see that Elgg has a huge blind spot, since it considers that everyone should be treated the same. We know by experience, that a post by Cash, is worth 10 times more than a post by johndoe. And we know that if you give administrator access to Cash, there is no problem, while if you give it to John Doe, even if you trust him, it will be full of mistakes, so you would want to limit his range of action.

    In terms of percentage, about 1% of users are in the Highly intelligent, 5% admin, 15% business, and 80% low intelligence.

    Please comment.

    Uddhava dasa

  • Some basic level of user / group roles are necessary to support basic web business models. For example, the "freemium" biz model is based on a free level with teasers to upgrade to a paid premium level. In many cases, such sites have multiple premium levels at varying subscription costs. There needs to be a native way within Elgg core to identify and manage such roles in order for someone to create a plug-in for billing, security, etc. I see this as a critical feature for Elgg to add.

    Going beyond that, I'm not sure that full-out Drupal style user security is worth the development costs and complexity it would entail.


  • We've had discussions about this before and just can't come to a good way to do it.  Anyone who has had the misfortune of having to work with moodle's roles, context, and permissions knows the dangers of too granular control.  I would hate putting Elgg admins through the same thing.

    We're all agreed that we need something more than what we have in roles / access.  The key is implementing it efficiently so that it can be managed efficiently in both code and UI.

  • I use and usually replace existing is_admin checks with this. currently static roles is enough to me and it's less db hit. I may consider including them in an include file. Also user_roles and individual user_rights (not in this code) can be stored in user metadata instead.

    in my 'lib' file :

        function chk_user_perm($perm) {
            static $userrights;
            if (!isset($userrights)) {
                // get userrights, currently static, but can be extended with a system to store / get from the db
                // we don't store individual user rights to gain a bit performance, also no DENY permissions yet.
                $username = get_loggedin_user()->username;
                $roles = array();
                $perm_roles = array(
                    'default'=>array() // default permissions

                // roles for users, can also be stored as a metadata in users
                $permrole_users = array(
                $userrights = array();
                $roles = $permrole_users[$username];

                foreach($roles as $role) {
                    if (array_key_exists($role,$perm_roles))
                        $userrights = array_merge($userrights,$perm_roles[$role]);
                $userrights = array_merge($userrights,$perm_roles['default']);
                $userrights = array_unique($userrights);
            if (array_key_exists($perm,$userrights)) return true;
            if (array_key_exists("sys:full",$userrights)) return true; //special key, giving full access on everything
            return false;

  • Hey Duck.

    From that code, it dn't look like you need 'DENY permissions' anyway since you're calling the roles and perm_roles in array.


    I like it.

  • to check a permission I just use chk_user_perm('part:perm'), if user is a member of a role, which has 'sys:full', then he/she will have all permissions.

    each plugin can have a static, configurable namespace (part) in a constant, editable by the administrator, in order to prevent namespace collisions with other plugins. then it can check it's permissions like chk_user_perm($myplugin_ns . ':deleteitem'), or the concatenation can be done in the function.


  • thanks carlos. usually it's not needed. just in some extreme cases it can be easier, but as you say...


  • What is the typical thing a moderator can do, on, let's say, a forum? A moderator can delete (or hide) posts that are not in compliance with the Terms and Conditions. A moderator can ban abusive users. A moderator can move a post from one thread to another. I think when most people are thinking about this subject, they are thinking in those terms, although we all understand it is a far more reaching topic.

    So, with that in mind, if an Elgg site had 10,000 members and the site admin dubbed 50 of them as trustworthy moderators, it would be a huge benefit to the site admin. It's a simple principle of having more eyes and ears checking on things and being able to correct problems as they see them.

    If all Elgg added was this simple moderator, it would be HUGE. And then other functionalities or roles could be added.

    On this subject, I had suggested Translators, for the translation module. It would be good to have a distinct role for Translators, where they would be able to do the translations, save the work, but could not apply it to the site or export any of the content or files. This would also be HUGE for Elgg.

  • Well, I've cleaned it a bit as it's not only seen by me now =)

    I temporarily use 'site:admin' permissions on my test server to replace old isadminloggedin function in some temporary hub functions, to prevent a lot of changes for now.. whatever..


     * Check if the current logged in user has the given right
     * @param string $namespace The namespace of the right, eg. a module shortname, 'sys', 'misc'..
     * @param string $token The permission token, eg. 'run','delete','ban'..
     * this can be extended to store roles in an entity, and user rights & roles in metadata,
     * but unless a dynamic assignment is needed, this way prevents extra db hits and is kinda more secure.
    function chk_user_perm($namespace,$token) {
    	static $userrights;
    	$perm = $namespace . ':' . $token;
    	if (!isset($userrights)) {
    		// get userrights
    		$username = get_loggedin_user()->username;
    		$current_roles = array();
    		// defined roles and assigned permissions
    		$conf_roles = array(
    			'default'=>array() // default permissions, applies to everyone
    		// defined individual user rights
    		$conf_user_rights = array(
    		// defined users and their roles, can also be stored as a metadata in users
    		$conf_user_roles = array(
    		$current_roles = $conf_user_roles[$username];
    		$userrights = array();
    		foreach($current_roles as $role) {
    			if (array_key_exists($role,$conf_roles))
    				$userrights = array_merge($userrights,$conf_roles[$role]);
    		if (array_key_exists($username,$conf_user_rights))
    			$userrights = array_merge($userrights,$conf_user_rights[$username]);
    		$userrights = array_merge($userrights,$conf_roles['default']);
    		$userrights = array_unique($userrights);
    	if (array_key_exists($perm,$userrights)) return true;
    	if (array_key_exists($namespace . ':*',$userrights)) return true; // all permissions under the given namespace
    	if (array_key_exists("*:*",$userrights)) return true; //special key, giving full access to everything
    	return false;
  • Going back to the original topic, Elgg out of the box is quite elegant and simple.  Over complicating it may not be the answer.  I do agree that it will help add some additional granularity but perhaps using some existing model.  For example, a user can create a "Friends Collection" and assign permission using that collection.  I think if there is such thing as a "site-wide collection" that an admin can set up, perhaps by simply belonging to a group so that others group or content owners can assign access permission to that group or collection. My half a cent worth...

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.