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.

  • @Satheesh - Definitely don't be afraid to express your opinion! I know that many sites are interested in roles, but I was explaining why Elgg never implemented them in core. It went against the original developer's philosophy of the project. 

  • Oopss - I should have also qualified -- that the *subsequent and immense popularity of Elgg (post version.1.0 rewrite) in a few very very short years - has created the 'demand' for roles/perms a la all other 'standard' platforms by all sectors of 'Users'.

    @blue corner = Elgg's design beginnings

    @red corner = prevalent philosophy and *user requirements

    & @confluence ? workable extensions..;-o;)

    Basicallly --- *in my opinion* - anything can be done / Elgg extended wth some appropriate foresight and a little 'pre' thinking. I would personally not be adamant for any post-design 'features' to be 'in the core' - that is my basic position w.r.t Elgg's design. If a functionality can be easily implemented via the norm - PlugIns [ as in the usual OOP extensibilty / overloading / etc ] - then Elgg Life goes on regardless and everyone *will be happy ;-oO.

    I reckon that it *is the 'limitations of Elgg - BUT 'flexible enough to encompass and integrate an assimilate' that makes Elgg what what it is.. Y'all Remember 'vger' the cloud of intelligence from StarTrek ? That = Elgg + PlugIns + Extentions.

    "In the Core or not in the Core.." should not be quite the question ;-) but rather - " can Elgg allow me to get it do the new & unique tricks that I want it to do " ? If the answer is (& should be) "yes" - both sides are winners ! And so far... We all should feel as 'winners' ;-P

     

  • @Matt the idea of the current Roles implementation is that there should be the least possible amount of explicit roles and permission check in 3rd party code. What you suggest would mean that all plugins should be developed with implicit role checks for certain actions/pages/views/etc. Unless a well designed and implemented, generic roles framework makes it's way into the core, I don't see that happeningn. It's highly unlikely that authors would voluntarily add a dependency on roles to their plugin.

    The current approach admittedly is a bit complex, but provides an unobtrusive way to post-apply permissions to existing plugins, without the need of changing a single line of code in those plugins. Well, that is true for some cases at least.

  • @Andras I think you're right: Elgg's plugin_hook system is already rich enough to define pretty precise permissions without having to make their checks explicit throughout plugin code; there probably doesn't need to be a new API with something like has_capability() (but I can imagine plugin authors feeling encouraged to add more hook triggers to individual operations so that some other system can implement the checking).

    The way you've applied permissions is what I've yet to dig into, and I'd really like to understand it before I comment much further. Could you elaborate more on the difficulties of allowing multiple roles? Is debugging the major factor or are there bigger design decisions that would need to be made?

  • @Steve Allowing multiple roles per users just adds complexity on every level to the whole idea. It's far from impossible, and if the need is there, we're willing to add it. But until there are clear use cases that  require multiple roles, I don't see the point of making our lives even more complicated. With the current implemetation of roles, I just don't see the added benefit.

    Having said that, I think we're almost on the same track of thoughts. Quoting one of your earlier comments: "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." So you say we need context dependent roles, I say we could live with context dependent permissions within a role - this is not that big a difference.

    The real challenge here is to define a meaning ful set of contexts that can be used for conditional assignment of capabilities (or roles, in your multiple-roles-per-user world :). Your example - "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." - is a good and sufficiently complex one. Here "invite" and "approve" are the capabilities, roles could be Inviter (with invite capability) and Approver (with invite and approve capabilities), and the context is the group itself.

    The current approach can handle the above capabilities and the roles, but not such a dynamic context. Currently you can only define contexts for certain type of permissions, and context is meant as the default Elgg context (blog, bookmarks, etc). We need much more flexible context definition to be able to set up roles like your example above. I'm very open to any suggestion on how to approach this. Once we have identified what kind of contexts we need, it'll be a much smaller issue if roles or permissions should be tied to contexts.

     

  • @Andras Yeah, whether we call them roles or permissions, they both just imply capabilities. I generally think of site/groups as contexts, but I certainly could be persuaded to consider a particular tool to be a part of that. If a context were: [container_guid, string_context], then examples might be [$site->guid, "*"], [$group->guid, "bookmarks"], etc. Though its sounds to me like the elgg context isn't really meant to be configurable: it's part of what defines the role.

    Re: multiple roles, with only 2 plugins released I could already imagine admins wanting to make a single user both a Group Admin and a Moderator. Arck's Roles plugin really opens a new market for plugins and I think we'll both be surprised at how much pent up demand there is for granular permissions. I'm sorry I haven't had time yet to digest the plugin. When I do I hope to be able to offer more constructive feedback.

  • Roles/Permissions have had some lengthy discussions here@elgg since abt 2 years back with nothiing else substantive published until Andras' Roles PlugIn series. Kinda way-to-go because - considering Elgg's inherent 'open-field' nature - roles/perms have been quite difficult to implement!

    Re: granularity of permissions vs 'roles' - coming from the world of RACF/ACF where such security consideratiomsnare taken for granted - - permissions are permissions and roles are roles! the 'granularity' can exist at the level of permissions - not roles. roles == users -> therefore 'roles' should be segregated from permissions and only mapped to permissions as and when needed.

    We just need to look at linux's perms vector for owner|group|world to see simple imlementations  for security and perms. and the same applies to ibm's racf/acf.  both technologies work exceptiioally well and who's complaining? of course if i complain - i should put put a better product or shut up.

    i hope Andras' Roles/Perms matures to a stage of maturity to become more uniquitous and satisfy the (pent) demands by elgg website owners.

     

  • Question: Are you all - Andras, Arck, et al - targettiing a partocular level of the RBAC scale -- Flat, Hierarchical, RBAC or Symmetrical ? And that given tagetted level, how did Elgg's Core -- facilities  / lack-of -- help or hinder the implementation ?

     

  • @Dhrup I was digging around at the community site before we started on the actual implementation. I found topics going back 3 years where lengthy discussions took place about the necessity of granular access and roles in Elgg. There even was a development effort, but real products never surfaced.

    For your question, I'm not really familiar with RBAC scale - I'd need to educate myself a bit on the subject before making a statement on this. But I think the implementation satisfies most aspects of the RBAC model. And this is definitely true in our case: "he 'granularity' can exist at the level of permissions - not roles. roles == users -> therefore 'roles' should be segregated from permissions and only mapped to permissions as and when needed."