User roles in Elgg

Folks,

we've uploaded a plugin that attempts to build a "user roles" framework for Elgg, see here.

There are also two extension plugins that implement frequently requested, role-based features, the Moderator and the Group Administrator roles.

All plugin specific feedback is welcome on the relevant plugin's page. We've fired up this discussion to collaborate on the long term, high level goals for user roles in Elgg.

We'd like to hear

  • Elgg core developers; on what they think about this approach. I.e should user roles be implemented via plugins, or eventually be merged into the core? Is there any plan for the latter?
  • Elgg contributors; on what generic, high level requirements a roles API should satisfy? Having multiple roles per user was already raised by Steve Clay.
  • Elgg users/administrators; on what they're lacking currently regarding user roles in Elgg. What would be the most needed user roles to implement in Elgg?

Fine grained user roles have been missing from Elgg for a long time. Though it is a complex topic, it should be addressed, as most of the competing frameworks offer something for more granular access than "admin" and "user". Please contribute with your thoughts so this development effort goes into the right direction.

  • Steve Clay said:

    First off, this looks well thought out and implemented, and will most certainly support some nice plugins (like the two you posted with it).

    I'm curious what led to the decision of limiting users to having only one role? IMO a user should be able to wear multiple hats, and in different contexts (like site-level or in a particular group). I think it would be wise to build on top of an API that supports that even if a lot of it is roped off for future implementation. Perhaps this discussion should be elsewhere.

  • Matt Beckett said:

    Well, I've just read through the docs.  Seems very well thought out, I can see this being the base of many more plugins.  If the framework is done even half as well as the docs I think we should be in good shape.

    The only suggestion I can think of at the moment is echoing Steve's sentiment about multiple roles.  I need to look a little closer at the implementation of the rules but I'm wondering if the rules could be assigned a weight/priority value similar to how the core handles hooks.  Users could then have multiple roles, and anytime there are mutually exclusive rules the one with the higher priority would take effect.

    It could get pretty complex, but I think it's something to consider.  I'm excited about this anyway.  Many thanks for taking the initiative on this.

  • Users having multiple roles adds a very heavy additional complexity to an already complex idea. It might be a nice feature, but guaranteed to cause nightmare debugging sessions for developers of roles.

    Also, when would different rule sets kick in? Steve suggests context based roles - well for some permission types, you can already have context based permissions (mostly menus). I think most of what you mean by "multiple roles" is already in the bag: you can extend - even multiple - roles, thus you have a permission sharing and overriding mechanism in place.

    We're open to discuss multiple roles per users - but given the additional complexity, it would be nice to hear specific use-cases where multiple roles is the only solution. Maybe, what you're trying to achieve, is already possible with the current approach.

    For Matt's request on weights/priorities on rules, this is again in place - at least where it made sense for this initial implementation. First, you have a standard hook for adding new roles or overriding already defined ones - here you already have priority. Within the rule sets, you also have priorities for role based menus, hooks and event handlers. So again, I'm asking you, let's approach this from specific features - what are you trying to achieve, and what obstacles the current implementation presents?

  • When this API starts to get usage we're going to see new ability-providing plugins and that getting the right combination of abilities for some users will require multiple roles. In a system without native roles it's hard to imagine use cases but I guarantee people will have them :)

    Where Elgg is used with online learning, instructors want to have groups dedicated to each section of a class and with that the ability to give their assistants the ability to moderate group content in different ways. While there are existing plugins that essentially extend $group->canEdit() to select users, this functionality belongs in, and would be considerably more flexible in, a dedicated roles system.I'm a group owner I want users A, B, and C to be able to invite new members, but only A can approve them.

    Code-wise Moodle's contextual roles system is messy, but when crossed with Drupal's it can be simple: You have contexts, capabilities, and roles; roles imply capabilities; users get roles within a context; and before you let something happen, you query to check if the user has the capability in this context.

  • I'm not entirely sure a contextual role system for Elgg with fit its data model well, but I'm not all that concerned. I think the core team is open to expanding the schema when the need is apparent and the alternative would be heavy shoehorning.

  • @Steve, I've been discussing this with Andras, as it was part of the challenge I've had in implementing roles into the current project (revolving around groups). This in theory should be possible through extended roles. 

    This is already in place for 'pages' - {$pageowner_*}. The problem is integrating this into other permissions, mainly views. I couldn't really think of a solution, so if you have any thoughts, please share.

  • I think the complexity comes with the extended framework you've created.  You have a system in place to create/extend/replace views/actions/events/redirects - which is indeed very cool, but this can also be done using the same Elgg framework we're all used to.  Consider if the roles framework was simplified to an allow/deny system - instead of registering an action for a specific role by declaring a new role, the developer can use the same logic they're used to:

    if(role_has_access($user, 'action:blog/save')){

      elgg_register_action(...);

    }

     

     or

     

    if(role_has_access($user, 'action:user/roles')){

      register the action

      extend the view for the role switcher

    }

     

    This would make for equally granular access, and multiple roles could be handled by simply checking if *any* of the roles the user has returns true.

  • Everyone - Thanks for the contributions in this...some very valuable stuff!

    Elgg was purposely designed without roles. The lack of roles wasn't an oversight but a design decision, and this is reflected in the data model, controllers, and throughout the entire system. Back in the day, the idea was to encourage full-site organic discussion and networking on a level playing field--all users were the same.

    Elgg's entire development team has changed since then. This team hasn't had a recent discussion about integrating roles into core. My current personal opinion is that we should make core flexible enough to support roles but not include in core. The other core devs might have different opinions, however...

  • I dont know whether I should comment on the words of Brett...

    In my openion  there should be a role system in ELGG site, where admin can make moderators who can control the posting of the members (delete/edit..) who can delete/ban members who makes vulgur /spam posts..

    thanks to Arck Interactive for role plugin

  • Disagree !!

    " ...wasn't an oversight but a design decision.. "
    " ..core flexible enough to support roles but.. "
    " full-site organic discussion and networking on a level playing field "

    We must not let our current oir new feature requirements cloud the design approach. One needs to look at history of Elgg - where is came from and the basic principles of the design to appreciate the apparent lack of functionality - which can be extrapolated easily anyway via the PlugIns facility.

    So far - since mid-2008. I have yet to see any aspect of the Elgg design and structure.. which has not allowed or facilitated fairly easy extentension of feature power. That was the basis of choice to go for and stay with Elgg then and dump all (<=30 CMSs) other platforms for good in favour of Elgg.

    Elgg has the easiest of all the platforms to work with even at the lowest denominator ;-)