QuickBuild organizes configurations into a hierarchy tree. You can selectively expose portions of the tree to certain group of users by adding authorizations for certain configurations when defining related groups. Let's assume a full configuration tree like below:
!visibility1.png!
Now you want that developers can only access the subtree under _root/componentA_. To do this, you define a developer group, add an authorization for configuration _root/componentA_, and specify proper permissions. When logged in as developer, the resulting dashboard will look like this:
!visibility2.png!
As you can see, the authorization entry for _root/componentA_ exposes corresponding subtree to members of the group. If multiple authorization entries exist for the group, the resulting visible subtree will be a union of all subtrees rooted at each authorized configuration. Subtree union also applies when a user is a member of multiple groups.
When determining permissions for a particular configuration, QuickBuild will look for the nearest ancestor configuration that is authorized in the group, and uses the corresponding permissions. For example, if authorizations of the developer group is defined as:
!permission1.png!
Developers will only have _RUN_BUILD_ permission for configuration _root/componentA/2.0/QA_ as the authorization entry _root/componentA/2.0_ is the nearest ancestor.
When a user is member of multiple groups, configuration permissions consist of the union of permissions that are calculated separately for each group using algorithm described above. For example, if the user _madaha_ is also a member of group _tester_ besides being member of _developer_ group mentioned above, and the _tester_ group has following authorizations:
!permission2.png!
User _madaha_ will have permission _RUN_BUILD_ and _PROMOTE_BUILD_ for configuration _root/componentA/2.0/QA_ as the permissions derived from _developer_ group is _RUN_BUILD_, and the permissions derived from _tester_ group is _RUN_BUILDS_ and _PROMOTE_BUILD_. The union of these two sets of permissions will be _RUN_BUILD, PROMOTE_BUILD_.
!visibility1.png!
Now you want that developers can only access the subtree under _root/componentA_. To do this, you define a developer group, add an authorization for configuration _root/componentA_, and specify proper permissions. When logged in as developer, the resulting dashboard will look like this:
!visibility2.png!
As you can see, the authorization entry for _root/componentA_ exposes corresponding subtree to members of the group. If multiple authorization entries exist for the group, the resulting visible subtree will be a union of all subtrees rooted at each authorized configuration. Subtree union also applies when a user is a member of multiple groups.
When determining permissions for a particular configuration, QuickBuild will look for the nearest ancestor configuration that is authorized in the group, and uses the corresponding permissions. For example, if authorizations of the developer group is defined as:
!permission1.png!
Developers will only have _RUN_BUILD_ permission for configuration _root/componentA/2.0/QA_ as the authorization entry _root/componentA/2.0_ is the nearest ancestor.
When a user is member of multiple groups, configuration permissions consist of the union of permissions that are calculated separately for each group using algorithm described above. For example, if the user _madaha_ is also a member of group _tester_ besides being member of _developer_ group mentioned above, and the _tester_ group has following authorizations:
!permission2.png!
User _madaha_ will have permission _RUN_BUILD_ and _PROMOTE_BUILD_ for configuration _root/componentA/2.0/QA_ as the permissions derived from _developer_ group is _RUN_BUILD_, and the permissions derived from _tester_ group is _RUN_BUILDS_ and _PROMOTE_BUILD_. The union of these two sets of permissions will be _RUN_BUILD, PROMOTE_BUILD_.