From Crell's blog post:

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.


Jody Lynn’s picture

My 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.

Jody Lynn’s picture

I'm trying to get the spacing correct in the file.

Crell’s picture

"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!

dmitrig01’s picture

The 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.

Dave Reid’s picture

Issue tags: +permissions, +access
beejeebus’s picture

@dmitrig01: that issue highlights the main limitation of the 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.

Crell’s picture

The 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?

beejeebus’s picture

in case anyone can make it, we will be hacking on this at drupalcon:

drewish’s picture


greggles’s picture

The 'field of checkboxes' is not only complicated to use

This 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."

yoroy’s picture

Issue tags: +Usability

greggles 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!

wonder95’s picture


EastWan’s picture


sun’s picture

Wildcard-support seems the way to go.

Grant create action for a certain resource type:

Grant all actions for a certain resource type:

Grant create action for all resource types:

Grant all actions for all resource types:

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.

Crell’s picture

I 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.

sun’s picture

Sorry, 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.

jstoller’s picture

I 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:

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?

Crell’s picture

@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.)

Jody Lynn’s picture

I 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.

sun’s picture

Wildcards 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).


Crell’s picture

Node 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.

Jody Lynn’s picture

The 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?

yoroy’s picture

It 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.

Crell’s picture

Would it be better to continue this here in the queue, or in a Group on g.d.o?

yoroy’s picture

Let'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.

jstoller’s picture

So 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, then I'm really giving them*. That way if I later enable field level permissions, they will automatically have and 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?

Crell’s picture

Well 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$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*, 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. :-)

sun’s picture

Now, 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 However, wildcard permissions for node.edit or 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.

jstoller’s picture

So 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').

sun’s picture

To advance on #28:

OTOH, we could also simply define a standard like thing.configure. "Administer site configuration" would then equal:



Crell’s picture

- 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...

Berdir’s picture

This 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 =>

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 => 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 ;)

EmanueleQuinto’s picture

Should 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;

Edit Node with nid 135
Edit all nodes of type page*
Administer all nodes of type page
Edit all nodes
Edit all own nodes
any action on own nodes

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...

Jody Lynn’s picture

Version: 7.x-dev » 8.x-dev
168.99 KB

I'm submitting this slideshow on the issue to the core dev summit at DCSF to renew motion for D8.

David Latapie’s picture

Hierarchical permissions is tangential with tri-state permissions (allow/inherit/disallow, made necessary by the multi-role feature).

Hope this helps.

joachim’s picture

One application of this would be to get something like into core -- this currently has to do some fiddly work with regexps in order to present node-related permissions like this:

amc’s picture


joachim’s picture

How 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.

bumblebee’s picture

Maybe 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?

lpalgarvio’s picture

Title: Hierarchical Permissions System » Tiered and Weighted Permission & Role System V1

what 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.
* administration
* authenticated user
----trusted user
----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.


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.

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.

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 ;)

lpalgarvio’s picture

meh, 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.

Crell’s picture

Title: Tiered and Weighted Permission & Role System V1 » Hierarchical Permissions System

Um. 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.

jstoller’s picture

I 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.

lpalgarvio’s picture

this 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:

On 8 April 2007, Simple Machines announced the introduction of their next version, SMF 2.0 [8]. SMF 2.0 has been in development alongside SMF 1.1 since December 2005.

it's version 2.0 that includes the new hierarchical system:

# Permission improvements such as group inheritance and permission profiles to further reduce the complexity of the permissions 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.

axel.rutz’s picture


lpalgarvio’s picture

xjm’s picture

Status: Active » Closed (duplicate)

Closing this issue as a duplicate of #1200572: Concept of a hierarchical permission system.