Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/redmine/redmine/llms.txt

Use this file to discover all available pages before exploring further.

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 roleTypical use
ManagerFull control over a project — can create and edit issues, manage members, close versions, and configure project settings.
DeveloperCan create and edit issues, log time, and manage their assigned work. Cannot change project settings.
ReporterCan 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 visibilityall (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 visibilityall or own.
  • Users visibilityall (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

PermissionWhat it controls
edit_projectChange project settings, name, description, and modules.
select_project_modulesEnable or disable project modules (Issues, Wiki, Forums, etc.).
manage_membersAdd, remove, and change roles of project members.
manage_versionsCreate, edit, and delete project versions.
manage_categoriesCreate, edit, and delete issue categories.
close_projectArchive and close the project.
delete_projectPermanently delete the project.

Issue tracking

PermissionWhat it controls
view_issuesView issues in the project.
add_issuesCreate new issues.
edit_issuesEdit any issue’s fields (subject, description, status, etc.).
copy_issuesCopy existing issues to the same or another project.
manage_issue_relationsAdd and remove issue relations (blocks, duplicates, etc.).
manage_subtasksCreate and manage parent/child issue relationships.
set_issues_privateMark issues as private (visible only to members with sufficient permissions).
set_own_issues_privateMark issues the user created as private.
add_issue_notesAdd notes to existing issues without editing the issue itself.
edit_issue_notesEdit notes written by others.
edit_own_issue_notesEdit notes the user wrote.
view_private_notesSee private notes on issues.
set_notes_privateMark a note as private when adding it.
delete_issuesPermanently delete issues.
import_issuesImport issues from a CSV file.

Time tracking

PermissionWhat it controls
log_timeAdd time entries to issues.
view_time_entriesView time entries (subject to time entries visibility setting).
edit_time_entriesEdit any time entry in the project.
edit_own_time_entriesEdit only the user’s own time entries.
manage_project_activitiesOverride the global time entry activities for this project.
log_time_for_other_usersSubmit time entries on behalf of another user.

Wiki and documents

PermissionWhat it controls
view_wiki_pagesView wiki pages.
export_wiki_pagesExport wiki pages to PDF, HTML, or plain text.
edit_wiki_pagesCreate and edit wiki pages.
rename_wiki_pagesRename wiki pages.
delete_wiki_pagesDelete wiki pages.
view_documentsView documents attached to the project.
add_documentsUpload new documents.
edit_documentsEdit document metadata.
delete_documentsDelete documents.

Repository and source code

PermissionWhat it controls
browse_repositoryView source code in the repository browser.
view_changesetsSee commit history and changesets.
commit_accessGrants 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:
ValueBehavior
allCan see all issues in any project where the role is assigned.
defaultCan see public issues and any private issues they created or are assigned to.
ownCan 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.

Build docs developers (and LLMs) love