Projects
Projects
A project is the top-level container in Redmine. All issues, time entries, wiki pages, forum boards, and other data belong to a project.Each project has:
- A name and a URL-safe identifier (e.g.,
my-project) - A description and optional homepage URL
- A set of enabled modules that control which features are active (see Modules below)
- A set of members, each assigned one or more roles
- A set of trackers that determine which issue types are available in the project
- A visibility setting: public (visible to all users, including anonymous visitors) or private (visible only to members)
| Status | Meaning |
|---|---|
| Active | Normal operating state. Issues can be created and updated. |
| Closed | Read-only. Issues can be viewed but not modified. |
| Archived | Hidden from project lists. All data is preserved. |
Issues
Issues
An issue is the fundamental unit of work in Redmine. It represents a bug report, a feature request, a task, a support ticket, or any other item that needs to be tracked.Every issue has:
Issues can also have subtasks (child issues). A parent issue’s done ratio can be computed from the done ratios of its children.Issues are searchable, filterable, and exportable to CSV, PDF, and Atom feeds.
- A subject (required) — a short description of the work
- A tracker — the issue type (see Trackers below)
- A status — where the issue is in its lifecycle (see Statuses below)
- A priority — urgency level (Low, Normal, High, Urgent, or Immediate by default)
- An author — the user who created the issue
- An optional assignee — the person responsible for resolving it
- Optional start date and due date
- An optional target version (milestone)
- An optional done ratio — a 0–100% completion estimate
- Optional estimated hours — planned effort
- Time entries — actual time logged against the issue
- A description and threaded notes (journal entries) recording the full history of changes
- Attachments — files uploaded to the issue
- Watchers — users who receive email notifications when the issue changes
| Relation | Meaning |
|---|---|
| Related to | General association between two issues |
| Duplicates / Duplicated by | One issue is a duplicate of another |
| Blocks / Blocked by | One issue must be resolved before another can proceed |
| Precedes / Follows | One issue must start or finish before another (with optional delay in days) |
| Copied to / Copied from | One issue was copied from another |
Trackers
Trackers
A tracker defines the type or category of an issue — for example, Bug, Feature, Task, or Support. Your administrator creates and configures trackers for the entire Redmine instance, then assigns trackers to individual projects.Trackers control:
- Which fields are shown on the issue form. Each tracker can enable or disable standard fields such as category, target version, start date, due date, estimated hours, and done ratio.
- Which custom fields are available for issues of that tracker type.
- Which workflow transitions apply (which status changes are allowed for each role).
- The default status that new issues start with.
- Whether issues of this tracker appear in the roadmap view.
Trackers are global — they are defined once and shared across all projects. However, each project chooses which trackers to enable. If a tracker you need is not available in a project, ask your administrator.
Statuses
Statuses
An issue status represents where an issue is in its lifecycle. Statuses are global and shared across all projects and trackers. Examples of typical statuses are New, In Progress, Resolved, Feedback, and Closed.Each status has:
- A name
- A closed flag — statuses marked as closed cause their issues to be counted as resolved in reports and queries
- An optional default done ratio — when an issue transitions to this status, its done ratio can be updated automatically if your administrator has enabled this option
Roles and permissions
Roles and permissions
A role is a named set of permissions that can be assigned to project members. Roles are global — defined once by an administrator and reused across all projects.Common built-in roles include Manager, Developer, and Reporter, but administrators can create any roles they need.Permissions control actions such as:
A user can hold multiple roles in the same project. Their effective permissions are the union of all their roles’ permissions.
- Viewing, creating, editing, and deleting issues
- Viewing and logging time entries
- Managing project members
- Editing wiki pages
- Adding and deleting attachments
- Managing forums and documents
| Role | Who it applies to |
|---|---|
| Non-member | Authenticated users who are not members of a (public) project |
| Anonymous | Unauthenticated visitors viewing a public project |
You cannot assign roles or manage members unless your role in the project includes the Manage members permission.
Workflows
Workflows
A workflow defines which status transitions are allowed for a given combination of tracker and role.For example, a workflow might say:
- A user with the Reporter role can move a Bug from New to Feedback, but not to Resolved.
- A user with the Developer role can move a Bug from any open status to Resolved or Closed.
- Author — the user who created the issue is allowed to make this transition regardless of their role
- Assignee — the user assigned to the issue is allowed to make this transition regardless of their role
Custom fields
Custom fields
Custom fields let administrators extend the default data model with additional attributes. They can be added to issues, projects, users, time entries, versions, and other objects.Custom field types include:
For issue custom fields, the administrator controls:
| Type | Description |
|---|---|
| Text | Single-line or multi-line text input |
| Integer | Whole number |
| Float | Decimal number |
| Date | Date picker |
| Boolean | Checkbox (yes/no) |
| List | Drop-down with administrator-defined options |
| Key/value list | Drop-down with separate internal key and display value |
| User | Selects from the project’s members |
| Version | Selects from the project’s versions |
| Link | URL field |
- Which trackers the field appears on
- Which projects the field is enabled for
- Whether the field is required
- Whether the field is searchable
- Whether the field accepts multiple values
- Which roles can see the field (if not globally visible)
Modules
Modules
Modules are the individual feature areas that can be enabled or disabled per project. Enabling a module adds it to the project’s left sidebar navigation.The available modules are:
| Module | What it provides |
|---|---|
| Issue tracking | The issue list, issue creation, and all issue management features |
| Time tracking | Time entry logging and reports |
| News | A news feed for project announcements |
| Documents | A document library with categories |
| Files | A simple file repository for project-level attachments |
| Wiki | A per-project collaborative wiki with version history |
| Repository | Source code repository browsing and changeset linking |
| Boards | Discussion forums organized by board |
| Calendar | A calendar view of issues with due dates |
| Gantt | A Gantt chart view of issues and versions |
Only project administrators and users with the Manage project permission can enable or disable modules in a project’s settings.
How the concepts fit together
Here is a quick summary of how these concepts relate:- A project groups work together and selects which modules, trackers, and members are active.
- Members are assigned roles, which determine their permissions.
- Issues belong to a project and have a tracker and a status.
- The workflow for a tracker + role combination defines which status transitions are allowed.
- Custom fields extend issues (and other objects) with additional attributes, scoped to specific trackers and projects.
Quickstart
Ready to put this into practice? Walk through logging in, creating an issue, and logging time.
Issues
Explore the full capabilities of the issue tracker.