Roles: I need a better understanding

[kgroneman]

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:

• I can add the "submit posts" permission
• I can not remove the "read posts" permission

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. 

[lilim]

Hi @kgroneman -

Are the default permissions for your community set so that "read posts" is granted? If so, try leaving the permission set to "default" for this special role, rather than setting it to grant. (See example below of permissions for a moderator role.)

Also -

Are the default permissions for the category also set to deny?

Have you tried removing the role and then checking for that category?

[kgroneman]

Hi @lilim    Thanks for the reply.   Here are the default permissions in the areas I want to block a specific role from seeing:

Here are the permissions for the role I want to block:

Yet I switch to a user that has that role, and I can still access this area so obviously I'm not understanding how this works.    They have access to the parent category and sibling categories.  I just want to block them from this one. 

[lilim]

For the Knowledge Partner role at the board level, you could try moving the read posts permissions to "deny" rather than the "default". While it is also set to deny, it might be overridden by the permissions at the community level.

[kgroneman]

Ok..did that.  It made no difference.   I just don't understand why I can't block this role here.  The user has no other roles that has access to these private areas. 

[lilim]

Have you tried deleting that role from the board level and the category level (if possible)?

[CarolineS]

Have you confirmed that the roles you create are actually sticking? I had an issue a few weeks ago where my roles would always revert back to the default permissions after I saved them.

Support fixed this via some sort of configuration change that had to be deployed in the maintenance window.

[CarolineS]

Perhaps there's a name mismatch between the community-level role and the category-level role - e.g. two spaces accidentally in one of the versions of the name? I like @lilim's suggestion of deleting the role (maybe both roles) and trying again.

[kgroneman]

@lilim  I've deleted the role at the category level and recreated it twice.  @CarolineS  when I recreated it I copied/pasted the role name, and it's not a complicated role name so I'm certain there isn't a name mismatch.  I think it's time I open a support case and ask them to look at it and tell me why it isn't working.  Thanks a LOT for trying to help me figure this one out.  I'll post back here when support tells me what bonehead thing I'm doing to make it so this doesn't work.

[DanK]

Is it possible to reverse the logic of having this role exclude this location and rather have a role that allows the location, which is disabled by default.

We have several employee only or superuser only locales within Community. These are explicitly granted via a role rather than, as in your case, revoked.

[kgroneman]

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

[DanK]

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.

[kgroneman]

Ouch!  

[lolagoetz · Accepted solution]

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.

[kgroneman]

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.