Roles - Authority numbers

I could make a case for dropping authority numbers (and maybe policies) altogether and linking permissions directly to roles. Is it worth laying this out, or has that ship sailed?

The main points would be:

1. They make the whole system an order of magnitude harder to understand.
2. They provide convenience, but I think you could accomplish the same things without them.
3. They assume that MODx permissions are hierarchical, which they often aren’t.
4. They have potential side effects (through inheritance) that can lead to confusion and trouble.
5. They will create a monster support headache, no matter how good the docs are.

They are how having Roles within Groups is possible. You could hide Roles if you want to in a custom manager UI (and essentially set everything to 0 automatically), but this functionality is at the core of how the entire system works, and provides, IMO, one of the major benefits over the current Evo security system limitations.

Quote from: OpenGeek at Dec 21, 2009, 01:34 PM

They are how having Roles within Groups is possible. You could hide Roles if you want to in a custom manager UI (and essentially set everything to 0 automatically), but this functionality is at the core of how the entire system works, and provides, IMO, one of the major benefits over the current Evo security system limitations.

Fair enough. I wouldn’t want to hide Roles, I’d just want to hide authority numbers and any inheritance (and the Minimum Role field). Is there no way to have an architecture where people in groups can have different roles without using authority numbers?

In trying to implement permissions, I found the "Minimum Role" thing tremendously confusing (although I think I get it now). It’s not clear to new users whether that setting is assigning something or requiring something and it kind of implies that there is a per-user authority number setting (which one looks for in vain). The newer permission UI is a definite improvement, though, and it’s hard to say how much that might have helped. Labeling each grid with "Access Control List" at the top might help tie the Manager to the documentation.

It’s so much simpler to have roles (a la Evolution) where you say "this is what the user with this role can and can’t do." You can create as many roles as you like and there’s no chance of those users getting capabilities you don’t mean for them to have. You gain convenience with inherited roles, but at quite a cost in terms of understandability and confidence that you’ve done what you meant to do.

On many sites, there are users with specific roles that are not at all hierarchical and involve various subsets of permissions that are unique to each role. For those sites, authority numbers and inheriting roles, IMO, is confusing and of no real use. Maybe I’d have more appreciation for the system if I’d worked on large corporate or .edu sites with zillions of users and more hierarchical permission requirements.

One of my main concerns (and I hope I’m not misunderstanding this) is that if I accidentally assign the full Administrator policy to a role with a high authority number, a whole bunch of low-level users suddenly become super-users in all the User Groups where that role exists.

Quote from: BobRay at Dec 21, 2009, 02:50 PM

One of my main concerns (and I hope I’m not misunderstanding this) is that if I accidentally assign the full Administrator policy to a role with a high authority number, a whole bunch of low-level users suddenly become super-users in all the User Groups where that role exists.

Roles are Authority Numbers with Names only for description purposes. And I don’t understand your concern. If they are not in the Administrator User Group the Roles don’t apply. Roles are applied to Users in specific User Groups. Your Role in Group A does not affect your Role in Group B.

Quote from: OpenGeek at Dec 21, 2009, 02:56 PM

Quote from: BobRay at Dec 21, 2009, 02:50 PM

One of my main concerns (and I hope I’m not misunderstanding this) is that if I accidentally assign the full Administrator policy to a role with a high authority number, a whole bunch of low-level users suddenly become super-users in all the User Groups where that role exists.

Roles are Authority Numbers with Names only for description purposes. And I don’t understand your concern. If they are not in the Administrator User Group the Roles don’t apply. Roles are applied to Users in specific User Groups. Your Role in Group A does not affect your Role in Group B.

I understand that, but my understanding is that if I have many roles in the Administrator user group and I create a new role with access to the Mgr context, a role of 9999 and a policy of Administrator (full administrator policy), then add a user to the admin group with that role, everyone in the group becomes a super-user, not just the user assigned to that new role. Have I got that wrong?

Quote from: BobRay at Dec 21, 2009, 03:22 PM

I understand that, but my understanding is that if I have many roles in the Administrator user group and I create a new role with access to the Mgr context, a role of 9999 and a policy of Administrator (full administrator policy), then add a user to the admin group with that role, everyone in the group becomes a super-user, not just the user assigned to that new role. Have I got that wrong?

No, you don’t have it wrong, what you describe would give both Roles all the same Permissions, which is why you would design a "sub" Administrator policy containing only the permissions you want to assign to the new Role in the Administrators User Group.

Quote from: OpenGeek at Dec 21, 2009, 03:45 PM

Quote from: BobRay at Dec 21, 2009, 03:22 PM

I understand that, but my understanding is that if I have many roles in the Administrator user group and I create a new role with access to the Mgr context, a role of 9999 and a policy of Administrator (full administrator policy), then add a user to the admin group with that role, everyone in the group becomes a super-user, not just the user assigned to that new role. Have I got that wrong?

No, you don’t have it wrong, what you describe would give both Roles all the same Permissions, which is why you would design a "sub" Administrator policy containing only the permissions you want to assign to the new Role in the Administrators User Group.

OK. I know better than to do that, but I’ve learned not to underestimate the ability of users to make catastrophic errors. I can imagine a non-computer-savvy administrator who would insist on having super user authority and might do such a thing.