Scenario 4 – Understanding Inheritance

This scenario illustrates the effect inheritance has on rights, what is viewable before and after breaking inheritance as well as resetting inheritance. Remember that you always require rights on the parent category if you want to view the objects in the category tree.

Setting up rights on different levels can be easy with inheritance. This scenario describes how inheritance can be used in different ways to ensure the correct rights exist for each role. The tables below show a parent category Level A with two child nodes, Level A1 and A1a.

By default permissions are inherited and the HR role is granted permissions and rights on the parent Level A. HR inherits the same permissions on Level A1 and A1a. Those in the IT role only need permissions to Level A1a and are granted permissions specifically to this node.

Even though the IT role is added manually to Level A1a with View rights, people in the IT role cannot view the Level A1a category as they would need the View - Allow permissions on the parent (Level A) category in order to view child nodes

Inheritance is broken for the HR role on Level A1a, resulting in the permissions being updated from inherited to Explicit Allow and Explicit Deny as shown below.

HR permissions are manually changed to Allow on Level A1a where inheritance was broken. This allows the members in the HR role to execute items in Level A1a.

Add the Finance role and assign View Allow permissions on Level A which allows inherited permissions on Level A1 and Level A1a. Level A1a inheritance is then broken and no rights are assigned. None means that members of the Finance role cannot see Level A1a.

Resetting the inheritance on Level A1a causes the permissions of HR and Finance to be set back to the Level A parent permissions. Members of the Finance role can see and use items in all categories, but cannot run anything.

Related Topics