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:
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:
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:
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:
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.