Guidelines
In addition to the principles listed in the previous section, there are some basic Access Control rules to remember:
1 If you change the Access Control permissions for users who are logged into the system, the changes will not affect them until they log out and log back in again.
2 Users can belong to multiple groups. Every aPriori user belongs to at least one group: All Users. But most users also get assigned to one or more other groups that reflect something like the organization’s regions, or projects, or job function.
3 A user who belongs to a sub-group automatically belongs to all of that sub-group's parents, grandparents, etc.
4 To have access permission to a resource, a user must:
• belong to at least one group that grants that permission,
• NOT belong to any group that denies that permission with Strong Deny
5 The most restrictive permission is the one that counts. For example, a user might belong to one group that allows him or her to update a component, and to another group that explicitly prohibits (via Strong Deny) updating that component. In this case, the "deny" permission takes precedence and the user cannot update the component.
There are two modifiers called "Grant" and "Deny" that allow you to fine-tune this behavior. "Grant/Deny modifiers" above for more information. Also note that a given group can have multiple permission definitions consisting of the same action and the same resource, but with different rules.
Note: Group Inheritance vs. "Most Restrictive Permission Wins" – As mentioned above, a user who is a member of a sub-group is also automatically a member of all of that sub-group's parents. So what happens if a user belongs to a sub-group that grants Read + Update permission to a component, but the parent group grants ONLY Read access? Does the more restrictive permission of the parent prevent the user from updating the component?
By default, the user is not prevented from updating the component. Why? Because the Read permission of the parent group does not explicitly deny Update access to the user, it simply does not grant update access to its members. So somebody who is a member of ONLY the parent group will not be able to update the component, but somebody who is a member of the sub-group can. The parent permission does not grant it, but it does not deny it either. Further note that there is nothing special about parent-child group relationships when it comes to permissions. The permissions for each group are evaluated independently for each group, regardless of whether they are peers, or parent-child, or completely unrelated.