User authorization

User authorization functionality is achieved by assigning users to proper groups. You can create several groups; with each group has its own set of permissions. Multiple groups can be assigned to a single user, which means this user has all permissions set in those groups. You can create new group or editing existing group through Groups menu of Administration tab. While creating new groups, the special name anonymous is reserved for anonymous users, that is, all anonymous users will be assigned to this group automatically, thus get permissions set in this group. Basically there are two type of permission you need to set for a group: queues and configurations.

Set queue permissions

By specifying authorized queues for a group, you allow users of that group be able to bind those queues to configurations they have permission to edit. This is useful, for example, if you want that only one build can be performed at the same time (in order to save CPU cycle) for some projects. In order to do achieve this, you create a queue with only one working thread, and create a group with only this queue authorized, and assign users from those projects to this group. In this way, users of that group can only use that particular queue, which will streamline all triggered builds, instead of run them simultaneously.

Set configuration permissions

By specifying configuration permissions for a group, you authorize users of that group be able to access certain configurations in the system, and what operations they can do on those configurations. This is done by choosing desired configuration subtree, and set appropriate permission on that tree; then all configurations under choosed subtree will get specified permission. There are three types of permission you can set:

View

Be able to view and access artifacts of all configurations under the choosed subtree.

Build

Be able to build all configurations under all configurations under the choosed subtree.

Admin

Be able to administrate all configurations under the choosed subtree.

For a particular configuration, if it is affected by multiple permission lines, the actual permission will be the maxium possible permission. In order to demonstrate this, let's assume that configuration permissions are set as below:

Table 6.1. Configuration permissions

Configuration subtreePermission
root.department1Admin
root.department1.project1View

Although second permission line states that all configurations under root.department1.project1 have View permission, but because the first line states that all configurations under root.department1 have Admin permission, configuration root.department1.project1 will take Admin permission which is the maximum possible permission. This rule also applies when determine permission for a configuration that is affected by multiple groups assigned to the same user.