As you have seen, groups are collections of users and are applied globally. JIRA offers another way of grouping users, which is applied on the project level only:
Project role |
Description |
---|---|
Administrators |
This project role represents the administrator of the project (for example, project manager). |
Developers |
This project role represents the developer of the project. |
Users |
This project role represents the user of the project (for example, tester). |
Similar to users and groups, project roles are maintained by the JIRA administrator through the Project Role Browser. There is a slight difference, however, since project roles are specific to projects, JIRA administrators only define what roles are available in JIRA and their default members. Each project's administrators (discussed in later sections) can further define each role's membership for their own projects, overriding the default assignment. We will first look at what JIRA administrators can control through the Project Role Browser and then look at how project administrators can fine-tune the membership assignment later. Perform the following steps to access the Project Role Browser:
As an administrator, you can create new role types, which can then be used by project administrators for their projects. Perform the following steps to create a new project role type:
Once you have added a new project role, it will appear for all the projects.
You can update a project role's name and description, as follows:
Existing project roles can be deleted if they are no longer used, as follows:
As new projects are created in JIRA, it will often happen that those projects will share a similar security requirement. So, it becomes desirable to have default members assigned to the project roles when new projects are created.
Default members are an efficient way for JIRA administrators to assign project role members automatically, without having to manually manage each new project as they come in.
For example, by default, users in the jira-administrators
group will have the Administrators project role. This increases the efficiency of the security setup by creating a baseline for new projects, but also offers the flexibility to allow modifications to the default setup to cater for unique requirements.
Perform the following steps to set default members for a project role:
In this page, you will see all the default members assigned to the selected project role. Default members can be logically assigned project roles based on the group setup. Users can be useful when you have exceptional cases, such as a lead developer that should have the Developers role in all software development projects.
Perform the following steps to add a default user/group for the project role:
Once added, any new projects created will have the specified users/groups assigned to the project role. It is important to note that after you have set default members, only new projects will have the settings applied. Existing projects will not retrospectively have the default members applied.
As you have seen, JIRA allows you to assign default members to projects when they are created. This might be sufficient for most projects when they start. Changes will often need to be made due to staff movements throughout the project life cycle. While it is possible for the JIRA administrator to continue maintaining each project's membership, it can easily become an overwhelming task, and in most cases, since project roles are specific to each project, it makes sense to delegate this responsibility to the owner of each project.
In JIRA, an owner of a project is someone with the Administer Projects permission. By default, members of the Administrators' project role will have this permission. We will see in a later section how to manage permissions in JIRA.
As a project administrator, you will be able to assign members to the various project roles for your project. You can assign roles from the project administration page, as follows:
The users and groups assigned to the project role will be for the current project only. You will have to reconfigure the members again for other projects. In this way, project role members are maintained separately for each project: