You might expect to see the very major part of the administration area discussed in a single chapter, but that's not going to happen. In this book, I'm trying to review Redmine by functional parts and not by web interface sections. However, this is the chapter which discusses many sections of the administration area, as they are related to the access control and the workflow.
On the other hand, you might wonder why the access control and the workflow are reviewed in a single chapter? In terms of Redmine, the workflow is a set of rules for the issue life cycle, in particular, for issue status change. These rules take into account member roles and trackers (issue types). And these are, actually, member roles that define access permissions.
We will not just review many sections of the administration area but will also discuss them and their influence on the system functionality. So, this chapter is intended for administrators, however, it will be interesting for project managers as this chapter explains how to configure Redmine to ease and optimize the development process, in particular, the issue life cycle. Other users may also find this chapter useful, as here, they can learn what permissions they need to gain access to certain types of functionality.
In this chapter, we will cover the following topics:
- Roles
- Trackers
- Issue statuses
- Workflow
- Modifying workflow
- Practical example
Redmine roles define which permissions users have in projects. As you already know users can be added to projects as members. To do this, we select a user and a role. So, here, a role is a kind of membership type, that's why roles are also often called member roles.
Roles are system wide and can be managed in Administration | Roles and permissions, as shown in the following screenshot:
The order of roles—how it is presented on this page—is important as the same order is used for the forms, with which users select member roles. Therefore, this order can be changed using the arrows in the Sort column. Normally, you will want the order to be from the most privileged at the top to the less privileged at the bottom.
The italicized Non member and Anonymous roles are virtual ones, meaning they do not really exist in the database and thus, cannot be renamed, removed, their order cannot be changed, and so on (permissions can be changed for them though). The Non member role is used for users who are not members of the project and the Anonymous role is used for unauthorized (not logged in) users.
A role can be edited by clicking on the role name in this list. When you do this, you get the following form:
The Issues can be assigned to this role option controls if the role is assignable, that is, if members of this role appear in the value list for the Assignee issue field. This can be useful, for example, for a reporter or customer role, which you unlikely want to make assignable.
The Issues visibility option specifies which issues should be visible for members of this role. It accepts the following values:
- All issues: All issues, including private ones, are visible to the user.
- All non private issues: All issues, except private ones, are visible to the user.
- Issues created by or assigned to the user: Only issues, which are owned by the user, are visible. This means that an issue should be created by the user or assigned to the user to be visible.
However, the most interesting and important part of this form can be found under the Permissions label.
Generally, Redmine access control is built on permissions, and all such permissions (if editable) can be found in this form. Thus, when a plugin adds a permission, it is also added here.
The permission list is split into blocks (Project, Forums, and so on); each block corresponds to a project module. Thus, when a plugin adds a project module and permissions for this module, you will see new block and new permissions in this block here. An exception is the Project block, which is not related to a project module and defines permissions for the project itself.
Redmine users can be divided into three types—unauthorized (not logged in) users (presented by the Anonymous role), authorized users but not members of the project (presented by the Non member role), and project members (other roles). Generally, permissions are defined for these three types and not all permissions are available for all the types. Thus, Redmine can't permit project creation to unauthorized users. Most of the permissions are defined for project members though.
So let's discuss each block and permission now.
The Project block, as has been mentioned earlier, holds permissions for the project. If a plugin provides any system permissions for accessing objects outside projects, for example, blog posts provided by the Redmine Blog plugin, such permissions will appear in this block as well. Refer to the following permissions:
- Create project permission is available for registered users and controls if the user is allowed to create new projects.
As we know, to have permissions, the user should be associated with the role, and to be associated with the role, the user should be added to the project. So, how users can have the Create project permission if they have not been added to any project yet? The first project should be always created by the administrator. Normally, this will be the general company project named, for example, after the company name. You can add users, who you want to allow creating projects, to this project. Alternatively you can, of course, grant the Create project permission to the Non member role.
- Edit project permission controls if the project member can change project properties located under the Information tab in the project settings.
- Close/reopen the project permission controls if the project member is able to close or reopen the project, which can be done on the project overview page.
- Select project modules permission controls if the project member can manage project modules under the Modules tab in the project settings.
- Manage members permission controls if the project member is allowed to manage project membership under the Members tab in the project settings.
- Manage versions permission controls if the project member is able to add, edit, and delete project versions using the Versions tab in the project settings.
- Create subprojects permission controls if the project member is able to add subprojects to the project. Such project members should also have the Create project permission.
The Forums block contains permissions for Redmine message boards, which are provided by the Forums project module and are available under the Forums tab in the project menu. Refer to the following permissions:
- Manage forums permission controls if the project member has access to the Forums tab in the project settings, where message boards can be created, edited, or removed.
- Post messages permission specifies if the user can add messages to the project message board. This also includes whether the user can reply to the message. This permission is available to all users including not logged-in ones.
- Edit messages permission controls if the project member can modify forum messages, including ones posted by other users. This permission will be useful for forum moderators.
- Edit own messages permission controls if the user can modify own forum messages. Granting this permission, you should always remember that the original text can be copied into replies as a quote, so this permission won't help in such cases. Generally, the Edit own messages permission, that is, editing, should be used only to correct typos. Certainly, this permission is available only to logged-in users.
- Delete messages permission specifies if the project member can delete forum messages, including messages of other users. This permission can be useful for spam moderation.
- Delete own messages permission controls if the user can delete own forum messages. Like with the Edit own messages permission when granting this one, you should consider that the message text can be copied into replies, or replies may be based on the message. This permission is available to registered users.
The Calendar block contains permissions that define access control for the calendar, which is available under the Calendar tab, if the Calendar project module is enabled:
- View calendar permission is the only permission in this block. This permission controls if the user has access to the Calendar tab of the project menu. Please notice that if the user does not have access to issues, the calendar will be empty or will contain only versions' due dates (if they were specified). This permission can be specified for all users, including not logged in ones.
The Documents block holds permissions for accessing the Documents tab of the project menu, which is provided by the Documents project module. Refer to the following permissions:
- Manage documents permission controls if the user can create, edit, or delete documents. Users with this permission will also be able to attach files to documents as well as to remove attachments.
- View documents permission controls if the user can see documents and download their attachments. This permission can be granted to any user, including not logged in ones.
The Files block contains permissions for accessing the Files tab of the project menu. This tab is available only if the Files project module is enabled. Refer to the following permissions:
- Manage files permission specifies if the user is able to add or remove project files.
- View files permission is needed for the user to be able to download project files. This permission can be granted to any user, including not logged in ones. However, project files will still not be available for non members if the project is private.
The Gantt block holds permissions for accessing the Gantt tab of the project menu, which contains the Gantt chart. This tab is available only if the Gantt project module is enabled.
The Issue tracking block holds permissions related to issue tracking. This is the largest and perhaps, the most important block. Permissions in this block influence not only the content under the Issues tab of the project menu but also every page, where issues are involved, and these are almost all project pages including the overview page, roadmap, calendar, gantt, and more. Issue-tracking functionality is provided by the Issue tracking project module. Refer to the following permissions:
- Manage issue categories permission controls if the project member can add, edit, or delete issue categories, which can be done under the Issue categories tab in the project settings menu—in addition, project members with this permission can add issue categories within the issue form.
- View issues permission is the most important permission as it controls if the user can see issues, that is, without this permission, the user won't see any issues in the project. So, in most cases, you will want this permission to be set. The permission is available for all users, including not logged in ones.
- Add issues permission controls if the user is able to add new issues. This permission is also available for not logged in users.
- Edit issues permission controls if the user is able to edit issues, including adding attachments. This permission is available for all users, including not logged in ones.
- Manage issue relations permission controls if the user can add or remove related issues, which can be done on the issue page. This permission is also available for not logged in users.
- Manage subtasks permission specifies if the user is able to add child issues to the issue, which can be done on the issue page. Such user should also have the Add issues permission. Like the latter, this permission is also available for not logged in users.
- Set issues public or private permission controls if the user is able to modify the Private flag of the issue. If this permission or the Set own issues public or private permission is set, the user will also be able to see the value of this flag in the issue list (by enabling the appropriate column), and filter the issue list by the value of this flag. The permission is available for not logged in users as well (for example, if an anonymous user reports a critical security issue).
- Set own issues public or private permission controls if the user is able to modify the Private flag of the issue, which was created by this user. Users with this permission will also be able to see the value of this flag in the issue list and filter the issue list by this value. The permission is available for all registered users.
- Add notes permission specifies if the user can comment issues. This permission also allows adding attachments to the issue. The permission is available to all users, including not logged in ones.
- Edit notes permission controls if the user can edit issue comments. This permission, however, does not allow to remove files that were attached to the issue along with the comment. The permission is available to all registered users and is useful for moderation.
- Edit own notes permission allows the user to modify own comments, that is, the comments that were created by this user. This permission, however, won't allow the user to remove files that were attached along with such comments. Permissions like this one should be used only for correcting typos, as the original text from the comment can be used in replies as a quote. The permission is available for all registered users.
- View private notes permission specifies if issue private notes are visible to the user. The permission is available only to project members.
- Set notes as private permission controls if the user can post issue private notes. Note that without the View private notes permission, such user won't be able to see own private notes. The permission is available only to project members.
- Move issues permission is used to determine whether the issue can be moved between projects by the user. In addition to this permission, such user must have the Add issues permission in both—the source and the target projects. Certainly, the permission is available for non members as well.
- Delete issues permission controls whether the issue can be deleted by the project member.
Tip
However, in my opinion, issues should never be deleted. Each issue is assigned a unique ID and can be referenced from many places. When you delete an issue, its ID becomes unused. Besides, while most of associated objects are deleted as well, the issue can be referenced by links from, for example, Wiki pages which will become dead. Instead issues can and should be closed.
- Manage public queries permission specifies if the project member can add, modify, or delete public custom queries. Custom queries is a very powerful feature, and public custom queries can make the project more customer-friendly. However, too many public queries for the project can make this feature ineffective. So, this permission should be granted to users who know what to do with it.
- Save queries permission indicates if the user can save custom queries. Custom queries are available for all users, including not logged in ones, but only logged in users can save queries (if this permission is set).
- View watchers list permission specifies if the user can see who is watching the issue. This permission is available for all users, including not logged in ones.
- Add watchers permission is available for all users as well. This permission controls who is able to add watchers to the issue. For anonymous users, it can be useful if the user knows who is likely interested in the issue. However, when granting this permission, you should consider that watchers may get e-mail notifications on changes in watched issues. In other words, you are granting the permission for sending many e-mails to project members.
- Delete watchers permission specifies who will be able to remove watchers from the issue. This permission is available for all users, including not logged in ones as well. But, you will unlikely want to grant this permission to anyone besides project managers. The user, who is watching the issue, may expect to be notified about changes in the issue, so I don't think it's good if someone besides this user removes him/her from watchers.
The News block contains permissions for accessing news, which are available under the News tab in the project menu—if the News project module is enabled for the project. News are visible to everyone, including not logged in users, and there is no permission to change this (besides disabling the News project module). Refer to these permissions:
- Manage news permission specifies if the project member is able to post, edit, and delete news in the project. The user with this permission will be also able to remove news comments (which is useful for spam moderation).
- Comment news permission controls who can comment news. This permission is available to all users, including not logged in ones. But, I would not recommend granting this permission to anonymous users, as in my practice, news are where spam goes most often.
The Repository block holds permissions, which control access to repositories. Some of these permissions apply not only to Redmine (as a web application) but also to SCM servers, if the advanced repository integration has been configured (see Chapter 3, Configuring Redmine). Repositories are available under the Repository tab in the project menu if the Repository project module is enabled. Refer to the following permissions:
- Manage repository permission allows the project member to add, edit, and delete repositories. This permission also allows you to modify committer associations.
- Browse repository permission controls if the user can browse the content of the repository. If the SCM server has been configured to support the advanced integration, this permission also controls access to the repository on the SCM server. The permission can be set for all users, including not logged in ones.
- View changesets permission specifies if the user has access to the repository revision list and revision pages. For full repository browse access, you should set this permission along with the Browse repository permission. The permission is available for all users, including not logged in ones.
- Commit access permission has nothing to do with Redmine itself. This permission is used by the SCM server, if the advanced integration has been configured, to determine whether the write access to the repository should be given to the user. The permission is available for all users, including not logged in ones.
- Manage related issues permission specifies if the user can add or remove issues related to the revision, which can be done on the revision page. The permission is available for all users, including not logged in ones.
The Time tracking block holds permissions used to control the access to the time tracking in the project. Refer to the following permissions:
- Log spent time permission specifies if the user is able to add time entries to the project. This also applies to the time entries added using commit messages. The permission is available to all registered users.
- View spent time permission controls if the user can see time entries of the project. This applies not only to the time report but also to the sum of spent hours on the project overview page, spent hours on the issue page, and so on. The permission can be set even to not logged in users.
- Edit time logs permission allows modifying time entries of any user in the project. This permission can be granted only to project members. Anyway, I doubt it's good to allow a user to modify time entries of other users.
- Edit own time logs permission allows the user to modify own time entries. This permission is available for all registered users.
- Manage project activities permission controls if the project member can enable or disable time-tracking activities for the project.
The Wiki block includes permissions for working with Wiki pages, which are available under the Wiki tab in the project menu (if the Wiki project module is enabled). These permissions do not apply to other Wiki syntax-enabled contents (for example, issue description).
- Manage wiki permission specifies if the project member has access to the Wiki tab in the project settings (do not confuse with the Wiki tab in the project menu). In fact, this tab allows you to specify the starting Wiki page name only.
- Rename wiki pages permission controls if the project member is able to move the Wiki page to a different parent page and/or change its name.
- Delete wiki pages permission controls if the project member is able to remove the Wiki page.
- View wiki permission is the permission which actually makes the Wiki page visible to the user. You should unset this permission if you want to hide Wiki from particular roles. The permission is available for all users, including not logged in ones.
- Export wiki pages permission controls if the user is able to export the Wiki page to PDF, HTML, or TXT. Unsetting this permission actually has no sense as users can always save the Wiki page using browser. The permission is available for all the users.
- View wiki history permission is also available for all users, including not logged in ones. As you know the Wiki page stores the history of changes, sometimes some sensitive data can get there, so it may be needed to hide previous versions of the page. This permission allows the user to see the full changes history, previous versions of pages, difference between versions, and who authored each line.
- Edit wiki pages permission specifies whether the user should be allowed to edit the Wiki page in the project. With this permission, users can also add attachments to the Wiki page. You can grant this permission to not logged in users as well. The Wiki system stores the full history of changes and allows to rollback the previous version if needed, so it's quite safe, in most cases, to grant this permission even to the Anonymous role.
- Delete attachments permission allows the user to remove attachments from the Wiki page. While Wiki stores the history of changes of the Wiki text, it does not store the attachments history, so this permission can be used to prevent removing important files by anonymous users. The permission is available to all users.
- Protect wiki pages permission controls if the project member can lock or unlock the Wiki page. Having all the project Wiki system editable by anyone, you can make some pages editable only by trusted users. All such trusted users should have this permission set (yes, the page protected by one user can be edited by another user, who has this permission as well).