User and group management

Permission control in QuickBuild is implemented through group and user. The administrator creates groups and give them certain permissions. All users in the group will have the permissions defined for the group. A single user can be associated with multiple groups, and the user permission is the union of all permissions of all groups.
Groups are managed through menu Administration/Group Management as indicated below:
Unable to render embedded object: File (group1.png) not found.

Users are managed through menu Administration/User Management as indicated below:
Unable to render embedded object: File (user1.png) not found.

The administrator account created when you initially setup the server will not able to be deleted, however you can follow the account link to edit its details including changing password.

Configuration visibility and permission

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 define related groups. Assume the full configuration tree is like below:

Unable to render embedded object: File (visibility1.png) not found.

Now you want that developers can only access the subtree under project1. To do this, you define a developer group and add an authorization for configuration root/project1, and specify proper permissions. When login as developer, the resulting dashboard will look like:

Unable to render embedded object: File (visibility2.png) not found.

As you can see, the authorization entry for root/project1 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 happens when an user is member of multiple groups.

When determine permissions for a particular configuration, QuickBuild will look for the nearest ancestor configuration that is authorized in the group, and use the corresponding permissions. For example, if authrozations of the developer group is defined as:

Unable to render embedded object: File (permission1.png) not found.

Developers will only have "ACCESS_BUILDS" permission for configuration root/project1/2.0/nightly as the authorization entry root/project1/2.0 is the nearest ancestor, and the permissions defined in this authorization entry will be used for configuration root/project1/2.0/nightly.
When a user is member of multiple groups, configuration permissions is the union of permissions that is 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. The tester group has below authorizations:

Unable to render embedded object: File (permission2.png) not found.

User madaha will have permission "ACCESS_BUILDS, RUN_BUILD" for configuration root/project1/2.0/nightly as the permissions derived from developer group is "ACCESS_BUILDS", and the permissions derived from tester group is "ACCESS_BUILDS, RUN_BUILD". The union of these two set of permissions will be "ACCESS_BUILDS, RUN_BUILD".

Enable anonymous access to server

Anonymous access to server can be enabled by creating a group named "anonymous" as below. Permission of anonymous users are determined by permission of this "anonymous" group:

Unable to render embedded object: File (group2.png) not found.

Enable user self-register

Users can self register their accounts if a group named "register" exists. All self-registered users are initially a member of the "register" group, and the administrator can change groups of these users laterly.

Allow users to connect their agent to QuickBuild server

User agent is used to collect uncommited changes from user's computer in case of running of [proof build]. To do this, you will need to check the "Allow Agent" option when define the associated group for the user.