summaryrefslogtreecommitdiff
path: root/doc/user/project/issues
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/project/issues')
-rw-r--r--doc/user/project/issues/associate_zoom_meeting.md4
-rw-r--r--doc/user/project/issues/confidential_issues.md6
-rw-r--r--doc/user/project/issues/due_dates.md2
-rw-r--r--doc/user/project/issues/index.md1
-rw-r--r--doc/user/project/issues/managing_issues.md14
-rw-r--r--doc/user/project/issues/sorting_issue_lists.md107
6 files changed, 100 insertions, 34 deletions
diff --git a/doc/user/project/issues/associate_zoom_meeting.md b/doc/user/project/issues/associate_zoom_meeting.md
index e020bdee737..aba8c45699c 100644
--- a/doc/user/project/issues/associate_zoom_meeting.md
+++ b/doc/user/project/issues/associate_zoom_meeting.md
@@ -25,7 +25,7 @@ In an issue, leave a comment using the `/zoom` quick action followed by a valid
/zoom https://zoom.us/j/123456789
```
-If the Zoom meeting URL is valid and you have at least [Reporter permissions](../../permissions.md),
+If the Zoom meeting URL is valid and you have at least the Reporter [role](../../permissions.md),
a system alert notifies you of its successful addition.
The issue's description is automatically edited to include the Zoom link, and a button
appears right under the issue's title.
@@ -44,5 +44,5 @@ Similarly to adding a Zoom meeting, you can remove it with a quick action:
/remove_zoom
```
-If you have at least [Reporter permissions](../../permissions.md),
+If you have at least the Reporter [role](../../permissions.md),
a system alert notifies you that the meeting URL was successfully removed.
diff --git a/doc/user/project/issues/confidential_issues.md b/doc/user/project/issues/confidential_issues.md
index 136e8ee2ebb..b8a01f7ccd6 100644
--- a/doc/user/project/issues/confidential_issues.md
+++ b/doc/user/project/issues/confidential_issues.md
@@ -77,14 +77,14 @@ that prevent leaks of private data.
There are two kinds of level access for confidential issues. The general rule
is that confidential issues are visible only to members of a project with at
-least [Reporter access](../../permissions.md#project-members-permissions). However, a guest user can also create
+least the Reporter [role](../../permissions.md#project-members-permissions). However, a guest user can also create
confidential issues, but can only view the ones that they created themselves.
Confidential issues are also hidden in search results for unprivileged users.
-For example, here's what a user with the [Maintainer role](../../permissions.md) and Guest access
+For example, here's what a user with the [Maintainer role](../../permissions.md) and the Guest role
sees in the project's search results respectively.
-| Maintainer role | Guest access |
+| Maintainer role | Guest role |
|:---------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------|
| ![Confidential issues search by maintainer](img/confidential_issues_search_master.png) | ![Confidential issues search by guest](img/confidential_issues_search_guest.png) |
diff --git a/doc/user/project/issues/due_dates.md b/doc/user/project/issues/due_dates.md
index 94a5fdc3f0f..2c20ccdcee0 100644
--- a/doc/user/project/issues/due_dates.md
+++ b/doc/user/project/issues/due_dates.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Due dates **(FREE)**
Due dates can be used in [issues](index.md) to keep track of deadlines and make sure features are
-shipped on time. Users need at least [Reporter permissions](../../permissions.md)
+shipped on time. Users need at least the Reporter [role](../../permissions.md)
to be able to edit the due date. All users with permission to view
the issue can view the due date.
diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md
index 9842b0820e6..64838b261ce 100644
--- a/doc/user/project/issues/index.md
+++ b/doc/user/project/issues/index.md
@@ -49,3 +49,4 @@ To learn how the GitLab Strategic Marketing department uses GitLab issues with [
- [Issues API](../../../api/issues.md)
- [Configure an external issue tracker](../../../integration/external-issue-tracker.md)
- [Parts of an issue](issue_data_and_actions.md)
+- [Tasks](../../tasks.md)
diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md
index a2fa044be6b..6b3d5d6563a 100644
--- a/doc/user/project/issues/managing_issues.md
+++ b/doc/user/project/issues/managing_issues.md
@@ -380,12 +380,18 @@ You can also use the `/iteration`
[quick action](../quick_actions.md#issues-merge-requests-and-epics)
in a comment or description field.
-## Real-time sidebar **(FREE SELF)**
+## Real-time sidebar
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17589) in GitLab 13.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17589) in GitLab 13.3. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/3413) in GitLab 13.9.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/17589) in GitLab 14.5.
-Assignees in the sidebar are updated in real time. This feature is **disabled by default**.
-To enable it, you need to enable [Action Cable in-app mode](https://docs.gitlab.com/omnibus/settings/actioncable.html).
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature per project or for your entire instance, ask an administrator to
+[disable the feature flags](../../../administration/feature_flags.md) named `real_time_issue_sidebar` and `broadcast_issue_updates`.
+On GitLab.com, this feature is available.
+
+Assignees in the sidebar are updated in real time.
## Similar issues
diff --git a/doc/user/project/issues/sorting_issue_lists.md b/doc/user/project/issues/sorting_issue_lists.md
index aed346fb504..ebfc723280f 100644
--- a/doc/user/project/issues/sorting_issue_lists.md
+++ b/doc/user/project/issues/sorting_issue_lists.md
@@ -8,34 +8,59 @@ info: To determine the technical writer assigned to the Stage/Group associated w
You can sort a list of issues several ways, including by:
-- Blocking **(PREMIUM)**
-- Created date
-- Due date
-- Label priority
-- Last updated
-- Milestone due date
-- Popularity
-- Priority
-- Title ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67234) in GitLab 14.3)
-- Weight
+- [Blocking issues](#sorting-by-blocking-issues)
+- [Created date](#sorting-by-created-date)
+- [Due date](#sorting-by-due-date)
+- [Label priority](#sorting-by-label-priority)
+- [Last updated](#sorting-by-last-updated)
+- [Manual sorting](#manual-sorting)
+- [Milestone due date](#sorting-by-milestone-due-date)
+- [Popularity](#sorting-by-popularity)
+- [Priority](#sorting-by-priority)
+- [Title](#sorting-by-title)
+- [Weight](#sorting-by-weight)
The available sorting options can change based on the context of the list.
-For sorting by issue priority, see [Label Priority](../labels.md#label-priority).
-In group and project issue lists, it is also possible to order issues manually,
-similar to [issue boards](../issue_board.md#how-gitlab-orders-issues-in-a-list).
+## Sorting by blocking issues **(PREMIUM)**
-## Sorting by popularity
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34247/) in GitLab 13.7.
-When you select sorting by **Popularity**, the issue order changes to sort descending by the
-number of upvotes ([awarded](../../award_emojis.md) "thumbs up" emoji)
-on each issue. You can use this to identify issues that are in high demand.
+When you sort by **Blocking**, the issue list changes to sort descending by the
+number of issues each issue is blocking.
+
+## Sorting by created date
+
+When you sort by **Created date**, the issue list changes to sort descending by the issue
+creation date. Issues created most recently are first.
+
+## Sorting by due date
+
+When you sort by **Due date**, the issue list changes to sort ascending by the issue
+[due date](issue_data_and_actions.md#due-date). Issues with the earliest due date are first,
+and issues without a due date are last.
+
+## Sorting by label priority
+
+When you sort by **Label priority**, the issue list changes to sort descending.
+Issues with the highest priority label are first, then all other issues.
+
+Ties are broken arbitrarily. Only the highest prioritized label is checked,
+and labels with a lower priority are ignored.
+For more information, see [issue 14523](https://gitlab.com/gitlab-org/gitlab/-/issues/14523).
+
+To learn more about priority labels, read the [Labels](../labels.md#label-priority) documentation.
+
+## Sorting by last updated
+
+When you sort by **Last updated**, the issue list changes to sort by the time of a last
+update. Issues changed the most recently are first.
## Manual sorting
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62178) in GitLab 12.2.
-When you select **Manual** sorting, you can change
+When you sort by **Manual** order, you can change
the order by dragging and dropping the issues. The changed order persists, and
everyone who visits the same list sees the updated issue order, with some exceptions.
@@ -48,13 +73,47 @@ the updated relative order value is used for the ordering.
So, if anyone drags issue `A` above issue `B` in your GitLab instance,
this ordering is maintained whenever they appear together in any list.
-This ordering also affects [issue boards](../issue_board.md#how-gitlab-orders-issues-in-a-list).
+This ordering also affects [issue boards](../issue_board.md#ordering-issues-in-a-list).
Changing the order in an issue list changes the ordering in an issue board,
-and vice versa.
+and the other way around.
-## Sorting by blocking issues **(PREMIUM)**
+## Sorting by milestone due date
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34247/) in GitLab 13.7.
+When you sort by **Milestone due date**, the issue list changes to sort ascending by the
+assigned milestone due date. Issues with milestones with the earliest due date are first,
+then issues with a milestone without a due date.
+
+## Sorting by popularity
+
+When you sort by **Popularity**, the issue order changes to sort descending by the
+number of upvotes ([awarded](../../award_emojis.md) a "thumbs up" emoji)
+on each issue. You can use this to identify issues that are in high demand.
+
+## Sorting by priority
+
+When you sort by **Priority**, the issue order changes to sort in this order:
+
+1. Issues with milestones that have due dates, where the soonest assigned milestone is listed first.
+1. Issues with milestones with no due dates.
+1. Issues with a higher priority label.
+1. Issues without a prioritized label.
+
+To learn more about priority, read the [Labels](../labels.md#label-priority) documentation.
+
+## Sorting by title
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67234) in GitLab 14.3.
+
+When you sort by **Title**, the issue order changes to sort alphabetically by the issue
+title in this order:
+
+- Emoji
+- Special characters
+- Numbers
+- Letters: first Latin, then accented (for example, `รถ`)
+
+## Sorting by weight
-When you select to sort by **Blocking**, the issue list changes to sort descending by the
-number of issues each issue is blocking. You can use this to determine the critical path for your backlog.
+When you sort by **Weight**, the issue list changes to sort ascending by the
+[issue weight](issue_weight.md).
+Issues with lowest weight are first, and issues without a weight are last.