As we have discussed, an issue in JIRA can be anything in the real world to represent a problem domain. It can be a software bug, a help desk ticket, or a customer request. But, what does an issue look like in JIRA? How does JIRA achieve this level of flexibility and still present it in a consistent manner?
Let's first take a look at an issue in JIRA. The following screenshot shows a typical example of an issue and breaks it down into more digestible sections, followed by an explanation of each of the highlighted sections in a table. This view is often called the Issue Summary or the View Issue page:
These sections are described in the following table:
|
Section |
Description |
|---|---|
|
It shows the project the issue belongs to. The issue key is the unique identifier of the current issue. This section acts as a breadcrumb for easy navigation. | |
|
It is a brief summary of the issue. | |
|
These are the various view options for the issue. The options include XML, Excel, and Word. | |
|
These are the operations that users can perform on the issue, such as edit, assign, and comment. These are covered in the later sections of this chapter. | |
|
These are the workflow transitions available. Workflow will be covered in Chapter 6, Workflows and Business Processes. | |
|
This section lists the issue fields such as issue type and priority. Custom fields are also displayed in this section. Fields will be covered in Chapter 4, Field Management. | |
|
This section is specific for user-type fields such as assignee and reporter. Fields will be covered in Chapter 4, Field Management. | |
|
This section is specific for date-type fields such as Create and Due date. Fields will be covered in Chapter 4, Field Management. | |
|
These are the options that allow users to vote and watch an issue. | |
|
These list all the attachments on an issue. | |
|
These list all the comments that are visible to the current user. |