Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
From Crell's blog post: http://www.garfieldtech.com/blog/hierarchical-acls
The 'field of checkboxes' is not only complicated to use but not flexible enough for all the refined levels of permissions that may be desired. We could create a hierarchical permission system and a new permissions admin page to go with it.
Comment | File | Size | Author |
---|---|---|---|
#34 | jody-core-sf.pdf | 168.99 KB | Jody Lynn |
#2 | hierarchical-permissions.txt | 4.62 KB | Jody Lynn |
#1 | hierarchical-permissions.txt | 4.62 KB | Jody Lynn |
Comments
Comment #1
Jody LynnMy plan right now is:
Place all core permissions into a tree structure with corresponding names
Make a patch that changes all the permission names (the name keys, not the displayed text)
Restructure the permissions admin page to organize by the name keys into a hierarchical table
Change functions to respect hierarchical dominance of permissions
Improve UI of permissions table
A tree of the core permissions with my proposed new permission names is attached.
Comment #2
Jody LynnI'm trying to get the spacing correct in the file.
Comment #3
Crell CreditAttribution: Crell commented"Use PHP for block visibility" is probably a subset of Administer blocks, since you can't get to the form to use PHP without it.
Administer book outline should probably be something like book.admin.outline, or book.outline.
Not sure if it's appropriate for right now, but part of the goal is to kill the "administer X" permissions and replace them with much more fine-grained permissions. So comment.admin should probably be broken out into a half-dozen sub-permissions. Ibid for a couple of other places.
node.bypass seems misnamed. Shouldn't it be something like node.bypass_restrictions, or better yet node.access_all?
Revision access/reversion should probably be per-node type. It is not now. That's a problem. :-) Again, not sure if that's appropriate to fix here or not. (node.revisions.view.nodetype?)
Poll module can similarly be broken down further, I think.
search.access is probably more consistent than search.use.
Simpletest doesn't really have an "administrator". It has the ability to run tests or not. The current name is a bug. :-)
system.theme is confusing. Is that the ability to change one's personal theme, or the ability to change the site theme? Not obvious.
system.admin.access is one of those permissions that ideally would cease to exist in this model. Again, not sure if that's a now or a later.
user.account.change_own_username perhaps? Or user.account.edit.own.username? Hm...
Eventually I think all of the node.create/edit/delete permissions should be provided by node.module itself for all defined nodes; or rather, by a separate module that provides a pluggable node access mechanism based on permissions that can be replaced with another.
Subscribing. :-) Thank you for picking this up!
Comment #4
dmitrig01 CreditAttribution: dmitrig01 commentedThe node ones give me some trouble. node.create.X and node.X.create are good options, the first if you want to be able to be able to grant global "create everything" permissions, and the second if you want to be able to grant "do everything with X" permissions. I'm not sure which one is right.
Comment #5
Dave ReidComment #6
Anonymous (not verified) CreditAttribution: Anonymous commented@dmitrig01: that issue highlights the main limitation of the
foo.bar.baz
structure - it only allows simple inheritance for a single tree.i think we need two trees, one for the resource, and one for the action we are allowing on the resource. or, a clean way to distinguish between a resource tree and list of allowed actions, if we don't want inheritance for actions.
Comment #7
Crell CreditAttribution: Crell commentedThe question is, how do we handle multiple overlapping trees? That's non-trivial.
Alternatively, perhaps we can offer infix wildcards? node.*.create? Would that allow a way around needing multiple trees?
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedin case anyone can make it, we will be hacking on this at drupalcon: http://dc2009.drupalcon.org/node/4464
Comment #9
drewish CreditAttribution: drewish commentedsubscribing.
Comment #10
gregglesThis page is infamous, but there's not much evidence that the UI is bad. I believe that all of the usability tests done on Drupal so far have shown that this page is one of the few pages that people actually understand.
They are confused by the words used in the descriptions and by the grouping/ordering, but not by the "field of checkboxes."
Comment #11
yoroy CreditAttribution: yoroy commentedgreggles is correct. The permissions page as it is now performs quite well in usability testing. Last weeks testing confirmed this again. The page is huge but easily understood. (Still a lot of room for improving the actual workflow for setting permissions, i.e. make them show up directly after installing a new module but I can see how that is totally out of scope here :-)
Still, tracking this for ux-team because I get the idea that this new approach might help us solve things like #301902: Allow more users to see the node admin page in a better way.
Have a good sprint for this at DCDC!
Comment #12
wonder95 CreditAttribution: wonder95 commentedSubscribing
Comment #13
EastWan CreditAttribution: EastWan commentedsubscribing
Comment #14
sunWildcard-support seems the way to go.
Grant create action for a certain resource type:
node.create.story
Grant all actions for a certain resource type:
node.*.story
Grant create action for all resource types:
node.create
Grant all actions for all resource types:
node
The remaining question is just whether we solve this solely in the UI ("tick all"), but store all permissions expanded. Or whether we implement wildcard matching when user access is checked at run-time. I'm inclined to say it's rather an UI issue.
Comment #15
Crell CreditAttribution: Crell commentedI disagree. It needs to be a run-time check. If I give someone node.edit.* permission ("edit any node"), then create a new node type, I should not have to go back to the admin and click submit again just to give them permission to that new node type. That should still be perfectly doable in the DB using a materialized path-like structure.
Comment #16
sunSorry, yes, you're absolutely right. I didn't think of that, because that's one of the niceties a hierarchical permission system would finally allow.
Comment #17
jstollerI think I like where this is going!
Please, please, please include an "Administer everything" permission that inherits all rights. I expect that would make a lot of admins very happy.
Would there be a mechanism to exclude specific sub permissions? Could I give someone the equivalent of:
node.*
-node.revisions.delete
What might the UI for this look like? Adding exclusion means a simple check box will no longer work.
Would field level permission be possible for different content types?
Could I give different rolls permission to view/edit/delete specific menus? How about specific sections of a given menu (i.e. the ability to add and rearrange items only within a single branch of the Primary menu hierarchy).
This may be fodder for a separate discussion, but any thoughts about pairing hierarchical permissions with hierarchical rolls, thus allowing one roll to inherit the permissions of its children?
Comment #18
Crell CreditAttribution: Crell commented@jstoller: Those are very good questions, which we're trying to answer here. Please join in if you have something constructive to add to that answer finding. :-) (Hierarchical roles are a separate matter for now that I'd rather not deal with.)
Comment #19
Jody LynnI can't wrap my head around how we could allow the use of wildcards in the middle of permissions, like node.*.story, on a UI level. I can see node.create.* as hierarchical rows of inheriting checkboxes, but not node.*.story and the like.
When we discuss these hierarchical permissions though and we get to the wildcards issue and give examples of possible permissions like node.*.story.title, we almost always use the node example rather than any other type of permission. This makes me wonder if it would not make sense to split out the node permissions from the other permissions in the system, and have two systems. After all, the node access system is already intertwined with the node permissions in confusing ways, so maybe node permissions would be better separated out.
Comment #20
sunWildcards probably apply to all permissions that can (or could) be applied to a certain type only. Examples:
- Users have a type, it's just called "user role".
user.edit: Edit users
user.edit.roleA: Edit users with roleA
user.edit.roleB: Edit users with roleB
user.create: Create users
user.create.roleA: Add user with roleA
...
user.*.roleA: Do anything with users with roleA
- Taxonomy terms have a type (vocabulary).
etc.
Comment #21
Crell CreditAttribution: Crell commentedNode access controls do need to be better abstracted from the permission system, but there's plenty of use for hierarchical permissions otherwise. Specifically, I'm thinking of "show this menu item if the user has this.menus.concept.*". For example, the /admin/users page would have a permission restriction of admin.users.*, which would give you access to the admin/users summary page iff you had permission to any of the sub-tasks of user administration. That makes the "access administration pages" permission pointless, and menu items behave more naturally.
Comment #22
Jody LynnThe UI for this is going to be a big part of changing this system. Should we try to start making rough mockups of a UI or just try to get moving on the functionality first?
Comment #23
yoroy CreditAttribution: yoroy commentedIt would probably be best to start a seperate issue for the UI. We found that discussing UI and functionality in one issue complicates matters real fast and makes it hard to keep track of what is actually being discussed.
But please do open one, ideally with a nice briefing of what UI should accomplish. Invite people to post mockups and screenshots etc. Let me know where it ends up and I'll try to send some UI peoples over.
Nice opportunity this, as you all are still in the early stages of hashing out the functionality, so still time to have both issues inspire eachother. Do it! :-) Thanks.
Comment #24
Crell CreditAttribution: Crell commentedWould it be better to continue this here in the queue, or in a Group on g.d.o?
Comment #25
yoroy CreditAttribution: yoroy commentedLet's try the queue. Catch wrote up a nice outline of how it could work in #411414: Module enabling / task workflow design. We've seen a lot of good brainstorming and mockups on g.d.o. but it doesn't get a lot of eyes from developers there and in general it seems hard to carry over ideas from there to here.
Comment #26
jstollerSo if I understand this correctly, all permissions are of the form moduleName.actionName.objectName.subobjectName, with the potential to continue this down to an arbitrary level of specificity. So if I grant a user node.edit.page, then I'm really giving them node.edit.page.*. That way if I later enable field level permissions, they will automatically have node.edit.page.body and node.edit.page.title permissions.
As for wanting to use a wildcard for the actions as well, I'm wondering how much of an issue that is. Unlike objects, which are naturally hierarchical and can be subdivided ad infinitum, the actions we perform on those objects are discrete and limited in number. Basically, for any given object (or component there of) you can potentially view, edit, create, or delete it. To this we add one more option, administer, which indicates all of the above. In this context, rather than a wild card search we're really talking about a few or statements. I.e. — "Does the user have edit or administer privileges for this item?" In fact, while wildcards used in the object reference must be checked at run-time, it seems like the action wild card (or administer action) could just be a UI ploy that grants all four possible actions behind the scenes. Am I missing something?
Comment #27
Crell CreditAttribution: Crell commentedWell I don't think we need to lock ourselves down to moduleName.actionName.objectName. There are cases where that makes sense, but nothing should be forced to be module-centric, for instance. (That only makes it harder for modules to integrate into a cohesive system.) New permissions should be able to be added anywhere they make sense to.
The level of specificity will probably have to be capped somewhere, just like it is for the menu system, in order to make decent queries possible. But otherwise yes on the nesting behavior. Which, now that I think about it, would allow for node.edit.page.$nid permissions to "just kinda work". OK, now I'm getting excited. :-)
"Administer Foo" permissions, though, need to go away and die. "Administer users" gets replaced with granting someone user.* permission. "Administer nodes" gets replaced with node.*. "Edit any page" becomes node.edit.page.*, and "administer organic groups" becomes og.*. Ideally it will lead to modules providing naturally more fine-grained permissions instead of "administer mymodule" and "the rest of you random people can't do anything", which is the norm these days and sucks royally. A lot of random module permissions would become system.mymodule.configure, or something like that, which would allow someone with system.* permission (formerly "administer site configuration") to pick up those permissions automatically, unless they were excluded from that user.
Follow? The original blog has more. :-)
Comment #28
sunNow, this simply blows me away. :)
However, the last sentence of yours made me think. Imagine modules are supposed to put their configuration permissions into system.mymodule.configure, then this means we allow and are encouraging module developers to put their permissions into "foreign" permission structures. That's awesome for this specific use-case, but could also lead to some drawbacks of unwanted wildcard permissions. I'm trying to think of a good example, but it's hard - this might do it: Consider Better Formats module, which uses permissions to control the input format selector on content-type specific node forms. So, a user with the right permissions will see additional form elements on the node form. My immediate suggestion would be: Use node.edit.page.formatX. However, wildcard permissions for node.edit or node.edit.page could then result in a) unexpected and b) unresolvable user permissions, i.e. the user would have no chance to configure permissions differently without granting permissions without wildcards.
Comment #29
jstollerSo perhaps "module" was the wrong noun to use there. How about group.action.object, where "group" represents a logical collection of rights that share a defined object hierarchy? For instance node.'action'.'content type', or menu.'action'.'menu ID'. A module could then enhance this by expanding the defined object hierarchy for a given permission group. For instance node.'action'.'content type'.'field group'.'field', or menu.'action'.'menu ID'.'item ID'.
Of course, now I've convinced myself that infix wildcards are a necessity. What if I simultaneously want to control node permissions by user and field? I would have something like node.'action'.'creator'.'content type'.'field group'.'field'. This would be impossible to manage without using wildcards for 'creator' and perhaps 'content type'. I kinda feel like this is trying to force a direct hierarchy where it doesn't exist. Really what we're dealing with is more of a forked hierarchy, like node.'action'.('creator ID'&&'content type'&&'field group'.'field').
Comment #30
sunTo advance on #28:
OTOH, we could also simply define a standard like
thing.configure
. "Administer site configuration" would then equal:...catching...
Comment #31
Crell CreditAttribution: Crell commented- Yes, group is a much better top level logical item than module. Often that will correlate to a module, but not always.
- @sun, hm, valid point. I suppose the answer there is that either input formats should be in their own tree, or use something other than the permissions system for them.
- @#30, We want to be careful that foo.configure doesn't become the new "administer foo", as that's what we're trying to get away from. If anything, I'd prefer to see foo.configure.setThingX, foo.configure.setThingY, foo.configure.doThingZ. Extremely fine-grained.
- It occurs to me that if we allow and encourage infix wildcards then we're not really dealing with a hierarchy anymore, are we? We're dealing with an n-axis label. Of course, there's absolutely good reasons to do so as discussed above. The plot thickens...
Comment #32
BerdirThis sounds almost too good to be true :)
An idea I just had about a possible UI is (maybe opt-in to another, more "classical" way), a simple auto-complete field, which is intelligent enough to handle autocompletion of the following things, similiar to how Code Completion works in IDE's:
- partially names: no => node
- next-level names, after a .: node. => create, delete, edit, anotherAction
- recognition of *: node.*. => page, article, anotherNodeType
- automatic validation: node.illegalAction => no corresponding permission found; back to node.
- maybe description searching, something like: Create new node => node.new.
After the new permission "thing" has been entered, the roles can be selected, optionally a description added and saved.
The saved permissions could then be displayed in a table, with the permission string, the actived roles and the description. It would allow to delete, add/remove roles or change the permission. If no description has been entered, or even additionaly, some sort of automatic description could be displayed, examples:
node.* => Administer nodes
node.edit.* => Edit all Nodes
node.*.page => Administer nodes of type page
node.edit.page.134 => Edit Node with nid 135
Of course, that's only possible for a limited and more or less hard-coded number of combinations.
Hrm.. too bad I don't have time for GSoC that summer ;)
Comment #33
EmanueleQuinto CreditAttribution: EmanueleQuinto commentedShould not be better to separate explicitly "domain" and "action"? Use dot for hierarchical fine graining of the domain, slash for action and hash for conditions;
At this point user_access needs something more complex than the current isset in the $perm array test; something like
array_uintersect($string, $perm[$account->uid, "_user_access_cmp")
where _user_access_cmp would perform some preg_match...Comment #34
Jody LynnI'm submitting this slideshow on the issue to the core dev summit at DCSF to renew motion for D8.
Comment #35
David Latapie CreditAttribution: David Latapie commentedHierarchical permissions is tangential with tri-state permissions (allow/inherit/disallow, made necessary by the multi-role feature).
Hope this helps.
Comment #36
joachim CreditAttribution: joachim commentedOne application of this would be to get something like http://drupal.org/project/node_permissions_grid into core -- this currently has to do some fiddly work with regexps in order to present node-related permissions like this:
Comment #37
amc CreditAttribution: amc commentedsubscribe
Comment #38
joachim CreditAttribution: joachim commentedHow about adding more JS to the permissions page so clicking the 'administer nodes' checkbox automatically checks (and greys out) all the 'create / edit / delete' permissions?
In other words, the vertical equivalent of the authenticated user javascript.
This could be achieved fairly easily by adding a 'dependents' key to a permission's data array.
Comment #39
snable CreditAttribution: snable commentedMaybe a single "parent" dependency will do , depending on the hierarchy, of course.
The other way round, it might be an idea to have "override" messages or visual markers to make the permission section more transparent and informative?
Comment #40
lpalgarvio CreditAttribution: lpalgarvio commentedwhat about combining not tri, but quad-state permissions, WITH weighted and tiered permissions, ALONG with weighted and tiered roles?
(tier is just another name for hierarchy)
sounds confusing and uberly complex huh? i'm sure it is...
but oh well, i'm going to mix in some more things :P
* decimal-weighted permissions, because we would like increments in 0.5.
* OR
* longer-range-weighted permissions, like -99 to +99, because we like flexibility (ok, maybe not this much!)
* user one protection given with high fixed weights
* role delegation permission
* role descriptions (for 6.x, role fields for 7.x, if they can be set as entities - that way you can also add pictures);
* full node moderation queue and revision queue, on a per content type, role and user basis.
* new permissions, like user_is_blocked, imitating the user status in profile.
* treat users, roles, nodes, taxonomy, etc as entities - this way you can tie permissions to them or even create custom permissions based on Rules, Tokens or whatever APIs.
* perhaps something in those lines for Fields? of course, fields should apply to any entity, including users, roles, nodes, taxonomy, etc.
(in this sense, permissions would be like super fields that would attach to any entity, field or view - not sure though if a view will be a entity or so)
for my examples i will use the following roles:
administrator is the man in charge with all the settings, having supreme rule over the site.
designer is someone with access to theme and structure related settings, and is responsible for theming the site.
manager is the actual owner(s) of the site, the boss(es) of the company. they have full power over data and access to some configurations, but not everything, to avoid breaking the site, as most people aren't familiar with advanced settings like permissions.
moderator is someone trusted by the owner, with duties like moderating users, update stocks of products, moderate nodes, check reports and confirm orders. moderators have slightly less permissions than managers, only missing the configuration wise permissions in comparison.
publisher is in charge of creating new nodes, products, translate nodes, etc. they should not have permissions to edit nodes that don't belong (except through revisions) to them and all the content they touch remains pending review by a moderator, remaining unpublished or at latest approved revision. they can make any type of content except books.
purchasers are users who actually buy something (or an amount of something, or number of points, etc) in the site and for that, has fewer content type creation permissions, like comment, forum, poll and blog.
trusted user are users that are whitelisted and so they can make content without requiring approval. they can also make, say, the same content as purchasers.
untrusted user are users that are blacklisted, as they behave in a bad manner, like occasionally flaming, trolling or spamming, but not to the point of mandating a ban/block. this can be a probation role, with a time expiration, after which the user returns to the authenticated user pool... or not. being untrusted, they cannot make or edit comments.
blocked user has been blocked permanently (or until someone flips the switch). when used with something like Rules or Triggers/Actions, it could automatically block the user. or there could be a permission named user_is_blocked for this effect, superseding the user_block_status_or_whatever_it_called. this would effectively allow mass blocking users, through roles, while minimizing human errors and admin efforts.
authenticated user has regular access and permissions to make forum topics, comments and vote on polls.
anonymous can only view content.
weighted permissions
these would work in ranges.
say -99 to +99
or -50 to +50
or -20 to +20.
basically the idea is that if an entity has a positive value, then another entity that is being compared that has negative value, will have permission superiority over the previous entity.
this means a -25 is superior to a +30 (is bigger in drupal, although smaller in math).
tiered permissions
permissions could have a hierarchy, in which each permission has a parent and child, inheriting or not their flag.
in tiers, inheritance would work reverse.
to visualize this, take this example:
imagine the concept that a permission Administer Users, unless otherwise challenged by child permissions, is inherited by their childs.
* Administer Users (allow for admin, manager & moderator)
-----delete users (inherit admin, manager & moderator)
-----delegate users (inherit for admin & manager, disallow for moderator)
after tiers are applied, we apply weights.
* Administer Users (allow for admin -20, manager -20 & moderator -20)
-----delete users (inherit admin -20, manager -15 & moderator -10)
-----delegate users to roles (inherit for admin -20, semi-allow manager -15, disallow for moderator -10)
this means manager can delete managers and moderators, but not admins, and delegate moderators, but not admins or managers. why different for delegate? check bellow...
to organize tiers, we can make custom top-level entries, which we could call permission groups (to differentiate).
tiered roles
would work as tiered permissions, but inheriting permissions on a per role basis.
example:
* administration
--------moderator
--------manager
--------designer
--------administrator
* authenticated user
----trusted user
--------purchaser
--------publisher
----untrusted user
--------blocked user
again, to organize tiers, we can make custom top-level entries, which we could call role groups (to differentiate).
weighted roles
weights are applied in roles after tiers.
and now, the quad-state permissions and all that confusion about semi-allow!
quad-state permissions
quad-state permissions would be disallow, inherit and allow, as said before, but also include semi-allow.
allow - permit to entities of same or bellow (greater than or equal) the tier or weight
semi-allow - permit, but only to entities bellow (greater than) the tier or weight
inherit - inherit the permission from tier or weight bellow
disallow - negate the permission (replaces any tier or weight)
(the names could be changed to something better)
these permissions could be applied to roles, users and anything considered a entity.
conclusion
like said before, permissions can be applied in tiers and in weights.
they can be applied to entities or fields.
entities can be roles, users, nodes, taxonomy, etc.
fields are cck fields, which are applied to entities.
roles have collections of permissions, sorted by weight and structured hierarchical in a tier.
permissions can be further applied to ALL ENTITIES, including roles, again sorted by weight and structured hierarchical in a tier.
weights take priority over tiers in the end.
and so do entity permissions over role permissions...
and so do field permissions over entity permissions.
example of a complex case: delete user permission
weight role permission flag
-99 root_user allow
-20 administrator: allow
+1 designer: disallow
+2 manager: allow
+3 moderator: allow
+4 publisher: inherit
+5 purchaser: inherit
+6 some_3dparty_user_trusted: allow
+6 trusted user: inherit
+7 untrusted user: inherit
+8 blocked user: inherit
+19 authenticated user: inherit
+20 anonymous: disallow
the permission system would work from bottom to top.
what happens here?
* anonymous can't delete users
* authenticated, blocked, untrusted, trusted, purchaser and publisher inherits this behavior
* some_3dparty_user_trusted user, who happens to belong to trusted users, but has this permission, can delete users from trusted role to authenticated user role.
* moderator can delete users from publisher to authenticated
* manager can delete the same users moderator can, but also moderators, as his role supersedes them
* designer can't delete any users at all, like anonymous
* administrator can delete all users from designer to authenticated user, but not the root_user.
* root_user can delete ALL users except himself.
note:
the weight on the permission for some_3dparty_user_trusted is +6 with allow - that is why he can delete trusted users (which are +6 for the same permission). if he had semi-allow, he could only delete untrusted and bellow.
for root_user, should be a fixed/unchangeable -99 permission tied to his account, so that he can not ever be deleted.
another example: edit any page (as in node type page)
weight role permission flag
-20 root_user allow
-20 test_user allow
-20 administrator: inherit
+1 designer: semi-allow
+2 manager: inherit
+3 moderator: allow
+4 publisher: inherit
+4 some_3dparty_user_trusted: semi-allow
+5 purchaser: inherit
+6 trusted user: inherit
+7 untrusted user: inherit
+8 blocked user: inherit
+19 authenticated user: inherit
+20 anonymous: disallow
the permission system again would work from bottom to top.
and what happens here?
* anonymous can't edit pages
* authenticated, blocked, untrusted, trusted, purchaser and publisher inherits this behavior
* some_3dparty_user_trusted user, who happens to belong to trusted users, but has this permission, can edit pages belonging from purchaser role to this time anonymous role (some pages can belong to no one), but not the ones of publishers
* moderator can edit pages from publisher to anonymous
* manager can edit the same pages moderator can, but also moderators, as his role supersedes them
* designer this time can edit any pages from manager to anonymous
* administrator can edit any pages from designer to anonymous, but not those belonging to root_user.
* root_user can edit ALL pages but so can test_user. test_user can also edit root_user pages.
note:
the weight on the permission for some_3dparty_user_trusted is +4 - that is why he can edit pages belonging to purchaser (which are +5 for the same permission), but not those of publisher, as though they have +4 like them, he has semi-allow and can't edit others on the same weight. if it was 5, he would only be able to edit the ones from trusted to anonymous.
root_user and test_users can edit everything including the ones from each other, as they share allow and -20.
but other administrators inherit the semi-allow from designer, hence they can only edit bellow their weight.
---------------------------------------------------------------------------------------------------------------
as for:
* role descriptions (for 6.x, role fields for 7.x, if they can be set as entities - that way you can also add pictures);
* full node moderation queue and revision queue, on a per content type, role and user basis.
role descriptions would be required to help admins describe the roles they make
and node queues and revisions could use the same principle of permissions
---------------------------------------------------------------------------------------------------------------
well i guess that is it.
it is highly complex and that is why i highly doubt it will be applied at all in a contrib module, much less in drupal core.
even if this idea (or other ideas in this thread) get even partially used in drupal core, 8.x ish while distant, is a long shot. a massive contrib module wouldn't be easier either.
meh, i know i'm crazy
maybe bits here and there could be used for a simpler system?
we can always have loads of roles dedicated to permissions and separate them from visible roles...
hope you enjoyed reading ;)
Comment #41
lpalgarvio CreditAttribution: lpalgarvio commentedmeh, btw, invest highly in UI.
like colored horizontal sliders...
meh, take a look at SMF (SimpleMachines Forum).
it has part of this sort of thing for ages.
Comment #42
Crell CreditAttribution: Crell commentedUm. A permissions system that takes that much text to explain sounds like one that is over-engineered. I got lost part way through it. There comes a point where we need to not have a single permission system for everything but allow some systems to use some other, pluggable mechanism.
Comment #43
jstollerI got a little lost in #40 as well, though there are bits in there which I think sound reasonable (and have heard discussed elsewhere).
A tri-state permission system that permits both "allow" and "disallow" settings would be hugely helpful (the "semi-allow" permission suggested in #40 sounds overly complex and unnecessary to me). This was requested in #218764: Allow - Deny (ignore) - Forbid permissions.
Associating weights with roles is also a great idea (and perhaps a requirement once "disallow" is implemented). I saw a discussion of this at #228061: Usability UMN: Allow roles to be weighted.
I'm not sure if this is exactly what LPCA had in mind, but I have long wished for hierarchical roles, where being assigned to Role-A implies that you are also in Role-B. In fact, about 2.5 years ago I put in a feature request which included something along those lines (#217934: expanded user access management), but it didn't gain enough traction at the time.
Hierarchical permissions—which we're supposed to be discussing here—also sound really amazingly cool. Though the more I think about it, the harder it is to see a clear hierarchy.
Comment #44
lpalgarvio CreditAttribution: lpalgarvio commentedthis kind of system is always complex and hard to implement.
a good example of that would be SMF itself.
version has been in RC state for about 3 years now (2007)...
and started development around 2005
froum wikipedia SMF article:
http://en.wikipedia.org/wiki/Simple_Machines_Forum
it's version 2.0 that includes the new hierarchical system:
it say's reduce, but it also adds complexity.
i suggest you guys install SMF 2.0-RC3 and take a look at the permissions.
you'l have to enable hierarchical permissions in the configuration to see it working.
http://download.simplemachines.org/?archive
Comment #45
geek-merlin!
Comment #46
lpalgarvio CreditAttribution: lpalgarvio commentedsee #1200572: Concept of a hierarchical permission system
Comment #47
xjmClosing this issue as a duplicate of #1200572: Concept of a hierarchical permission system.