You cannot assign access directly to a shared member. A shared member inherits access permissions from its base member, parent, or ancestor.
Planning checks access permissions at each level, first by user, then by group, based on the member’s access permissions inheritance relationship. If multiple access permissions exist, the least restrictive access permission is applied (for example, Write access takes precedence over Read access).
Sample Entity Members
Parent Entity | Child Entities |
|---|---|
United States | |
CA (base) | |
NY | |
West | |
CA (shared) | |
NV | |
Sales Region 1 | |
CA (shared) |
Table 2. Example of Inherited Access to Shared Members
Case | Access Permission | Effective Access for Base and Shared Member CA | Explanation |
|---|---|---|---|
Case 1 | CA (base) = None iDescendants (West) = Read | Read | CA inherits Read access from its West parent because Read is less restrictive than None. |
Case 2 | iDescendants (United States) = None iDescendants (West) = Read iDescendants (Sales Region 1) = Write | Write | CA inherits Write access from its Sales Region 1 parent because Write is less restrictive than Read or None. |
Case 3 | iDescendants (United States) = Write iDescendants (West) = None iDescendants (Sales Region 1) = Read | Write | CA inherits Write access from its United States parent because Write is less restrictive than Read or None. |