The Project Administration interface is where project administrators can manage the settings and configurations for their projects. For example, you can change the project's name, select what issue types will be available for the project, and manage a list of components within the project. As we have seen earlier, any user with the Administer Projects permission for a given project will be able to access this interface.
- Browse to the JIRA Administration interface.
- Bring down the Projects menu from the top navigation bar and select the Projects menu item.
- Select a project from the list. This will take you to the Project Administration interface:
From the Project Administration page, you will be able to perform the following key operations:
- Update project details, such as project name, description, and avatar
- Manage what users see when working on the project, such as issue types, fields, and screens
- Control permission settings and notifications
- Manage the list of available components and versions
JIRA 5 has a brand new Project Administration layout. Compared to the previous JIRA versions, this new layout is more organized, and is much easier for project administrators to find out the current project configuration settings. One of the major differences, especially when compared to JIRA 3 and the earlier versions of JIRA 4, is that all settings are broken into their own individual tabs, and nicely grouped together in terms of relevance. By default, there are five tabs on the Project Administration page.
The first group consists of a single tab, the Summary tab. On this tab, JIRA displays a single page view on all the current configuration settings for the project. Not all the settings will have their own tabs. So those that do not have a tab will also be shown here, on the Summary tab.
On this tab, you can edit the project's general information, such as its name and description, set the project's category, and delete the project.
The Components tab is where project administrators can manage the components for their projects. Components can be thought of as subsections that make up the full project. In a software development project, components can be various modules that the final product comprises.
In JIRA, components are project specific. This means that components from one project cannot be used in a different project. This also allows each project to maintain its own sets of components. As we will see in the later chapters, there are configuration items in JIRA where the values are shared across all projects.
A component has four pieces of information:
|
Field |
Description |
|---|---|
|
This is a unique name for the component. | |
|
This is an optional description to offer more explanation on what the component is for. | |
|
This is an optional field where you can select a single user as the lead for the component. For example, in a software project, this can be the main developer for the component. | |
|
This tells JIRA when an issue is created without the assignee being selected. If the issue has a component, then JIRA will auto assign the issue to the selected default assignee. |
One of the changes in JIRA 5 is that you can manage your project's components all on one tab, including create, edit, and update:
Unlike some older versions of JIRA, you can create new components directly from the Components tab:
- Browse to the Components tab for the target project.
- Provide a unique name for the component. JIRA will let you know if the name is already taken.
- Provide a short description for the new component.
- Select a user to be the lead of the component. Just start typing and JIRA will prompt you with options that meet the criteria.
- Click on Add to create the new component.
Once you have created the new component, it will be added to the list of existing components. When a component is first created, it will be placed at the top of the list. If you refresh the page, the list will then be ordered alphabetically.
As mentioned earlier, the Components tab in JIRA 5 allows you to directly edit and delete the existing components. You will be able to edit specific fields of each component, without jumping through different pages.
If you want to edit a component's name, all you need to do is hover your mouse over the component's name and you will see that the name field is highlighted. Click on the name to make the field editable, make your changes, and click on Update. If you want to delete a component, all you have to do is to click on the Delete button next to the target component.
As explained in the preceding section, one of the useful features of components is the ability to assign a default assignee to each individual component. This means, when a user creates an issue and does not select an assignee, JIRA will be able to automatically assign the issue based on the component selected. This is a very powerful feature where in an organization, members of various teams often do not know each other. So when it comes to assigning issues at creation time, it is difficult to decide who to assign it to. With this feature, it can be set up so that the lead of the component becomes the default assignee and the issues raised can then be delegated to other members of the team.
For our demo project, each of our supported systems has a system expert, which is represented as the lead of the respective component. When the business user logs a ticket and selects a component, the ticket will go directly to the lead. This setup is also flexible enough. If the user knows who to best assign the ticket to, he or she can directly assign the ticket to the member of the team and the automatic assignment will not take place.
If the issue has more than one component with a default assignee, the assignee for the first component in alphabetical order will be used.
Like the Components tab, the Versions tab allows project administrators to manage versions for their projects. Versions serve as milestones for a project. In project management, versions represent points in time. While for projects that are not product-oriented, versions may seem to be something that is less relevant, versions can still be invaluable at managing and tracking the progress of issues and work.
As with components, versions also have a number of fields:
|
Field |
Description |
|---|---|
|
Name |
This is a unique name for the version. |
|
Description |
This is an optional description to offer more explanation on what the version is for. |
|
Release Date |
This is an optional date that will be marked as the scheduled date to release the version. Versions that are not released according to the release date will have the date highlighted in red. |
Very similar to the Components tab, in JIRA 5, you can create, update, and delete versions all on the single tab. This makes managing large number of versions a much simpler job.
Creating new versions is as simple as providing the necessary details for the new version and hitting the Add button:
- Browse to the Versions tab for the target project.
- Provide a unique name for the version (for example,
1.1.0, v2.3). JIRA will let you know if the name is already taken. - Provide a short description for the new version.
- Select the date for when the version will be released by using the date picker.
- Click on Add to create the new version.
Unlike components, versions will not be ordered automatically by JIRA, so you will have to manually maintain the order. In the older versions, project managers will have to manually click on the up and down arrow keys repeatedly to move the version to the correct location. In JIRA 5, all you have to do is hover your mouse pointer over to the left of the version, and you will be able to drag the version up and down the list.
Just like managing components, the Versions tab of JIRA 5 uses the in-place editing feature. So, you just need to click on the field of the version to editor update the value and click on Update.
When you hover over a version, you will notice that there is a little action icon to the right. If you click on that, you will have the options to do the following:
|
Option |
Description |
|---|---|
|
This will mark the version as released; meaning it is completed or shipped. When you release a version, JIRA will automatically check to make sure that all the issues are completed for the selected version. If these are incomplete, you will be prompted to either ignore those issues or push them to a different version. If the version has already been released, it will change to Unrelease. | |
|
This is similar to the Release option, but it also performs a build via Atlassian Bamboo, if there are any software codes. The version will only be released if the build is successful. This option is not available if the version is already released. | |
|
This will mark the version as archived; meaning that the version is stored away until further notice. When a version is archived, you cannot release or delete it until it is unarchived. | |
|
This will delete the version from JIRA. Again, JIRA will search for issues that are related to this version and prompt you if you would like to move these issues to a different version. |
This is in fact an add-on that is now bundled with JIRA 5.1. If you are familiar with web browsers such as FireFox, you are probably familiar with add-ons. As we will be covering add-ons in Chapter 10, General Administration, all you need to know for now is that they are sometimes referred to as plugins, and they are small applications that can be installed on top of JIRA to provide additional functionalities.
So, if you do not have the Issue Collectors add-on installed, you will not see this tab. The The Issue Collector add-on lets you create and add dialog boxes that can be added to any websites you may have, so users can provide their feedback and these will be captured automatically in JIRA. We will cover the Issue Collectors add-on in Chapter 10, General Administration, when we introduce a number of other useful add-ons that will make JIRA work harder for you.
There are a number of other tabs on the Project Administration interface. We will not get into the details for these tabs, as they will each be covered in their own chapters later. We will, however, take a quick tour to look at what each tab does:
|
Tab |
Description |
|---|---|
|
This controls the types of issue that users can create for the project. For example, this may include Bugs, Improvements, and Tasks. Issue Types will be covered in Chapter 3, Issue Management. | |
|
This controls the workflow issues that we will go through. Workflows consist of a series of steps that usually mimic the existing processes that are in place for the organization. Workflows will be covered in Chapter 6, Workflows and Business Processes. | |
|
Screens are what users see when they create and edit issues in JIRA. Screens will be covered in Chapter 5, Screen Management. | |
|
Fields are what JIRA uses to capture data from users when they create issues. JIRA comes with a set of default fields, and the JIRA administrator is able to add additional fields as needed. Fields will be covered in Chapter 4, Field Management. | |
|
The project administrators can define roles in the project and assign users to them. These roles can then be used to control permissions and notifications. People will be covered in Chapter 8, Securing JIRA. | |
|
As we have already seen, permissions define who can perform certain tasks or have access in JIRA. Permissions will be covered in Chapter 8, Securing JIRA. | |
|
JIRA allows users to control who can view the issues they have created, by selecting the issue security level. Issue security will be covered in Chapter 8, Securing JIRA. | |
|
JIRA has the ability to send out e-mail notifications when certain events occur. For example, when an issue is updated, JIRA can send out an e-mail, alerting all users who participate on the issue of the change. Notifications will be covered in Chapter 7, E-mails and Notifications. |