Development Path ACLs
Development path, or variant, ACLs follow the same model as a project ACL; except they are applied to a variant on a development path.
|
|
If the global default for Dev Path Inheritance is set to false and no variant ACL is defined, a variant Sandbox inherits its permissions from the top level, global mks:si ACL.
If the global default for Dev Path Inheritance is changed to true and no variant ACL is defined, the variant Sandbox inherits its permissions from the master project in the tree.
The Dev Path Inheritance policy set for a specific development path overrides the global Dev Path Inheritance policy.
|
To create a variant Sandbox, users require explicit permissions specified through a variant ACL, unless the user already has all permissions, such as an administrator has.
Using the CLI, you can set the permissions for a variant project before creating the actual development path. From the Integrity Lifecycle Manager administration client, you must create the variant project in the Integrity Lifecycle Manager client before creating the development path ACLs.
|
|
When creating a development path ACL, remember to assign the same name to the variant project so that the principals and permissions can be applied by the system.
|
You can copy ACLs from the mainline or development path to another development path that exists on the same project. The Copy Project Permissions can be launched from the right-click menu in the > permissions view in the Integrity Lifecycle Manager administration client. You can also copy ACLs from the Integrity Lifecycle Manager administration client menu bar > . As the permissions view does not provide the required project context, you need to select a project in the Open Project Wizard.
For more information, see
“Copy Project Permissions”.
Development Path ACLs and Permission Inheritance
Working with development path ACLs allows you to provide a finer level of control over your projects. For example, you could grant permissions to individual developers allowing them to modify only the variant projects they work on. Permissions on the main trunk could then be restricted to limit the types of operations performed there.
For a development path, the default behavior is to inherit all permissions from the master project. If the master project does not specifically allow or deny a permission, the variant project ultimately inherits its permissions from the mks:si ACL.
When first creating a variant, you are presented with the same set of permissions as the master project. You can further customize the variant ACLs as required for your work environment. Whenever you attempt to change permissions on an inherited ACL, you are prompted to confirm your choice.
You can enable or disable permission inheritance behavior both at the global level or for each individual development path ACL you create.
When permission inheritance is set to true, permissions are inherited from the master project in the tree. When permission inheritance is set to false, permissions are inherited from the top level mks:si ACL.
|
Permission Inheritance
|
Inherited From
|
|
True
|
master project and then from mks:si
|
|
False
|
mks:si
|
|
|
When development path permission inheritance is set to true, the Integrity Lifecycle Manager server queries the ACL database for the user’s access permissions, working upwards through the variant project tree name space structure. If no permissions are found explicitly allowing or denying, the search resumes from the equivalent starting point on the master project tree.
When development path permission inheritance is set to false, the Integrity Lifecycle Manager server queries the ACL database for the user’s access permissions, working upwards through the variant project tree name space structure. If no permissions are found explicitly allowing or denying, the search resumes in the mks:si ACL.
|
The global default behavior for controlling development path inheritance is set in the Integrity view under the Permissions section. When you choose Global and select > , the policy for DevPathInheritACL is changed from the default true to false allowing development path permissions to be inherited from the project ACL.
To set permission inheritance for an individual development path, highlight the target ACL and select > from the main menu. To inherit permissions from the master project, choose True. To inherit permissions from the mks:si ACL, choose False. To reset to the default behavior set for the global policy, choose Use Global Policy.
|
|
When creating a development path ACL, you cannot grant the CreateDevPath permission to any principal. The CreateDevPath permission can only be allowed when working in reference to the top level mks:si ACL or project ACL.
|
