Understand permission inheritance of element objects
- Last UpdatedJan 08, 2025
- 4 minute read
- PI System
- PI Server 2024 R2
- PI Server
When you change access permissions for an element, the access permissions for any parent or child elements might also change. The behavior depends on the reference type.
Parent-child reference type
When an object or collection is created, a default set of access permissions is assigned, based on the access permissions that are set on the parent. When access permissions are set on a parent, the following Child Permission settings on the Permissions page of the Security Configuration window are evaluated:
|
Option |
Description |
|---|---|
|
Do not modify child permissions |
Prevents access permissions that have been set for the current object or collection from being replicated to child collections and objects in the PI AF hierarchy. This option is the default when the connected PI AF server is running 2.5 and earlier versions. |
|
Update child permissions for modified identities |
For each selected item on the Items to Configure list in the Security Configuration window, replicates the access permissions for all child collections and objects for each identity on the Identities list whose access permissions have been modified. This option is the default when the connected PI AF server is running 2.6 and later versions. This option is not available when the connected PI AF server is running 2.5 and earlier versions. |
|
Replace child permissions for all identities |
For each selected item on the Items to Configure list in the Security Configuration window, replaces all child permissions for every identity on the Identities list with the parent access permissions. Note: Before you apply this option, be sure to review access permission settings for all items on the Items to Configure list to avoid unintentionally overwriting custom permissions that may have been applied elsewhere in the collection hierarchy. Review the following example for clarification. |
Examples
The following hierarchy has three elements, each with a different access permissions setting.
Sample element hierarchy
-
The Administrators and World identities have access permissions to all three elements: EasternUS, SavannahSite, and ProductionLine1.
-
The Savannah_IT identity has access to the SavannahSite element.
-
The SavnEngineers identity has access to the ProductionLine1 element.
Access permissions for sample hierarchy
Suppose you want to add a CorporateEngineering identity to each element in the hierarchy. You would add the identity to the parent element EasternUS:
Add identity to parent element
To replicate the parent permissions without affecting identities already assigned access permissions, you would set the Child Permissions option to Update child permissions for modified entries. The security string for all three elements shows that the CorporateEngineering identity has been added, but the other identities remain unchanged:
Replicate identity and modify existing access permissions
To replicate the parent permissions for all identities down the hierarchy, you would set the Child Permissions option to Replace child permissions for all identities. The security string for all three elements shows that the CorporateEngineering identity has been added, but has replaced the access permissions with those assigned to the EasternUS element:
Replicate identity and replace existing access permissions
Notice that the Savannah_IT and SavnEngineers identities no longer appear in the security string for the SavannahSite and ProductionLine1 elements because they were not included in the Identities list of the parent EasternUS element.
Composition reference type
Access permissions for child and parent are always the same.
If you change the access permissions for the child, the parent access permissions are automatically changed to match the child permissions. Similarly, if you change the access permissions for the parent, the child access permissions are automatically changed to match the parent permissions. These changes cascade down (and up) through the hierarchy.
Weak reference type
Access permissions are never inherited.