Issues are the fundamental medium for collaborating on ideas and planning work in GitLab.
The GitLab issue tracker is an advanced tool for collaboratively developing ideas, solving problems, and planning work.
Issues can allow sharing and discussion of proposals before, and during, their implementation between:
- You and your team.
- Outside collaborators.
They can also be used for a variety of other purposes, customized to your needs and workflow.
Issues are always associated with a specific project, but if you have multiple projects in a group, you can also view all the issues collectively at the group level.
Common use cases include:
- Discussing the implementation of a new idea
- Tracking tasks and work status
- Accepting feature proposals, questions, support requests, or bug reports
- Elaborating on new code implementations
See also Always start a discussion with an issue.
Parts of an issue
Issues contain a variety of content and metadata, enabling a large range of flexibility in how they are used. Each issue can contain the following attributes, though not all items must be set.
Viewing and managing issues
While you can view and manage the full details of an issue on the issue page, you can also work with multiple issues at a time using the Issues List, Issue Boards, Issue references, and Epics(PREMIUM).
Key actions for Issues include:
On the Issues List, you can view all issues in the current project, or from multiple projects when opening the Issues List from the higher-level group context. Filter the issue list with a search query, including specific metadata, such as label(s), assignees(s), status, and more. From this view, you can also make certain changes in bulk to the displayed issues.
For more information, see the Issue Data and Actions page for a rundown of all the fields and information in an issue.
You can sort a list of issues in several ways, for example by issue creation date, milestone due date. For more information, see the Sorting and Ordering Issue Lists page.
Issue boards are Kanban boards with columns that display issues based on their labels or their assignees**(PREMIUM)**. They offer the flexibility to manage issues using highly customizable workflows.
You can reorder issues within a column. If you drag an issue card to another column, its associated label or assignee will change to match that of the new column. The entire board can also be filtered to only include issues from a certain milestone or an overarching label.
With Design Management, you can upload design assets to issues and view them all together to easily share and collaborate with your team.
Epics let you manage your portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones.
Related issues (STARTER)
You can mark two issues as related, so that when viewing one, the other is always listed in its Related Issues section. This can help display important context, such as past work, dependencies, or duplicates.
You can crosslink issues by referencing an issue from another issue or merge request by including its URL or ID. The referenced issue displays a message in the Activity stream about the reference, with a link to the other issue or MR.
Introduced in GitLab 11.6.
To prevent duplication of issues for the same topic, GitLab searches for similar issues when new issues are being created.
When typing in the title in the New Issue page, GitLab searches titles and descriptions across all issues the user has access to in the current project. Up to five similar issues, sorted by most recently updated, are displayed below the title box. Note that this feature requires GraphQL to be enabled.
Health status (ULTIMATE)
To help you track the status of your issues, you can assign a status to each issue to flag work that's progressing as planned or needs attention to keep on schedule:
- On track (green)
- Needs attention (amber)
- At risk (red)
You can then see issue statuses on the Epic tree.
Disable issue health status
This feature comes with the
:save_issuable_health_status feature flag enabled by default. However, in some cases
this feature is incompatible with old configuration. To turn off the feature while configuration is
migrated, ask a GitLab administrator with Rails console access to run the following command: