Track bugs and issues and manage your software development projects with JIRA
Before we delve into the deep end of how JIRA handles security, let's first take a look at how user memberships are managed.
In any information system, for users to access the system, they need to have an account. In JIRA, each user needs to have their own user account for them to access the data. Each user is identified by their username, which cannot be changed after account creation.
JIRA administrators can manage users centrally from the User Browser.
From the User Browser, you will be able to see a list of all the users in JIRA. The User Browser also provides you with search capabilities. You will be able to search for users that fit criteria such as username, full name, e-mail address, and group association. By default, the results will be paginated to show twenty users per page, but you can change this setting to show up to one hundred users per page. When dealing with large deployments with hundreds of users, these options will become extremely useful to quickly find the users you need to manage.
Other than the ability for you to effectively search for users, the User Browser also serves as the portal for you to add new users to JIRA, and manage user's group/role associations.
There are two ways for new user accounts to be created in JIRA. The first option is to have centralized management where only the JIRA administrators can create and maintain user accounts. This option is applicable to most private JIRA instances designed to be used by an organization's internal users.
The second option is to allow users to sign up for accounts themselves; this is most useful when you are running a public JIRA instance where manually creating user accounts is not feasible because of the volume of work. We will be looking at how to enable public signup options in later sections, for now we will examine how administrators can create user accounts manually.
If your JIRA instance is public, for example, as a public support system, creating user accounts individually as explained earlier will become a very demanding job for your administrator. For this type of JIRA setup, you can enable public signup to allow users create accounts themselves.
To enable public signup in JIRA:
Once you have set JIRA to run in the Public mode, users will be able to sign up and create their own accounts from the login page.
As we will see in the later section, Global Permissions, once a user has signed up for a new account, he/she will automatically join groups with JIRA users' global permission.
If you have set JIRA to run in Private mode, only the administrator will be able to create new accounts.
If you are running JIRA in Public mode, you run the risk of having automated spam bots creating user accounts on your system. To counter this, JIRA provides the CAPCHA service where potential users will be required to type in a word represented in an image into a text field. To enable CAPTCHA service:
Now when someone tries to sign up for an account, JIRA will present them with a CAPTCHA challenge that must be verified before the account is created.
Groups are a common way of managing users in any information system. A group often represents a collection of users, usually based on their positions and responsibilities within the organization. In JIRA, groups provide an effective way to apply configuration settings to users, such as permissions and notifications.
Groups are global in JIRA, which is something that should not be confused with Project Roles (discussed later). This means if you belong to the jira-administrators group, you will always be in that group regardless of which project you are accessing. We will see in later sections how this is different from project roles and their significance.
One important point to keep in mind is that a group association does not cascade in JIRA. For example, just because a user is in the jira-developers group does not mean he/she will have the privileges of the jira-users group.
JIRA administrators can manage groups centrally from the Group Browser.
Similar to the User Browser, the Group Browser allows you to search, add, and configure groups within JIRA.
JIRA comes with three default groups. These groups are created automatically when you install JIRA.
Out of the three groups, jira-administrators and jira-users are of most significance. As we will see later in this chapter, by default, jira-administrators are given the global permission to administer JIRA while jira-users are only given permission to access JIRA. You can, as we will learn, change this default behavior so your custom groups have the same permissions.
Other than the three groups that come by default with JIRA, you can create your own groups. It is important to note that once you have created a group, you cannot change its name. Make sure you think about the name of the group carefully before you create it.
After a group has been created, it is empty and will have no members. It will also have no configuration settings such as the permissions applied.
It is often that people move around within an organization, and JIRA needs to be kept up-to-date with the movement.
From the Group Browser, there are two ways to manage group membership. The first option is to manage the membership on per-group level, and the second option is to manage several groups at the same time. Both options are actually very similar, so we will be covering both at the same time.
To manage individual groups:
To manage multiple groups:
You will notice that both options will take you the same page. The difference is if you have chosen the individual group option, JIRA will auto select the group to update, and if you have chosen the bulk edit option, no groups will be selected. However, regardless of which option you have chosen, you can still select one or all of the groups to apply your changes to.
To update the membership in one or more groups:
If a group has become redundant, you can remove it from JIRA.
Once you have removed the group, it will automatically remove all the users who previously belonged to it.
As we 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.
Similar to users and groups, project roles are maintained centrally 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.
To access the Project Role Browser:
The list of project roles is managed by the JIRA administrator. As an administrator, you can create new role types which can then be used by project administrators for their projects.
To create a new project role:
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.
Existing project roles can be deleted if they are no longer used.
As new projects are created in JIRA, often those projects share a similar security requirement. It becomes desirable to have default members assigned to the project roles when new projects are created.
For example, by default, users in the jira-administrators group will have the Administrators project role. This increases the efficiency of 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.
From 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 group setup. Users can be useful when you have exceptional cases, such as a lead developer who should have the Developers role in all software development projects.
To add a default user/group for the project role:
Once added, any new project 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.
Default members is an efficient way for JIRA administrators to assign project role members automatically without having to manually manage it for each new project as they come in. After a project has been created, it becomes the responsibility of the project administrator to maintain the project's role membership, which we will be looking at in the next section.
JIRA allows you to assign default members to projects when they are created. This might be sufficient for most projects when they start, but changes will often need to be made due to staff movements throughout the project life cycle. It is possible for the JIRA administrator to continue maintaining each project's membership, but it can easily become an overwhelming task. 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 Administrators Projects permission. By default, members of the Administrators project role will have this permission. We will see how to manage JIRA's permissions in the later sections.
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.
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. This way, project role members are maintained separately for each project.