Software AG Products 10.5 | Using CentraSite | Type Management | Composite Asset Types | Usage Scenarios
 
Usage Scenarios
The outcome of each operation is given based on a very simple type and instance configuration in each of the usage scenarios.
Unless otherwise stated, the instances that each operation is performed on is:
Key
Description
IoA
Instance of type A
IoB
Instance of type B
Delete Usage Scenarios
In the following sections, we describe some delete usage scenarios.
Association Relationship
Given the type model:
The result of the delete operation is:
Operation
Expected result
Delete IoB
Fail because of incoming relationship from IoA
Delete IoA
Success. Post-condition: IoB is left intact
Aggregation Relationship with Containing Constraint on Type A
Given the type model:
The result of the delete operation is:
Operation
Expected result
Delete IoB
Fail because of incoming relationship from IoA
Delete IoA
Success. Post-condition: IoB is left intact
Aggregation Relationship with Containing Constraint on Type B
Given the type model:
The result of the delete operation is:
Operation
Expected result
Delete IoB
Fail because of incoming relationship from IoA
Delete IoA
Success. Post-condition: IoB is left intact
Composition Relationship with Containing Constraint on Type A
Given the type model:
The result of the delete operation is:
Operation
Expected result
Delete IoB
Fail because of incoming relationship from IoA
Delete IoA
Success. Post-condition: IoB is removed
Composition Relationship with Containing Constraint on Type B
Given the type model:
The result of the delete operation is:
Operation
Expected result
Delete IoB
Success. Post-condition: IoA is removed
Delete IoA
Success. Post-condition: IoB is left intact
Composition Relationship with Permission Scenario
Given the type model:
With the constraints:
*User who performs the deletion is Fred
*Fred has Full permission on IoA
*Fred has Read permission on IoB
The result of the delete operation is:
Operation
Expected result
Delete IoB
Fail. User Fred does not have full permission on IoB
Delete IoA
Fail. User Fred does not have full permission on IoB
Versioning Usage Scenarios
Versioning for Association Relationship and Aggregation Relationship are the same and do not change from previous versions, therefore only Composition Relationship are shown below.
Given the type model:
Note:
Both variants of a composite relationship (source and target) are supported and are orthogonal.
Based on the instances given above, the following scenarios are considered relevant.
Versioning of IoB
This causes just IoB to be versioned and the IoA version is left unchanged. Pictorially, this looks like:
Versioning of IoA
Versioning of IoA will result in the composite relationship being used to work out which other assets should be versioned at the same time. This will result in IoA and IoB being versioned together (if we fail to version either then neither is versioned).
This pictorially looks like:
Permission Usage Scenarios
For the permission scenarios, the following instances with the annotations for the owner and permissions is used as basis.
Association Relationship Permission Propagation
When an Association Relationship is used, the permission propagation does not take place. This means that if an instance permission is set, then only that instance's permission is affected. This means that if user Mary adds Read permission for user Mark on IoA, then Mark only gets permission to Read IoA. He does not get permission to Read IoB. Pictorially this looks like:
Composition or Aggregation with Weak Propagation
One of the key points of permission propagation is what happens if a user only has a Full permission on a subset of the assets to which the permissions need to be propagated. In this case, the usage of the so-called weak propagation rule comes into effect. The rule states that if a user does not have permission to propagate to all instances in the set, then the permissions is propagated to only the instances which are allowed.
For this scenario the following model is used:
Based on this model, the instances and the permissions to start with should be:
Now if user Paul adds Read permission for user Jack to IoA, Jack will only get this permission on IoA as Paul does not have the rights to give Jack the permissions on IoB. Even though Paul has Full permission on IoC, because it is a child of IoB, Jack does not get the permissions for IoC because of weak propagation. We trim or terminate the propagation at IoB.
This pictorially looks like:
Composition or Aggregation Relationship Updating Sub-component
Updating the permissions of a sub-component without affecting the overall composition or aggregation is not affected with the changes. Therefore if user Fred wants to explicitly add Read permission for Jack on IoB, this is possible.
This pictorially looks like:
Composition or Aggregation Relationship with Full Propagation
Full propagation happens when all sub-components can be updated by the instigating user. For example, Mary wants to give Read permission to Simon on IoA with permission propagation through the Composition or aggregation relationship. As Mary has Full permissions on IoA and IoB, the permissions are propagated over the relationship.
This pictorially results in:
Export Usage Scenarios
In the following sections, we describe some export usage scenarios.
Export with Association Relationship
Export works the same as in previous versions - the usage given here assumes that no additional options are selected.
Given the model:
The result of the Export operation is:
Operation
Expected result
Export IoB
Export set contains IoB. It does not contain IoA
Export IoA
Export set contains IoA. It does not contain IoB
Export with Composition or Aggregation Relationship
For both Composition and Aggregation Relationships, the rules are exactly the same. When such a Relationship with the appropriate containing rule is found, then traverse the relationship and add sub-components to the set.
Given the model:
OR
The result of the Export operation is:
Operation
Expected result
Export IoB
Export set contains IoB. It does not contain IoA
Export IoA
Export set contains IoA and IoB.
Move Organization Usage Scenarios
Move organization is an administrative task and may only be performed by someone with appropriate administration rights. This means that permissions and ownership do not play a role when performing the move operation.
Move Organization with Association or Aggregation Relationship
When moving an asset from one organization to another, the Association and Aggregation Relationships do not change any related assets. This is because both of these relationships are considered to be loosely coupled.
Given the model:
OR
The result of the Move Organization operation is:
Operation
Expected result
Move IoB
Only IoB is moved to the new organization. It does not move IoA.
Move IoA
Only IoA is moved to the new organization. It does not move IoB.
Move Organization with Composition Relationship
When a Composition Relationship with the appropriate containing rule is found, then traverse the relationship and move the sub-components to the new organization.
Given the model:
The result of the Move Organization operation is:
Operation
Expected result
Move IoB
Only IoB is moved to the new organization. It does not move IoA.
Move IoA
IoA and IoB is moved to the new organization.
Change Ownership Usage Scenarios
Change Ownership is an administrative task and may only be performed by someone with appropriate administration rights. This means that permissions and ownership do not play a role when performing the change ownership operation.
Change Ownership with Association or Aggregation Relationship
When changing an asset's ownership from one user to another, the Association and Aggregation Relationships do not change any related assets. This is because both of these relationships are considered to be loosely coupled.
Given the model:
OR
The result of the Change Ownership operation is:
Operation
Expected result
Change Ownership of IoB
Change the ownership of IoB. It does not affect IoA.
Change Ownership of IoA
Change the ownership of IoA. It does not affect IoB.
Propagation of Profile Permissions
In addition to propagating permissions that control the access to an asset instance (as described above), it is also possible to propagate permissions that control the access to the asset instance's profiles.
Profile permissions of the root asset of a composite asset can be propagated to the other components if the components have the same type as the root asset. This restriction arises because different asset types can have different sets of profiles, whereas assets of the same type have the same set of profiles.
Propagation of profile permissions is activated when you select the check box Propagate profile permissions in the asset's Permissions tab. This checkbox can only be selected if you have also selected the check box Propagate Permissions to dependent objects.