Roles and permissions

Define what project members can do in Redmine by configuring roles and their associated permissions.

Roles control what actions a user can perform within a project. Each project member is assigned one or more roles, and the role determines the full set of allowed actions.

Built-in roles

Redmine includes two built-in system roles that cannot be deleted:

Non member

Applied to authenticated users who are not members of a project. Relevant only for public projects. Controls read-only access such as viewing issues and wiki pages.

Anonymous

Applied to unauthenticated visitors. Relevant only for public projects. Should have minimal or no permissions.

In addition to the system roles, Redmine ships with three default named roles: Manager, Developer, and Reporter. These are regular roles that can be edited, renamed, or deleted.

Default role	Typical use
Manager	Full control over a project — can create and edit issues, manage members, close versions, and configure project settings.
Developer	Can create and edit issues, log time, and manage their assigned work. Cannot change project settings.
Reporter	Can create issues and add notes. Cannot edit issues created by others or manage anything else.

The Manager, Developer, and Reporter roles are only defaults. Your Redmine instance may have different roles if an administrator has changed them.

Creating a custom role

1. Open the Roles list

   Go to Administration → Roles and permissions and click New role.

2. Name the role

   Enter a unique name (maximum 255 characters). Role names are case-sensitive.

3. Configure visibility options

   Set three visibility scopes for the role:

   • Issues visibility — all (all issues in the project), default (public issues and own private issues), or own (only issues created by or assigned to the user).
   • Time entries visibility — all or own.
   • Users visibility — all (all active users) or members_of_visible_projects (only users sharing a visible project).
4. Select permissions

   Check the permissions this role should have. Permissions are grouped by module.

5. Save

   Click Create.

Permission matrix

Permissions are grouped by functional area. The table below lists the key permission symbols used internally and what they control.

Project management

Permission	What it controls
edit_project	Change project settings, name, description, and modules.
select_project_modules	Enable or disable project modules (Issues, Wiki, Forums, etc.).
manage_members	Add, remove, and change roles of project members.
manage_versions	Create, edit, and delete project versions.
manage_categories	Create, edit, and delete issue categories.
close_project	Archive and close the project.
delete_project	Permanently delete the project.

Issue tracking

Permission	What it controls
view_issues	View issues in the project.
add_issues	Create new issues.
edit_issues	Edit any issue’s fields (subject, description, status, etc.).
copy_issues	Copy existing issues to the same or another project.
manage_issue_relations	Add and remove issue relations (blocks, duplicates, etc.).
manage_subtasks	Create and manage parent/child issue relationships.
set_issues_private	Mark issues as private (visible only to members with sufficient permissions).
set_own_issues_private	Mark issues the user created as private.
add_issue_notes	Add notes to existing issues without editing the issue itself.
edit_issue_notes	Edit notes written by others.
edit_own_issue_notes	Edit notes the user wrote.
view_private_notes	See private notes on issues.
set_notes_private	Mark a note as private when adding it.
delete_issues	Permanently delete issues.
import_issues	Import issues from a CSV file.

Time tracking

Permission	What it controls
log_time	Add time entries to issues.
view_time_entries	View time entries (subject to time entries visibility setting).
edit_time_entries	Edit any time entry in the project.
edit_own_time_entries	Edit only the user’s own time entries.
manage_project_activities	Override the global time entry activities for this project.
log_time_for_other_users	Submit time entries on behalf of another user.

Wiki and documents

Permission	What it controls
view_wiki_pages	View wiki pages.
export_wiki_pages	Export wiki pages to PDF, HTML, or plain text.
edit_wiki_pages	Create and edit wiki pages.
rename_wiki_pages	Rename wiki pages.
delete_wiki_pages	Delete wiki pages.
view_documents	View documents attached to the project.
add_documents	Upload new documents.
edit_documents	Edit document metadata.
delete_documents	Delete documents.

Repository and source code

Permission	What it controls
browse_repository	View source code in the repository browser.
view_changesets	See commit history and changesets.
commit_access	Grants write access to the repository when Redmine manages access control.

Tracker-specific permissions

The permissions view_issues, add_issues, and edit_issues can be restricted to specific trackers. For example, a role can be allowed to add issues only for the Bug tracker but not the Feature tracker.

This is configured on the role’s edit page under Permissions → Issues by unchecking “For all trackers” and selecting individual trackers.

Issues visibility

The Issues visibility setting on a role determines which issues the role can see:

Value	Behavior
all	Can see all issues in any project where the role is assigned.
default	Can see public issues and any private issues they created or are assigned to.
own	Can only see issues they created or are assigned to.

Managed roles

A role can be configured to manage other roles. When All roles managed is enabled, users with this role can add and remove any role for project members. When specific managed roles are listed, the user can only assign those listed roles.

This is configured per role under Administration → Roles and permissions → (role name) → Managed roles.

Copying a role

When creating a new role, you can base it on an existing one by clicking Copy next to a role in the list. Permissions and workflow rules are duplicated; the name and position are not.