Configuration Visibility and Permissions

Version 1 by Robin Shen
on Aug 05, 2009 02:51.

 
compared with
Version 2 by Robin Shen
on Aug 05, 2009 02:52.

Changes from 2 to 3 >>
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

 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 following:
  
 !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, and the permissions associated with this authorization entry will be used.
 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, then 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_.
  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_.