In this section, we are going to discuss topics intended solely for Redmine project managers, that is, users who have permissions that allow them to edit some project attributes (or other attributes that are somehow related to projects). It's easy to check whether you are among of them—if you see the Settings tab in the project menu, it means you can manage this project (or at least some of its attributes).
So, let's move on to this tab:
Here, you see the settings of the project. As you can see, these settings also use tabs. Let's discuss them.
In this section, we will skip the Issue category tab, as it has been discussed in the previous chapter. We will also skip the Repositories and Forums tabs as they have been reviewed along with the appropriate modules. Also, we won't review the Activities (time tracking) tab because it's going to be reviewed in Chapter 8, Time Tracking.
The first tab of the settings menu that gets opened by default and which you can see in the previous screenshot is the Information tab. Generally, it contains the same fields that can be found in the new project form.
The only new field in this form is Default version. Using this field you can select a project version which will be used as the target version for new issues by default. Thus, you can create a version with the name, for example, Next major release and select it here to make all new issues assigned to it by default.
Elements of the second tab, which is Modules, can be seen on the new project form as well. These fields allow you to choose modules for the project, as shown in the following screenshot:
On this tab, you can enable (or disable) modules anytime—for example, when you are ready to fill out their pages.
The next tab is Members. Check it out in this screenshot:
This is the page where you can manage the members of the project.
If you click on the New member link, it will open the following dialog:
As you can see, in this dialog, you can choose several users and several roles at the same time (a user can have multiple roles in a project). Notice that the user list also contains groups, for example, Redmine developers. In this way, you can add all members of a group as members of the project.
The search field can be used to filter users and groups by parts of their names. Thus, if I type Jean in this field, the list will contain only Jean-Philippe Lang and Jean-Baptiste Barth. The green check mark (
) near the Roles label can be used to quickly select or unselect all listed roles.
Maybe you have noticed that the user/group list contains only those users who are not members of the project yet. To assign a different role to an existing member of the project, you need to use the Edit link in the member list. When you do this, the following form is revealed in the member's row:
After you have saved the changes or clicked on the Cancel link, this form disappears and the member's row gets updated accordingly.
Now, let's see what's under the Versions tab:
This is where we manage the versions of the project.
Project versioning is extremely important for software projects. Thus in Redmine, project versions can be referenced by issues (and you can specify in which version the issue is going to be resolved), project files can be uploaded for a specific version, versions are shown on the roadmap, the calendar can show version dates, the Wiki syntax supports links to versions (we will speak about this later), custom fields support the Version type, and so on. In other words, by ignoring versions, you literally limit the functionality that is available for your project in Redmine.
However, it's also important to manage versions correctly. Let's check out the new version form that becomes available when you click on the New version link. This form is shown in the following screenshot:
Here, Name is usually a version number but also can be just a string (such as Second edition in my case). However, it's not recommended to use strings for this field, as you can end up with a broken order of versions (which can be corrected by using the Date field though, which we'll discuss soon). This is also the only required field.
The Description field is optional and should contain a very short description of what is special about this version, for example, Maintenance release. This description is going to be shown on the roadmap and the version page.
The value of the Status field can be open, locked, or closed. Here, "locked" means that the version is in a frozen state and all associated issues have been fixed but not yet tested. Also, you can't change the Target version of an issue to a locked or closed version.
The Wiki page field contains the name of the Wiki page that describes changes that were made in this version. The content of this page will be embedded in the version's section on the roadmap and the version page. Such a Wiki page can contain, for example, the changelog for the version.
When you save the version, the value of the Wiki page field turns into the link that points to the associated Wiki page (see the Second-edition link in the first screenshot of this subsection). The same Wiki page is also going to be referenced by the Edit associated Wiki page: link on the version page.
The Date field is not just for showing the due date of the release. Thus, the value of this field affects the order of versions, as shown in the following screenshot:
Usually, more recent versions are shown at the bottom of the list, but if a version has Date, it gets moved to the top. So, other versions appear as newer. In other words, an empty Date field is treated as distant time in the future.
Additionally, the value of the Date field is used to determine whether the version is completed, but we will get back to this a little later in this subsection.
The last field of this form—the Sharing field—accepts the following values:
- Not shared: This version won't be shared. This means that it will be available only for this project. This is the default value.
- With subprojects: This version will be available for all subprojects of this project down to any nesting level.
- With project hierarchy: This version will be available for all subprojects as well as all parent projects of the current one, but not for other subprojects of parent projects. To be able to choose this option, the user must have the Manage versions permission for the parent project as well.
- With project tree: This version will be available for all subprojects of the current project as well as all subprojects of all parent projects of the current one. Moreover, it will be available for all parent projects of the current project. As with the previous option, to be able to select this option, the user must have the Manage versions permission for the parent project.
- With all projects: This version will be shared among all projects that are available on this Redmine installation! As this is a very wide sharing method, this option is available only for administrators. Certainly, you have to be extremely careful when choosing this option.
Any of these fields can be modified later by clicking on the Edit link next to the version in the version list. This link opens the same form that we have just reviewed. Additionally, you can remove the version by clicking on the Delete link.
There is, however, one more thing related to versions that we have not discussed yet. It's the Close completed versions link, which can be seen on the right-hand side under the version list (see the first screenshot in this subsection).
A completed version can be considered to be a not-yet-closed version that nonetheless meets all the conditions to be closed. Remember that when we were reviewing the Date field, I promised to get back to it? That's here! If the value of the Date field is in the past and there are no more open issues for the version, such a version is considered to have been completed. So, using the Close completed versions link, you can close all such versions with just one click.
The last tab of the project's Settings page that we will review in this section is Wiki, which is shown here:
In this tab, you can specify the landing page for the project's Wiki, which is Wiki by default. In other words, using this form, you can change the Wiki page that is opened when you click on the Wiki tab of the project menu. Thus, you may need to do this if you have prepared a special page for the next release of your project.
The Delete link in the bottom-right corner can be used to delete the start page. However, it not only deletes the Wiki page itself but also removes the name of the landing page in the form! So after this, the Wiki tab of the project menu (not of the project's Settings page) disappears, as the start page no longer exists. Actually, I believe that a more gracious way to do the same is to just disable the Wiki module.