NeXgeN Permissions & Roles:
Roles and Permissions for Elgg should not be so hardd;
and should not require a rocket science degree in coding PHP structures ;-)
In order to have truly granular control of accesses -
a R&P methodology designed around PHP data structues -
Therefore one needs coding to control approx 1000 resources (assets)
in the basic Elgg install with the bare-bones 'core' plugins !
And if you're a simple user, not a 'coder' -
you gonna have diddley's chance of
making such a system work for you ;-)
A careful study of the inherent structures that comprise Elgg's entities
and objects,owners, collections.. will be needed to design (and implement)
a workable R&P system for Elgg -
one that works for everyone -- without the need to code.
[ Yep..! if you've caught the drift via my 'neXgeN' posts..
I am working on a R&P system for Elgg that will truly blow
your minds away - by it's sheer simplicity & ease of use..
a direction that seems to been already catered for
by Elgg's original Design ]
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Roles & Permissions ?
What does the 'user' want ?
All Y'all that run elgg-based sites without 'roles and permissions'..
What do you want for this 'roles and permissions' ?
How does 'roles and permissions' look thru your eyes ?
If you were the programmer..
what would you code to control acceses for your web-site ?
WP (happens to) use these (default) roles :-
. administrator
. editor
. author
. contributor
. subscriber
Wonder what sort of 'Roles' names (and purposes) we would want for and Elgg-baed site ?
Those WP ones do not quite make sense in our elgg context, do they ?
[ Tho the presentation I have designned so far does not cater for 'default' roles - rather --
*all roles in muah 'Simple-Roles PlugIn' are defined by Elgg Admin and can then be applied.
More techno-babble:
happened to be cauhht-up- installing new WP Version
here after some length of time away from WP. And got reminded
about some rather neat features they've got -
which I am jealous about - 'export' and 'import' !??
and a few other tricks..
maybe we should 'clone such features' here @Elgg.
Let's dev together and do it ! shall we ?
Yalk to me ! y;all Devs - let us share the
code pie/s & do goodwill towards all Elggsters..!
I was fortunate to have Dhrup's basic roles installed on a production website and it has performed flawlessly! I am very anxious to see what develops from this new endeavor. You might be courious to what roles are in place on our site. So far only 3, admin, teacher and student. I don't see a problem adding alumni and parents to our system. Push forward Dhrup and I will help where I can.
@Steve: you knows what s/w you've got and how it dances ;-oO for you. I do promise for everyone @Elgg that I will *NOT be coding up 1100, 700, or whatever #lines of pure BS php code and neither subliminal advertising and tricky linkbacks ;-P for myself to do what I can get done with only 10 lines of code ! ;-P Thats *not my style.
stduying zOS, OS/390, RACF, ACF, zLINUX permisisons.. where I spent most of years` IT. the ui in there is easier and intuitively manageable.
This one is to catch Andras' attention.
However.. when he gets here..
no need to spend time reading code in orer to answer
If comments can be given from top-of-head,
tip-of-tongue recalls of the design intent..;)
if the built-in config array were to be stored
as *data (in the /datafolder?)
and any custom rules did the same,
a generic 'custom roles reader and picker upper'
could perhaps be coded to pick up
- builtin rules
- and custom rules
for the subsequent config merge!
so this coded array :-
function myroles_config($hook_name, $entity_type, $return_value, $params) {
$roles = array(
’limited_users’ => array(
'title' => 'yoursitename
get delegated to the /datafolder
some gui to manage these structures
and fingers-crossed...
we're on our merry easy-gui way
to allow and block to your heart's content;)
@All -FYI: I have been working on the GUI for Andras' Roles PlugIn to facilitate mucho easier customization and management of newer added roles, permissions, rules, and all etc in that there nice PlugIn - so that y'all cann worry LESS abiut 'fxk raw code' and have moare time to design your actual site's 'roles' and aspects t make it work for you with NeXgenEzz. Regards n Cheers Peeps. And say ThX to meister Aquila for instigating the first cut at SimpleRolesAndPermissions for his IcionMX rhe design for which has influences @here !
no names (to preserve privacy), but i got this in mssg from some-1 other (elgg) Dev -> '.. travelling in Africa and have very limited access to the Internet..' -- in it's own (strange;) way - this phrase in the context of out so freely taken-for-granted internet-access -- this cud be construed hilarious funnyy ! but reality is hardd !
dropped research and code development of that other roles plguin's gui extension to get the simple rolez design on a firmer and more stable base.. almost there! an readying for actual coding. hit one major snag though -> there seems to be no sinple-like technique for control over field level permissions - the data model's supporting api does not have *any hooks stubs ;o( the only way out is to descend to the mysql column priv acces control facility - *but this requires mysql userid to be setup ;( or maybe.. configuring a 'role' as a mysql userid ans rhen controlling access via this mechanism ;) still gets to be perhaps contrived or overtly complex. a simpler approach would be to simply have hooks allowed into the database.php functions to filter field level acceses using 'roles/permissions' decalarations.. lot of code logic to implement - more @quality tho not necessarily quantity.
copied over from (off-topic) http://community.elgg.org/discussion/view/1107309/other-vs-elgg-if-found-on-google?annoff=25
DhrupDeScoop 20120 Oct 17th
'wp + 10k users' ? hah! they who talk
'data designated public/logged-in-users..' ?? u gotta be talking abt DB sharding and that will take some effort. closest built-in to this i have seen is.. my oldd 'distributed elgg directions' prxes @ boston few years back; but never had a chance to devote time to that direction, even tho @conf dinnner a few Devs and approached to discuss actually developing code to support that design ;o(
'roles/perms' in elgg is wayy underdevloepd and not mature yet. my personal appraisal re that 'roles plugin' ? sounds attractivem but.. zero @user-oriented us/ ux, needs far too much 'code tweaking' (not what users want to do), not geared towards plug-and-play, does not (or very) utilize any of the elgg data model that naturally caters to and endears - think @nix`d g:u & 'rwx' ;) -- i see no internal limitations! & the sweet spot ? so simple to implement rbac for elgg; call this attitude just different set of eyes!) to std rbac styled roles/perms functionality. tha's not a step forward in my experience with (substantive) acf.. facilities of mature platforms. whay makes that unsuitable? => the need to code all those extra plugins to support other plugins (groups, profile mngr, etc). an acf by itself should be the be-all-end-all for rbac in elgg not further support code should be necessary! everything you've mentioned above can be coded for elgg's current dm & processes design -- minus the several thousand loc!
Steve Clay 20120 Oct 17th
FYI http://trac.elgg.org/ticket/4888
@Steve:
'do_something' relats to container of object/entity
& container is unique @ entity --
therefore cannot assign multiple roles for object (controlled resource)
to define different permission sets,
i.e. the traditional CRUD ('do_something') perms vector
will not work against (elgg) resources.
Elgg (as other platforms) needs to address Roles/Permissions per accepted standard methodologies - components — Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, Dynamic Separation of Duty Relations; Flat, Hierarchical, Constrained, Symmetric.... yadda, yadda...
There's a lot more to Roles & Perms than refractoring the API code - for a few extra hooks/stubs into ' core' API function for Developers -- ' open the door for more granular permissions control, and 2) anyone who wants to create a roles implementation can simply tie roles to the named capabilities." Do your research!
It is more about the syntax + semantics, the design + usability, the algorithm + UX... ! ;) beautifully coded PHP + smooth screens for end-users.. And the most imprtant point of all -- do the users really care about all those funky Developer-oriented core API hooks ? After all -> *they are the ones who keep us in business ! aren't they? When are y'all 'core team' (sic) gonna shut up and listen ??
Telling people to "shut up and listen" is not constructive.
It's fine that you want to concentrate on the UX side of things first, but to get anywhere we'll have to decide on an API for wiring capabilities like "can change access level" to the actual code. E.g. Drupal user_access(); Moodle has_capability(). WordPress current_user_can(). I'm well aware users will need an UI, but the capability system could be implemented fairly quickly. That would immediately give both the core devs and the many more plugin writers plumbing to build on. Plugins could define roles or just alter capabilities directly.
steve:
there's 7 points in my comment.
u answered @the joke!? & 16.66% of -->
"syntax semantics design usability algorithm UX"
(answering remainder 5.83% -- would have been constructive)
'well aware.. but...' = minimal answer to questions;
mere defensivenes but @absence of attack ;)
& i thot @another post u ackshully had 'sense of humor' !;-X
drupal.. wp examples --> interesting;
'implemented fairly quickly' ? ->
let's do it & open doors wider -->
elgg has since long ago lacked &
been criticized @ lacking 'roles', 'perms'
almost long as i've played w/ seriousness @2008;)
*&& elgg_has_capability -->
should & must return a CRUD vector!
--> container ~= 'role' and
'permission' on resource ~= crud vector.
however -- container will not allow map as many-many ;(
*esssential feature for basic RBAC.
I remember having this conversation with Brett about a year ago, and he was completely against the idea of roles/permissions in Elgg. I even brought up the Drupal method (which is probably how I would prefer to see it implemented). Has the official stance changed or is this still a speculative conversation?
To be clear, I was against putting roles themselves in core. I think we need to include the ability for plugins to be able to manage roles, which I believe Steve is alluding to with "Plugins could define roles or just alter capabilities directly." It's a longer term discussion to figure out exactly where that line is.
hmmm ;-o) core team, elgg core code, engine/start.php -- all can be completely against idea of roles/perms until 2112 lolz ;-) but as long as the core's design intent for plugins interfacing remains the same - one can code a plugin to do rolez/permz -- with no changes within the core code required - andras' roles plugin already demonstrates. i would make a few 1-line changes in the core to accomodate roles/perms more easily and the rest..? all within a plugin. i am slowly, cautiously, w/certainty refining a rolez/permz (plugin) design for elgg.. after many hours of research, design alternatives. modelled after linux rwx style, zos security server, os390 racf, mvs acf characteristics -- mixture of the best technologies tempered by nist's models and algorithms research.
My proposal boils down to formalizing/simplifying the creation/use of custom permissions hooks--which core already has a number of.
how about --> trigger_elgg_event ( 'read, $entity->type , $entity ) ?