I've read a few posts/articles on roles and this is the most comprehensive one I've found.
If I understand it correctly, role assignments in categories, sub categories, etc. are only additive. They can't restrict. For example if a role at the community level gives permission to "read posts" but not "submit posts" the following is true at a lower level:
Is that correct? I'm making that assumption based on what I'm seeing. I have a specific category I don't want people with a specific role to see/access. I create the role at that category level and set all permissions to NO. However, when I switch to a user with that role, I can still see/access that category. They have no other roles. How do I do this? I think I'm being stupid here.
Solved! Go to Solution.
@DanK I would prefer not to do it that way if I don't have to as there are quite a few sibling nodes where the role needs permissions and I would have to create the role under each one of those. It should be simpler than that. What I'm trying to do SHOULD work. I need to find out why it doesn't.
When I was creating our superuser program we wanted expert users to be able to move posts to visible areas of community and also edit the tKB. To get the permissions right I ended up creating the superuser role on every single public category in the community and allowing the permissions I wanted at that level.
It makes sense that the permissions should work the way you are saying but I am not sure that they do or will.
The problem you can frequently run into is grant trumps deny, and the permissions are inherited from above. So if at the community or parent category level, you have default grant, then you can't deny as easily lower down.
It's complicated, but it can be done with experimentation. Without seeing from community level all the way down, though, I couldn't quite tell you where the error is. It's probably default granted somewhere further up the line when it should be default denied and then granted using the roles. You'll need to start at the top level and work your way down.
Ok then. It sounds like I need to remove the default access then grant access at ALL the lower level nodes. That sucks. 🙂 In all other community platforms I manage you can set all permissions for all roles at a node level. All permissions flow downwards unless they are changed at the node level to grant OR deny. Lithium role permissions need to catch up with what everyone else is doing.