Understand permission inheritance of element objects

When you change access permissions on an element object, the element's parent and child elements can also change depending on the reference type. A reference type determines the relationship and access permissions between Asset Framework (AF) element objects in a hierarchy. This topic explains how access permissions work for the following reference types:

• Parent-Child

• Composition

• Weak

For more information on reference types, see Understand reference types.

Parent-child reference type

When you create an object or collection, it receives a default set of access permissions based on the parent's permissions set. After access permissions are set on a parent, the system uses the Child Permission settings (on the Permissions page of the Security Configuration window) to determine how permissions are applied to child element objects. These settings are listed in the following table.

1PI AF does not apply changes to referenced (not owned) objects. For example, changes to security for a secondary parent are not applied.

Examples of the Parent-child reference type

The following examples are provided to help illustrate the different child permission settings for Parent-Child reference types.

Example 1: Element hierarchy showing different access permissions

Each of the elements in the hierarchy shown in the following image have different access permissions.

As shown in the next image, each element in the hierarchy shown above is assigned to more than one identity; each identity has specific access permissions (read, write:

• Administrators and World identities: Have access to all three elements (EasternUS, SavannahSite, and ProductionLine1)

• Savannah_IT identity: Has access to SavannahSite

• SavnEngineers identity: Has access to ProductionLine1

Example 2: Add an identity to every element in the hierarchy

If you wanted to add the CorporateEngineering identity to every element in this hierarchy, you would add the identity to the parent element (EasternUS) as shown in the following image.

Example 3: Update child permissions for modified identities

To copy the parent permissions without affecting identities that already are assigned access permissions, set the Child Permissions option to Update child permissions for modified entries. The CorporateEngineering identity would be assigned to all three elements, and the existing identities (Savannah_IT and SavnEngineers) would remain unchanged.

The security strings for all three elements shown in the following image reflect that the CorporateEngineering identity has been added, but the other identities remain unchanged.

Example 4: Replace child permissions for all identities

To replicate the parent permissions for all identities in the hierarchy, set the Child Permissions option to Replace child permissions for all identities. In the following image, the security string for all three elements shows that the CorporateEngineering identity has been added, and has replaced the access permissions with those assigned to the EasternUS element.

Note: 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 EasternUS parent element.

Composition reference type

In a Composition reference type, the parent and child always have the same access permissions. The following rules apply to the Composition reference type:

• If you change permissions on the child, the parent automatically updates to match.

• If you change permissions on the parent, the child automatically updates to match.

• These changes cascade up and down the hierarchy.

Weak reference type

In a weak reference type, access permissions are not inherited.