When you finish creating an issue by clicking on the Create button, you get redirected to the issue page, which looks like this:
This page not only shows information about the issue but also gives you all the instruments that you need to work with it.
The content of the issue, including its attributes, is located inside the big yellow block. In the top-right corner of this block, you can see the Previous and Next links. These links can be used to navigate through the issue list (for example, issue search results).
Below the yellow block, you can see the History section. It lists changes that were made to the issue and includes information on what exactly was changed, when it was changed, and by whom.
The sidebar of this page contains the contextual links (most of which will be reviewed in Chapter 5, Managing Projects) and the Watchers section, which can be used to manage the watchers of the issue.
In the previous screenshot, at the bottom of the yellow box, you can see two empty sections. The first of them is Subtasks. If you click on the Add link to the right of its label, you will be redirected to the new issue form, with the Parent task field pre-filled with the current issue number. In this way, you can create subtasks.
But, what are subtasks? Let's check out the following screenshot:
These are the subtasks that I added to my demo project. Besides being shown in the hierarchical structure, subtasks (usually) also define the priority (the highest priority of all subtasks is used), the start date (the earliest date is used), the due date (the latest date is used), the done ratio (calculated), and the estimated time (the sum is used) for the parent task. Certainly, Redmine does not allow you to specify values for these attributes of the parent task explicitly in such cases. However, this behavior can be changed from the Issue tracking tab of the global Settings page (we will review this tab later in this chapter).
Tip
The Smart Issues Sort plugin
Redmine has an issue with displaying the hierarchical tree of tasks, as it strictly keeps the sort order. In the previous screenshot, the hierarchy is preserved because issues are sorted by numbers and they are sequential. So, to have the hierarchical tree of issues, you need either to keep their numbers sequential by creating them in the appropriate order, or to use the Smart Issues Sort plugin by Vitaly Klimov, which resolves this issue:
Another empty section at the bottom of the yellow box on the issue page is Related issues. If you click on the Add link of this section, the following form will appear inside it:
This form can be used to associate other issues with the current one. For each such related issue, you should specify the type of relation.
Some of these types not only describe the relation but also provide implicit functionality. So, let's review each of them:
- Related to: This is one of the relation types that does not do anything. You can use it just to mark that the issues are somehow related. Also, this type is selected by default, as it can be seen in the previous screenshot.
- Duplicates: This type tells Redmine that the current issue should be closed when the related one is closed.
- Duplicated by: This type is the inverse of Duplicates. It forces the related issue to be closed when the current one is closed.
- Blocks: This type does not allow the related issue to be closed until the current one is open.
- Blocked by: This type is the inverse of Blocks. It tells Redmine to prevent the closure of the current issue until the related one is open.
- Precedes: This type forces the start date of the related issue to follow the due date (plus an optional delay in days) of the current one.
- Follows: This type is the inverse of Precedes. It forces the start date of the current issue to follow the due date (plus an optional delay in days) of the related one.
- Copied to: This type marks the related issue as a copy of the current one and is automatically set by Redmine when an issue is copied. This relation type should not be set manually.
- Copied from: This type marks the current issue as a copy of the related one and is automatically set by Redmine when an issue is copied. This relation type should not be set manually either.
As the Precedes and Follows relation types support an additional delay, the relation form includes the special Delay field for these two types, as shown in the following screenshot:
In this field, you can specify the number of days that should pass between the due date of the preceding issue and the start date of the following issue.
Note
The described implicit functionality can become a source of confusion. Thus, if two duplicate issues are assigned to different employees, closing one of them will lead to closure of another one, and this can come as a surprise to the assignee of the latter. Also, adding a preceding issue with empty start and due dates can lead to clearing the dates of the following issue. For these reasons, you should be careful while managing issue relations.
When added, related issues are shown in the Related issues section, as you can see in this screenshot:
