Everything you have read in this chapter until now can actually be disabled for a project with just one click. I'm not sure, however, who and why may need to do this. Anyway just in case you got Redmine with issue tracking disabled by someone else or by default, here is how to enable (or disable) the issue tracking for a project.

Open the project's settings by clicking on the Settings tab in the project's menu and then click on the Modules tab in the Settings menu. Make sure the Issue tracking module is checked as shown in the following screenshot:

Unchecking the Issues tracking checkbox disables issue tracking for that project.

In the previous chapter, we skipped two tabs in Administration | Settings, there I promised to explain them in the next two chapters. So it's the time to learn the Issue tracking tab. The following screenshot shows the various options available under the Issue tracking tab:

Let's go through the available options:

By default, you can add a related issue to an issue, but only if both are in the same project. If projects hosted on Redmine are related, it can be useful to be able to add related issues from different projects. To make this possible, check the Allow cross-project issue relations checkbox.

By default, you can't assign an issue to more than one user. By checking the Allow issue assignment to groups checkbox, you make it possible to assign an issue to a group. Groups can be created and edited in Administration | Groups.

I discovered that in most cases the first thing I do after creating a new issue is to clear the current date from the Start date field. So I'm quite happy that the Use current date as start date for new issues option exists. Unless you are sure all users will be creating issues on the day these issues should start, or you need any value in the Start date field, uncheck this option.

The Display subprojects issues on main projects by default option is unfortunately an option that can lead to confusion. If all of your subprojects are related deeply to parent projects you may want to enable this option to have subprojects issues listed along with issues in parent projects. However, having forgot or not having noticed this feature, users may eventually navigate to a subproject and then wonder where the other issues disappear to, or may wonder why certain settings (for example, issue categories, custom fields) configured for the parent project (and not for subprojects) do not work for some issues.

Despite what it may sound like, the Calculate the issue done ratio with option actually allows you to choose between the manually done ratio and the automatically done ration calculation.

If this option is set to Use the issue status, the Done issue field will disappear from the issue edit form and there will be no way to set the done ratio explicitly. For the automatic done ratio to work, you must configure done ratios for your issue statuses in Administration | Issue statuses. Otherwise issue done ratio will always be zero percent:

After switching to the automatic done ratio calculation you can click on the Update issue done ratios link to recalculate all done ratios.

If the Calculate the issue done ratio with option is set to Use the issue field, users should specify the issue done ratio by themselves. But unfortunately in practice they often don't. For this reason, perhaps, the Use the issue status value, described earlier, was added and you should consider using it if the done ratio value is important for you.

The last option I would like to mention is the Default columns displayed on the issue list. Instead of making users select columns they want to see in the issue list, you should determine (in some way which is out of scope here) which columns are most common and select them on this page.

In case you are already bored with the repository integration topics, let's see a really interesting way of integration.

We'll speak about settings available in Administration | Settings | Repositories:

The Referencing keywords option specifies the words which, if found in commit messages before an issue number (# plus a number), produce issue references. You can specify several words separated by commas for this field. In commit messages, there can also be several issues listed after the words separated by commas (as well as by spaces or ampersands (&)). In practise, most likely you will want to put an asterisk (*) here which means that no special word is required for a reference to be created.

But what is a reference? Let's check the issue shown in the following screenshot:

The block you see under the Associated revisions title is an issue reference which was created by a SVN commit command like (The Fixing keywords field was set to "*" (asterisk)):

$ svn commit -m "Fixed that wiki start page can't be changed (#11085)."

An issue can be referenced any number of times. The words specified in the Fixing keywords field can also change issue statuses and done ratios. All you need to do is choose which status and what done ratio to set. Unfortunately, you can specify only one status and one done ratio.

For example, if the Applied status option was set to Closed, the % Done was set to 100%, and the Fixing keywords option 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)."

The Allow issues of all the other projects to be referenced and fixed option controls whether you can reference and fix issues in other projects from the repository of another project. This is unlikely to be needed unless all your projects are deeply related.