The main purpose of the workflow is to control which issue status can be set for the issue in certain conditions. Thus, instead of using the Open status after In Progress (for example, if the issue was returned), you may want to use the special Reopened status. For this, you can allow the Open status to be set only after the New one and allow the Reopened status after In Progress. These are the things that can be configured under the Status transitions tab.

Issue status transitions can be configured per role and tracker, which are to be chosen using the Role and Tracker fields correspondingly (see the preceding screenshot). If the status transitions are similar for several roles and/or trackers, you can use the plus icon () to convert the field into a multiselect mode.

Some issue statuses may be not used by certain trackers (for example, the Fixed status would not be needed for the Feature tracker), so to simplify the form, Redmine skips such issue statuses by default. However, we still need a way to configure new statuses, which of course won't be used by any tracker yet. So, to show all the available issue statuses, you can uncheck the Only display statuses that are used by this tracker checkbox.

After clicking the Edit button, we get the following form:

In the left-hand side column, you can see the initial issue status, and in the rows, you can see possible target statuses. In other words, this table allows you to decide whether the status in the left-hand side column can be changed to other statuses in the row. If the checkbox is checked, the change can be made.

For user convenience, the background color of the cell, the checkbox of which was initially selected, is green here. In this way, you can check what was modified before submitting your changes.

If several roles or trackers are selected and the issue transition is not the same for all the combinations of them, Redmine will use the select box instead, as shown in this screenshot:

The form for issue transitions is divided into three blocks. The top block contains the common configuration, while the other two blocks, which are collapsed by default, can optionally contain modifications to the common configuration. The common configuration applies to all users of the current role and to all issues of the tracker. The next block is for cases when the user is the author of the issue (that is, the issue was created by this particular user). And the last one applies to cases when the issue is or was previously assigned to the user.

There is no need to copy the common configuration into other blocks, as other blocks can only enable issue status transitions. Disabled transitions are just ignored there.

The Fields permissions tab can be used to make certain issue fields read-only or to require them for some trackers. This tab uses the same form as Status transitions.

Clicking on the Edit button opens the form shown in the following screenshot:

Each select box in this form allows you to choose the Read-only option. If this option is chosen for a field, a user of the corresponding role won't be able to change the value of this field, provided the issue is of the corresponding tracker.

Issue fields that are required by default are marked with a red asterisk () in this table. Fields that are not required have the additional Required option. If this option is selected for a field, it will become required for users of the corresponding role, provided the issue is of the corresponding tracker.

Normally, when you mark a field as read-only or required, you want it to remain the same for all subsequent issue statuses in the particular row. If this is the case, you can use the link to copy the option to the columns on the right-hand side.

Also, as with issue status transitions, if fields permissions were set before, they are loaded with the backgrounds of the corresponding cells changed to the appropriate colors, as shown here:

Here, the gray stands for the Read-only option, and the red stands for the Required option.

The workflow page also has the contextual menu with links in the top-right corner, which we did not review. I skipped this menu because at that moment you did not know enough to understand what they are for.

The Copy link of this menu can be used to quickly copy a configuration from one role and tracker pair to another. This feature can be used if, for example, you have mistakenly changed a wrong pair. Anyway, as you have seen, the workflow configuration is quite complex and utilizes many checkboxes and select boxes, so many of you may find this feature useful for different purposes. This link opens the page that is shown in the following screenshot:

As you can see, for user convenience, this form allows the selection of several target trackers and roles at a time.

The Summary link redirects to a page that contains the aggregate data. This page is shown in the following screenshot:

These numbers represent the number of enabled issue transitions per role and tracker, and the cross icon means that no transitions are enabled. While these numbers are generally useless, each number and cross icon is a link that redirects to the corresponding form. So, the summary page can be used for quick access to transitions editing.