Let's now see what configuration options are available in Redmine for issue tracking.
Everything you have read in this chapter so far can actually be disabled for a project with just one click. However, I'm not sure who might need to do this and why... Anyway, just in case you got Redmine with issue tracking disabled by someone else or whatever, let's discuss how Issue tracking can be enabled (or disabled) for a project.
Open the project settings by selecting the Settings tab in the Projects menu. Then select the Modules tab of the Settings page. Make sure that the Issue tracking module is checked, as shown in this screenshot:
If this checkbox is unchecked, issue tracking won't be available for the project.
Remember that we skipped several tabs of the Settings page in the Administration menu in the previous chapter? It's now time to discuss one of them—Issue tracking:
So let's go through the available settings:
- By default, you can mark an issue as related to another one only if both are in the same project. But if projects hosted on Redmine are somehow related, it can be useful to link issues from different projects. So, to make this possible, you need to enable the Allow cross-project issue relations setting.
- If the Link issues on copy setting is set to Yes, the copied issue will be added to the original one as related using the Copied to relation type, and the original issue will be added as a Copied from issue to the copy. If this setting is set to Ask (which is the default), Redmine will ask you what to do each time you copy an issue.
- By default, subtasks are required to be from any subproject of the topmost project at any level. This is controlled by the Allow cross-project subtasks setting, which is set to With project tree by default. To allow subtasks from any projects, you need to use With all projects for this setting. To allow subtasks from any subproject or any parent project (but not their other subprojects), use With project hierarchy. Finally, to allow subtasks only from subprojects, use With subprojects.
- By default, you can't assign an issue to more than one user. However, by enabling the Allow issue assignment to groups setting, you can make it possible to assign an issue to a group. Groups can be created and edited on the Groups page of the Administration menu.
- There were times when the first thing I did after creating a new issue was removing the current date from its Start date field. So, I was quite happy to see that the Use current date as start date for new issues setting was added to Redmine. Disable this setting unless you are sure that all your users will create issues on the day on which these issues should start, or unless you just need any value in this field for some reason.
- The Display subprojects issues on main projects by default setting is an option that can lead to confusion. If your subprojects are highly related to their parent projects, you may want to enable this setting to have issues of subprojects included in issue lists of their parent projects. But remember that having forgotten about this feature or not having noticed it, users may eventually navigate to a subproject and then wonder where the other issues have disappeared. Also, some users may wonder why certain settings (such as issue categories and custom fields) that are configured for the parent project do not work for some issues.
- Despite what it may sound like, the Calculate the issue done ratio with setting is actually about choosing between the manual and automatic done ratios.
If this option is set to Use the issue status, the % Done issue field disappears from the issue edit form, so there will be no way to set the done ratio explicitly. Also, for the automatic done ratio to work, you must configure the done ratios for your issue statuses on the Issue statuses page of the Administration menu, as shown in this screenshot (otherwise, the done ratio will always be empty):
After switching to the automatic done ratio (or updating the done ratios of the issue statuses), you should click on the Update issue done ratios link in the top-right corner of the Issue statuses page to recalculate all done ratios for all issues.
Finally, if the Calculate the issue done ratio with setting is set to Use the issue field (the default value), users will need to specify the done ratio on their own.
- Using the Non-working days setting you can select which week days should not be considered to be working. This setting affects the Gantt chart and calculation of issue date properties.
- Two other settings in the main block, which are Issues export limit and Maximum number of items displayed on the gantt chart, can be used to limit the number of issues that can be exported to a CSV file and included into a Gantt chart correspondingly.
- The Parent tasks attributes block contains settings that allow you to control how the Start date, Due date, Priority, and % Done fields are determined for parent tasks (that is, issues that have subtasks). If these settings are set to Calculated from subtasks, the values of the corresponding fields of parent tasks are calculated as described in the Subtasks subsection of The issue page section of this chapter. If the Independent of subtask value is selected, these fields are to be set manually.
- The last block, which is Default columns displayed on the issue list, can be used to select different default columns for issue lists on your Redmine installation. Thus, instead of making each user select the columns that he/she wants to see in the issue list, you should determine (in a way that is out of scope here) which columns are most commonly needed by your users and select them on this page.
- In the last block, using the Totals setting you can also choose to show grand total counts of the estimated and/or spent time of the included issues in the issue list by default.
To check other settings that are related to issues, we need to go to the Repositories tab of the Settings page in the Administration menu. We will speak about the part of this page which is shown in the following screenshot:
The Referencing keywords setting holds the words that, if found in commit messages before an issue number (# plus a number), generate a reference for the appropriate issue. In practice, however, you most likely will want to specify an asterisk (*) here, which means that no special word is required for a reference to be created (only the issue ID is enough). Also, such a reference can be created for several issues at a time. To do this, you need to list these issues in the commit message separated by commas, spaces, or ampersands (&).
But, what is a reference? Let's check out the issue shown in the following screenshot:
The gray block that you can see under the Associated revisions title contains an issue reference. It was created by an SVN commit command like this (the Fixing keywords field was set to *, that is, an asterisk):
$ svn commit -m "Fixed that wiki start page can't be changed (#11085)."
An issue can have any number of such references.
Special issue references can also be used to modify the status and/or the done ratio of the issue. As it can be complicated to find suitable universal words for all available trackers, Redmine allows you to specify different Fixing keywords for different trackers for such references. As you might have guessed, this can be done in the table at the bottom of the settings page.
Let's review a sample: say, if Applied status was set to Closed, % Done was set to 100%, and Fixing keywords included closes, the following SVN command would close the issue and set its done ratio to 100%:
$ svn commit -m "Fixed that wiki start page can't be changed (closes #11085)."
Finally, the Allow issues of all the other projects to be referenced and fixed setting decides whether users will be able to reference and fix issues of projects to which the repository does not belong. This is unlikely to be needed, unless all your projects are highly related.