Managing issues · Issues · Project · User · Help · GitLab

Managing issues · Issues · Project · User · Help · GitLab
Admin message
Due to an influx of spam, we have had to require each new account to be manually approved. Please register an account and then write an email to
accountsupport@archlinux.org
to get it approved. Sorry for the inconvenience.
Manage issues
Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
GitLab issues help you track work and collaborate with your team.
You can manage issues to:
Edit details like title, description, assignees, and metadata.
Move issues between projects while maintaining their context and history.
Close completed issues and reopen them if needed.
Use bulk editing to update multiple issues efficiently.
Track issue health status to monitor progress and identify risks.
For information on managing child items of an issue, see
child items
Edit an issue
Version history
Minimum role to edit an issue
changed
from Reporter to Planner in GitLab 17.7.
You can edit an issue's title and description.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be assigned to the issue.
To edit an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
To the right of the title, select
Edit
Edit the available fields.
Select
Save changes
Populate an issue with Issue Description Generation
Tier: Premium, Ultimate
Add-on: GitLab Duo Enterprise
Offering: GitLab.com
Status: Experiment
Model information
LLM: Anthropic
Claude 3.5 Sonnet
Not available on GitLab Duo with self-hosted models
Version history
Introduced
in GitLab 16.3 as an
experiment
Changed to require GitLab Duo add-on in GitLab 17.6 and later.
Changed to include Premium in GitLab 18.0.
Generate a detailed description for an issue based on a short summary you provide.
Watch an overview
Prerequisites:
You must belong to at least one group with the
experiment and beta features setting
enabled.
You must have permission to create an issue.
Only available for the plain text editor.
Only available when creating a new issue.
For a proposal to add support for generating descriptions when editing existing issues, see
issue 474141
To generate an issue description:
Create a new issue.
Above the
Description
field, select
GitLab Duo
{tanuki-ai}
) >
Generate issue description
Write a short description and select
Submit
The issue description is replaced with AI-generated text.
Provide feedback on this experimental feature in
issue 409844
Data usage
: When you use this feature, the text you enter is sent to
the large language model.
Bulk edit issues
Version history
Minimum role to bulk edit issues
changed
from Reporter to Planner in GitLab 17.7.
Added
more bulk editing attributes in GitLab 18.7.
You can edit multiple issues at a time when you're in a group or project.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the group or project.
To edit multiple issues at the same time:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
Select
Bulk edit
. On the right, a sidebar with editable fields appears.
Select the checkboxes next to each issue you want to edit.
From the sidebar, edit the available fields.
Select
Update selected
When bulk editing issues, you can edit the following attributes:
State (open or closed)
Status
Assignees
Labels
Health status
Notification
subscription
Confidentiality
Iteration
Milestone
Parent item
Move to another project
Move an issue
Version history
Minimum role to move an issue
changed
from Reporter to Planner in GitLab 17.7.
When you move an issue, it's closed and copied to the target project.
The original issue is not deleted. A
system note
, which indicates
where it came from and went to, is added to both issues.
Be careful when moving an issue to a project with different access rules. Before moving the issue, make sure it does not contain sensitive data.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
To move an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
) >
Move
Search for a project to move the issue to.
Select
Move
You can also use the
/move
quick action
in a comment or description.
Bulk move issues
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated
Version history
Minimum role to bulk move issues
changed
from Reporter to Planner in GitLab 17.7.
From the Work items list
Version history
Introduced
in GitLab 15.6.
You can move multiple issues at the same time when you're in a project.
You can't move tasks or test cases.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
To move multiple issues at the same time:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
Select
Bulk edit
. On the right, a sidebar with editable fields appears.
Select the checkboxes next to each issue you want to move.
From the
Move
dropdown list, select the destination project.
Select
Move items
From the Rails console
You can move all open issues from one project to another.
Prerequisites:
You must have access to the Rails console of the GitLab instance.
To do it:
Optional (but recommended).
Create a backup
before
attempting any changes in the console.
Open the
Rails console
Run the following script. Make sure to change
project
admin_user
, and
target_project
to
your values.
project
Project
find_by_full_path
'full path of the project where issues are moved from'
issues
project
issues
admin_user
User
find_by_username
'username of admin user'
# make sure user has permissions to move the issues
target_project
Project
find_by_full_path
'full path of target project where issues moved to'
issues
each
do
issue
if
issue
state
!=
"closed"
&&
issue
moved_to
nil?
Issues
::
MoveService
new
container:
project
current_user:
admin_user
).
execute
issue
target_project
else
puts
"issue with id:
#{
issue
id
and title:
#{
issue
title
was not moved"
end
end
nil
To exit the Rails console, enter
quit
Description lists and task lists
When you use ordered lists, unordered lists, or task lists in issue descriptions, you can:
Reorder all list items with drag and drop.
Delete task list items.
Convert task list items to task work items
Delete a task list item
Prerequisites:
You must have the Reporter, Developer, Maintainer, or Owner role for the project, or be the author or assignee of the issue.
In an issue description with task list items:
Hover over a task list item and select the options menu (
{ellipsis_v}
).
Select
Delete
The task list item is removed from the issue description.
Any nested task list items are moved up a nested level.
Reorder list items in the issue description
Version history
Minimum role to reorder list items in the issue description
changed
from Reporter to Planner in GitLab 17.7.
When you view an issue that has a list in the description, you can also reorder the list items.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be
assigned to the issue.
The issue's description must have an
ordered, unordered
, or
task
list.
To reorder list items, when viewing an issue:
Hover over the list item row to make the grip icon (
{grip}
) visible.
Select and hold the grip icon.
Drag the row to the new position in the list.
Release the grip icon.
Close an issue
Version history
Minimum role to close an issue
changed
from Reporter to Planner in GitLab 17.7.
When you decide that an issue is resolved or no longer needed, you can close it.
The issue is marked as closed but is not deleted.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be assigned to the issue.
To close an issue, you can either:
In an
issue board
, drag an issue card from its list into the
Closed
list.
From any other page in the GitLab UI:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
) and then
Close issue
You can also use the
/close
quick action
in a comment or description.
Reopen a closed issue
Version history
Minimum role to reopen a closed issue
changed
from Reporter to Planner in GitLab 17.7.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be assigned to the issue.
To reopen a closed issue, in the upper-right corner, select
More actions
{ellipsis_v}
) and then
Reopen issue
A reopened issue is no different from any other open issue.
You can also use the
/reopen
quick action
in a comment or description.
Closing issues automatically
You can close issues automatically by using certain words, called a
closing pattern
in a commit message or merge request description. GitLab Self-Managed administrators
can
change the default closing pattern
If a commit message or merge request description contains text matching the
closing pattern
all issues referenced in the matched text are closed when either:
The commit is pushed to a project's
default
branch
The commit or merge request is merged into the default branch.
For example, if you include
Closes #4, #6, Related to #5
in a merge request
description:
Issues
#4
and
#6
are closed automatically when the MR is merged.
Issue
#5
is marked as a
related issue
, but it's not closed automatically.
Alternatively, when you
create a merge request from an issue
it inherits the issue's milestone and labels.
For performance reasons, automatic issue closing is disabled for the very first
push from an existing repository.
User responsibility when merging
When you merge a merge request, it's your responsibility to check that it's appropriate for any targeted issues
to close. Users can include issue closing patterns in the merge request description, and also in the body
of a commit message. Closing messages in commit messages are easy to miss. In both cases, the merge request widget
shows information about the issue to close on merge:
When you merge a merge request, GitLab checks that you have permission to close the targeted issues.
In public repositories, this check is important, because external users can create both merge requests
and commits that contain closing patterns. When you are the user who merges, it's important
that you are aware of the effects the merge has on both the code and issues in your project.
When
auto-merge
is enabled for a merge request, no further changes can be made to
the list of issues that will be automatically closed.
Default closing pattern
Version history
Introduced
work item (task, objective, or key result) references in GitLab 17.3.
To automatically close an issue, use the following keywords followed by the issue reference.
Available keywords:
Close
Closes
Closed
Closing
close
closes
closed
closing
Fix
Fixes
Fixed
Fixing
fix
fixes
fixed
fixing
Resolve
Resolves
Resolved
Resolving
resolve
resolves
resolved
resolving
Implement
Implements
Implemented
Implementing
implement
implements
implemented
implementing
Available issue reference formats:
A local issue (
#123
).
A cross-project issue (
group/project#123
).
The full URL of an issue (
).
The full URL of a work item (for example, task, objective, or key result):
In a project (
).
In a group (
).
For example:
Awesome commit message
Fix #20, Fixes #21 and Closes group/otherproject#22.
This commit is also related to #17 and fixes #18, #19
and https://gitlab.example.com/group/otherproject/-/issues/23.
The previous commit message closes
#18
#19
#20
, and
#21
in the project this commit is pushed to,
as well as
#22
and
#23
in
group/otherproject
#17
is not closed as it does
not match the pattern.
You can use the closing patterns in multi-line commit messages or one-liners
done from the command line with
git commit -m
The default issue closing pattern regex:
\b
((
?:[Cc]los
?:e[sd]?|ing
\b
Ff]ix
?:e[sd]|ing
?|
\b
Rr]esolv
?:e[sd]?|ing
\b
Ii]mplement
?:s|ed|ing
)(
:?
?:
?:issues? +
?%
issue_ref
}(
?:
?:
,? +and +|
,?
([
A-Z][A-Z0-9_]+-
\d
))
Disable automatic issue closing
Version history
Changed
in GitLab 15.4: The referenced issue's project setting is checked instead of the project of the commit or merge request.
You can disable the automatic issue closing feature on a per-project basis
in the
project's settings
Prerequisites:
You must have the Maintainer or Owner role for the project.
To disable automatic issue closing:
In the top bar, select
Search or go to
and find your project.
Select
Settings
Repository
Expand
Branch defaults
Clear the
Auto-close referenced issues on default branch
checkbox.
Select
Save changes
Referenced issues are still displayed, but are not closed automatically.
Changing this setting applies only to new merge requests or commits. Already
closed issues remain as they are.
Disabling automatic issue closing only applies to issues in the project where the setting was disabled.
Merge requests and commits in this project can still close another project's issues.
Customize the issue closing pattern
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated
Prerequisites:
You must have
administrator access
to your GitLab instance.
Learn how to change the default
issue closing pattern
of your installation.
Prevent truncating descriptions with
Version history
Introduced
in GitLab 17.10.
If an issue description is long, GitLab displays only part of it.
To see the whole description, you must select
This truncation makes it easier to find other elements on the page without scrolling through lengthy text.
To change whether descriptions are truncated:
On an issue, in the upper-right corner, select
More actions
{ellipsis_v}
).
Toggle
Truncate descriptions
according to your preference.
This setting is remembered and affects all issues, tasks, epics, objectives, and key results.
Hide the right sidebar
Version history
Introduced
in GitLab 17.10.
Issue attributes are shown in a sidebar to the right of the description when space allows.
To hide the sidebar and increase space for the description:
On an issue, in the upper-right corner, select
More actions
{ellipsis_v}
).
Select
Hide sidebar
This setting is remembered and affects all issues, tasks, epics, objectives, and key results.
To show the sidebar again:
Repeat the previous steps and select
Show sidebar
Delete an issue
Version history
Required role to delete an issue
changed
from Owner to Owner or Planner in GitLab 17.7.
Prerequisites:
You must have the Planner or Owner role for a project.
To delete an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
).
Select
Delete issue
Change the issue type
Version history
Minimum role to change the issue type
changed
from Reporter to Planner in GitLab 17.7.
Changing issues to key results, objectives, and tasks
introduced
in GitLab 18.7.
Prerequisites:
You must be the issue author or have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be assigned to the issue.
To change issue type:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
).
Select
Change type
From the
Type
dropdown list select the new type:
Key result
Objective
Task
Epic (moves issue to the parent group)
For more information, see
promote an issue to an epic
Select
Change type
To promote an issue to an incident, see
promote an issue to an incident
Promote an issue to an epic
Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
Version history
Minimum role to promote an issue to an epic
changed
from Reporter to Planner in GitLab 17.7.
You can promote an issue to an
epic
in the immediate parent group.
Promoting a confidential issue to an epic creates a
confidential epic
, retaining
confidentiality.
When an issue is promoted to an epic:
An epic is created in the same group as the project of the issue.
Subscribers of the issue are notified that the epic was created.
The following issue metadata is copied to the epic:
Title, description, activity, and comment threads.
Upvotes and downvotes.
Participants.
Group labels that the issue had.
Parent item.
Prerequisites:
The project to which the issue belongs must be in a group.
You must have the Planner, Reporter, Developer, Maintainer, or Owner role the project's immediate parent group.
You must either:
Have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
Be the author of the issue.
Be assigned to the issue.
To promote an issue to an epic:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
, and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
).
Select
Change type
From the
Type
dropdown list select
Epic
Select
Change type
Alternatively, you can use the
/promote_to Epic
quick action
Promote an issue to an incident
You can use the
/promote_to Incident
quick action
to promote the issue to an
incident
Add an issue to an iteration
Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
To add an issue to an
iteration
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the right sidebar, in the
Iteration
section, select
Edit
From the dropdown list, select the iteration to add this issue to.
Select any area outside the dropdown list.
To add an issue to an iteration, you can also:
Use the
/iteration
quick action
Drag an issue into an iteration list in a board.
Bulk edit issues from the
Work items
list.
View all issues assigned to you
To view all issues assigned to you:
In the top bar, select
Search or go to
From the dropdown list, select
Issues assigned to me
Or:
To use a
keyboard shortcut
, press
Shift
In the upper-right corner, select
Assigned work items
{work-items}
).
Issue list
The issue list shows all issues in your project or group.
You can use it to view, sort, and manage issues.
To view the issue list:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
To set which attributes are shown in the
Work items
list,
configure display preferences
From the issue list, you can:
View issue details like title, assignees, labels, and milestone.
Sort issues
by various criteria.
Filter issues to find specific ones.
Edit issues individually or in bulk.
Create new issues.
The following sections describe how to work with the issue list.
Filter the list of issues
Version history
OR filtering
introduced
in GitLab 15.6
with a flag
named
or_issuable_queries
. Disabled by default.
OR filtering
enabled on GitLab.com and GitLab Self-Managed
in GitLab 15.9.
OR filtering
generally available
in GitLab 17.0. Feature flag
or_issuable_queries
removed.
Filtering the list of issues by custom status or the parent item
introduced
in GitLab 18.7.
To filter the list of issues:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
Select additional filters, operators, and values as needed.
The following filters are available:
Assignee
Author
Confidential
Contact
Health
Iteration
Label
Milestone
My reaction
Organization
Parent
Release
Search in (titles or descriptions)
Status
Subscribed
Type
Weight
Custom fields
Select or type the operator to use for filtering the attribute. The following operators are
available:
: Is
!=
: Is not one of
||
: Is one of (for Assignee, Author, Label, Type).
Works like an inclusive OR.
For example, if you filter by
Assignee is one of Sidney Jones
and
Assignee is one of Zhang Wei
GitLab shows issues where either
Sidney
Zhang
, or both of them are assignees.
Enter the text to filter the attribute by.
You can filter some attributes by
None
or
Any
Repeat this process to filter by multiple attributes. Multiple attributes are joined by a logical
AND
Press
Enter
or select the search icon (
{search}
).
Filter by title or description
To filter the list issues for text in a title or description:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
In the filter bar, type your search phrase.
In the dropdown list that appears, select
Search for this text
Press
Enter
or select the search icon (
{search}
).
Filtering issues uses
PostgreSQL full text search
to match meaningful and significant words to answer a query.
For example, if you search for
I am securing information for M&A
GitLab can return results with
securing
secured
or
information
in the title or description.
However, GitLab doesn't match the sentence or the words
am
or
M&A
exactly,
as they aren't deemed lexically meaningful or significant.
It's a limitation of PostgreSQL full text search.
Filter issues by ID
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
In the filter bar, type
followed by the issue ID.
For example, enter
#362255
to return only issue 362255.
Select
Search for this text
Press
Enter
or select the search icon (
{search}
).
Open issues in a panel
Version history
Introduced
in GitLab 17.4
with a flag
named
issues_list_drawer
. Disabled by default.
Generally available
in GitLab 18.6. Feature flag
issues_list_drawer
removed.
When you select an issue from the list or issue board, it opens in a details panel.
You can then view and edit its details without losing context of the list or board.
When using the panel:
Select an issue from the list to open it in the panel.
The panel appears on the right side of the screen.
You can edit the issue directly in the panel.
To close the panel, select the close icon (
{close}
) or press
Escape
Open an issue in full page view
To open the issue in full view:
Open the issue in a new tab. From the list of issues, either:
Right-click the issue and open it in a new browser tab.
Hold
Command
or
Control
and select the issue.
Select an issue, and from the panel, either:
In the upper-left corner, select the issue reference, for example
my_project#123
In the upper-right corner, select
Open in full page
{maximize}
).
To always open issues in full page view,
configure your list display preferences
Copy issue reference
To refer to an issue elsewhere in GitLab, you can use its full URL or a short reference, which looks like
namespace/project-name#123
, where
namespace
is either a group or a username.
To copy the issue reference to your clipboard:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
) >
Copy Reference
You can now paste the reference into another description or comment.
For more information, see
GitLab-specific references
Copy issue email address
You can create a comment in an issue by sending an email.
Sending an email to this address creates a comment that contains the email body.
For more information about creating comments by sending an email and the necessary configuration, see
reply to a comment by sending email
To copy the issue's email address:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the upper-right corner, select
More actions
{ellipsis_v}
) >
Copy issue email address
Assignees
An issue can be assigned to one or
more users
The assignees can be changed as often as needed. The idea is that the assignees are
people responsible for the issue.
When an issue is assigned to someone, it appears in their
Assigned work items
page.
If a user is not a member of a project, an issue can only be assigned to them if they create it
themselves or another project member assigns them.
Change assignee on an issue
Version history
Minimum role to change assignee
changed
from Reporter to Planner in GitLab 17.7.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
To change the assignee on an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the right sidebar, in the
Assignees
section, select
Edit
From the dropdown list, select the user to add as an assignee.
Select any area outside the dropdown list.
The assignee is changed without having to refresh the page.
Similar issues
To prevent duplication of issues on the same topic, GitLab searches for similar issues
when you create a new issue.
As you type in the title text box of the
New issue
page, GitLab searches titles and descriptions
across all issues in the current project. Only issues you have access to are returned.
Up to five similar issues, sorted by most recently updated, are displayed below the title text box.
Health status
Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
To better track the risk in meeting your plans, you can assign a health status to each issue.
You can use health status to signal to others in your organization whether issues are progressing
as planned or need attention to stay on schedule.
Incorporate a review of issue health status into your daily stand-up, project status reports, or weekly meetings to address risks to timely delivery of your planned work.
Change health status of an issue
Version history
Minimum role to change health status
changed
from Reporter to Planner in GitLab 17.7.
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
To edit health status of an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the right sidebar, in the
Health status
section, select
Edit
From the dropdown list, select the status to add to this issue:
On track
Needs attention
At risk
You can see the issue's health status in:
The
Work items
list
Epic's
Child items
section
Issue cards in issue boards
After an issue is closed, its health status can't be edited and the
Edit
button becomes disabled
until the issue is reopened.
You can also set and clear health statuses using the
/health_status
and
/clear_health_status
quick actions.
Status
Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
Version history
Introduced
in GitLab 18.2
with a flag
named
work_item_status_feature_flag
. Enabled by default.
Generally available
in GitLab 18.4. Feature flag
work_item_status_feature_flag
removed.
You can assign a status to issues to track their progress through your workflow.
Status provides more granular tracking than the basic open/closed states, so you can use specific
stages like
In progress
Done
, or
Won't do
For more information about how to configure custom statuses, see the
status section
Change status
Prerequisites:
You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project, be the author of the issue, or be assigned to the issue.
To change the status of an issue:
In the top bar, select
Search or go to
and find your project.
Select
Plan
Work items
, then filter by
Type
Issue
and select your issue.
In the right sidebar, in the
Status
section, select
Edit
From the dropdown list, select the status.
The issue's status updates immediately.
You can view the issue's status in:
The
Work items
list
An epic's
Child items
section
Cards on issue boards
You can also set the status by using the
/status
quick action
Participants
Participants are users who interacted with an issue.
For information about viewing participants, see
participants
Publish an issue
Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
If a status page application is associated with the project, you can use the
/publish
quick action
to publish the issue.
For more information, see
GitLab Status Page
Issue-related quick actions
You can also use quick actions to manage issues.
Some actions don't have corresponding UI buttons yet.
You can do the following
only by using quick actions
Add or remove a Zoom meeting
/zoom
and
/remove_zoom
).
Publish an issue
/publish
).
Clone an issue to the same or another project (
/clone
).
Close an issue and mark as a duplicate of another issue (
/duplicate
).
Copy labels and milestone from another merge request or issue in the project (
/copy_metadata
).
Related topics
Linked items
Child items