summaryrefslogtreecommitdiff
path: root/doc/user/group
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/group')
-rw-r--r--doc/user/group/epics/linked_epics.md14
-rw-r--r--doc/user/group/import/index.md2
-rw-r--r--doc/user/group/index.md34
-rw-r--r--doc/user/group/iterations/index.md124
-rw-r--r--doc/user/group/roadmap/index.md64
-rw-r--r--doc/user/group/saml_sso/group_managed_accounts.md4
-rw-r--r--doc/user/group/saml_sso/index.md4
-rw-r--r--doc/user/group/saml_sso/scim_setup.md2
-rw-r--r--doc/user/group/settings/group_access_tokens.md4
-rw-r--r--doc/user/group/settings/import_export.md2
-rw-r--r--doc/user/group/value_stream_analytics/img/new_value_stream_v13_12.pngbin19993 -> 0 bytes
-rw-r--r--doc/user/group/value_stream_analytics/img/vsa_aggregated_data_toggle_v14_9.pngbin145830 -> 0 bytes
-rw-r--r--doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.pngbin14209 -> 0 bytes
-rw-r--r--doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.pngbin14519 -> 0 bytes
-rw-r--r--doc/user/group/value_stream_analytics/index.md130
15 files changed, 223 insertions, 161 deletions
diff --git a/doc/user/group/epics/linked_epics.md b/doc/user/group/epics/linked_epics.md
index b695bae39e4..89699661efa 100644
--- a/doc/user/group/epics/linked_epics.md
+++ b/doc/user/group/epics/linked_epics.md
@@ -6,12 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Linked epics **(ULTIMATE)**
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/353473) in GitLab 14.9 [with a flag](../../../administration/feature_flags.md) named `related_epics_widget`. Enabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature,
-ask an administrator to [disable the feature flag](../../../administration/feature_flags.md)
-named `related_epics_widget`. On GitLab.com, this feature is available.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/353473) in GitLab 14.9 [with a flag](../../../administration/feature_flags.md) named `related_epics_widget`. Enabled by default.
+> - [Feature flag `related_epics_widget`](https://gitlab.com/gitlab-org/gitlab/-/issues/357089) removed in GitLab 15.0.
Linked epics are a bi-directional relationship between any two epics and appear in a block below
the epic description. You can link epics in different groups.
@@ -38,7 +34,11 @@ To link one epic to another:
- **relates to**
- **[blocks](#blocking-epics)**
- **[is blocked by](#blocking-epics)**
-1. Enter the epic number or paste in the full URL of the epic.
+1. To enter the linked epic, either:
+
+ - Enter `&`, followed by the epic's number. For example, `&123`.
+ - Enter `&`, followed by a word from the epic's title. For example, `&Deliver`.
+ - Paste in the epic's full URL.
![Adding a related epic](img/related_epics_add_v14_9.png)
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 0185cb9cfdf..6967815bf22 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -132,6 +132,8 @@ migrated:
- image URL
- Boards
- Board Lists
+- Releases
+ - Milestones ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339422) in GitLab 15.0).
## Troubleshooting Group Migration
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 085cd054c14..87146329031 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -53,7 +53,7 @@ For example, consider a user named Alex:
| GitLab URL | Namespace |
| ---------- | --------- |
| Alex creates an account with the username `alex`: `https://gitlab.example.com/alex`. | The namespace in this case is `alex`. |
-| Alex creates a group for their team with the group name `alex-team`. The group and its projects are available at: `https://gitlab.example.com/alex-team`. | The namespace in this cases is `alex-team`. |
+| Alex creates a group for their team with the group name `alex-team`. The group and its projects are available at: `https://gitlab.example.com/alex-team`. | The namespace in this case is `alex-team`. |
| Alex creates a subgroup of `alex-team` with the subgroup name `marketing`. The subgroup and its projects are available at: `https://gitlab.example.com/alex-team/marketing`. | The namespace in this case is `alex-team/marketing`. |
## Create a group
@@ -279,7 +279,7 @@ To view the activity feed in Atom format, select the
Similar to how you [share a project with a group](../project/members/share_project_with_groups.md),
you can share a group with another group. To invite a group, you must be a member of it. Members get direct access
-to the shared group. This includes members who inherited group membership from a parent group.
+to the shared group. This includes members who inherited group membership from a parent group.
To share a given group, for example, `Frontend` with another group, for example,
`Engineering`:
@@ -456,25 +456,28 @@ To restore a group that is marked for deletion:
## Prevent group sharing outside the group hierarchy
-This setting is only available on top-level groups. It affects all subgroups.
+You can configure a top-level group so its subgroups and projects
+cannot invite other groups outside of the top-level group's hierarchy.
+This option is only available for top-level groups.
-When checked, any group in the top-level group hierarchy can be shared only with other groups in the hierarchy.
+For example, in the following group and project hierarchy:
-For example, with these groups:
-
-- **Animals > Dogs**
+- **Animals > Dogs > Dog Project**
- **Animals > Cats**
- **Plants > Trees**
-If you select this setting in the **Animals** group:
+If you prevent group sharing outside the hierarchy for the **Animals** group:
-- **Dogs** can be shared with **Cats**.
-- **Dogs** cannot be shared with **Trees**.
+- **Dogs** can invite the group **Cats**.
+- **Dogs** cannot invite the group **Trees**.
+- **Dog Project** can invite the group **Cats**.
+- **Dog Project** cannot invite the group **Trees**.
To prevent sharing outside of the group's hierarchy:
-1. Go to the group's **Settings > General** page.
-1. Expand the **Permissions and group features** section.
+1. On the top bar, select **Menu > Groups** and find your group.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Permissions and group features**.
1. Select **Prevent members from sending invitations to groups outside of `<group_name>` and its subgroups**.
1. Select **Save changes**.
@@ -610,15 +613,16 @@ applies to:
You should consider these security implications before configuring IP address restrictions:
-- **SSH requests**: While you can restrict HTTP traffic on GitLab.com with IP address restrictions,
+- **SSH requests, including `git` operations will fail from all IP addresses**: While you can restrict HTTP traffic on GitLab.com with IP address restrictions,
they cause SSH requests, including Git operations over SSH, to fail. For more information,
read [issue 271673](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
-- **Administrators and group owners**: Users with these permission levels can always
+- **Administrators and group owners can access group settings from any IP address**: Users with these permission levels can always
access the group settings, regardless of IP restriction, but they cannot access projects
belonging to the group when accessing from a disallowed IP address.
-- **GitLab API and runner activities**: Only the [group](../../api/groups.md) (including all
+- **Some GitLab API endpoints will remain accessible from any IP**: Only the [group](../../api/groups.md) (including all
[group resources](../../api/api_resources.md#group-resources)) APIs and [project](../../api/api_resources.md#project-resources)
(including all [project resources](../../api/api_resources.md#project-resources)) APIs are protected by IP address restrictions.
+- **Activities performed by GitLab Runners are not bound by IP restrictions**:
When you register a runner, it is not bound by the IP restrictions. When the runner
requests a new job or an update to a job's state, it is also not bound by
the IP restrictions. But when the running CI/CD job sends Git requests from a
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index 1c316f2157d..858b13b87b8 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -41,7 +41,8 @@ From there you can create a new iteration or select an iteration to get a more d
## Create an iteration
-> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069) in GitLab 14.10.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069) in GitLab 14.10.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
WARNING:
Manual iteration management is in its end-of-life process. Creating an iteration is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069)
@@ -49,7 +50,7 @@ in GitLab 14.10, and is planned for removal in GitLab 16.0.
Prerequisites:
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
To create an iteration:
@@ -63,6 +64,7 @@ To create an iteration:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218277) in GitLab 13.2.
> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069) in GitLab 14.10.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
WARNING:
Editing all attributes, with the exception of `description` is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069)
@@ -71,7 +73,7 @@ In the future only editing an iteration's `description` will be allowed.
Prerequisites:
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
@@ -79,6 +81,7 @@ To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292268) in GitLab 14.3.
> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069) in GitLab 14.10.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
WARNING:
Manual iteration management is in its end-of-life process. Deleting an iteration is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/356069)
@@ -86,7 +89,7 @@ in GitLab 14.10, and is planned for removal in GitLab 16.0.
Prerequisites:
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
To delete an iteration, select the three-dot menu (**{ellipsis_v}**) > **Delete**.
@@ -169,37 +172,65 @@ To group issues by label:
## Iteration cadences
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5077) in GitLab 14.1.
-> - Deployed behind a [feature flag](../../feature_flags.md), named `iteration_cadences`, disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an
-administrator to [enable the feature flag](../../../administration/feature_flags.md) named
-`iteration_cadences` for a root group.
-On GitLab.com, this feature is not available. This feature is not ready for production use.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5077) in GitLab 14.1 [with a flag](../../../administration/feature_flags.md), named `iteration_cadences`. Disabled by default.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/354977) in GitLab 15.0: All scheduled iterations must start on the same day of the week as the cadence start day. Start date of cadence cannot be edited after the first iteration starts.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/354878) in GitLab 15.0.
Iteration cadences automate iteration scheduling. You can use them to
-automate creating iterations every 1, 2, 3, 4, or 6 weeks. You can also
+automate creating iterations every 1, 2, 3, or 4 weeks. You can also
configure iteration cadences to automatically roll over incomplete issues to the next iteration.
### Create an iteration cadence
+> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
+
Prerequisites:
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
To create an iteration cadence:
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Issues > Iterations**.
1. Select **New iteration cadence**.
-1. Fill out required fields, and select **Create iteration cadence**. The cadence list page opens.
+1. Complete the fields.
+ - Enter the title and description of the iteration cadence.
+ - Enter the first iteration start date of the iteration cadence. Iterations will be scheduled to
+ begin on the same day of the week as the day of the week of the start date.
+ - From the **Duration** dropdown list, select how many weeks each iteration should last.
+ - From the **Upcoming iterations** dropdown list, select how many upcoming iterations should be
+ created and maintained by GitLab.
+ - Optional. To move incomplete issues to the next iteration, select **Roll over issues**.
+1. Select **Create cadence**. The cadence list page opens.
+
+### Edit an iteration cadence
+
+Prerequisites:
+
+- You must have at least the Developer role for a group.
+
+To edit an iteration cadence:
+
+1. On the top bar, select **Menu > Groups** and find your group.
+1. On the left sidebar, select **Issues > Iterations**.
+1. Select **Edit iteration cadence**.
+
+When you edit the **Duration**, **Upcoming iterations**, or **First iteration start date** fields,
+only upcoming iterations are affected.
+
+You can edit the first iteration start date of a cadence if the cadence has not started yet.
+
+Editing **Upcoming iterations** is a non-destructive action.
+If ten upcoming iterations already exist, changing the number under **Upcoming iterations** to `2`
+doesn't delete the eight existing upcoming iterations.
### Delete an iteration cadence
+> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
+
Prerequisites:
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
Deleting an iteration cadence also deletes all iterations within that cadence.
@@ -210,18 +241,67 @@ To delete an iteration cadence:
1. Select the three-dot menu (**{ellipsis_v}**) > **Delete cadence** for the cadence you want to delete.
1. Select **Delete cadence** in the confirmation modal.
-### Convert manual cadence to use automatic scheduling
+### Manual iteration cadences
+
+When you **enable** the iteration cadences feature, all previously
+created iterations are added to a default iteration cadence.
+You can continue to add, edit, and remove iterations in
+this default cadence.
+
+#### Convert a manual cadence to use automatic scheduling
WARNING:
-The upgrade is irreversible. After it's done, manual iteration cadences cannot be created.
+The upgrade is irreversible. After it's done, a new manual iteration cadence cannot be created.
-When you **enable** the iteration cadences feature, all iterations are added
-to a default iteration cadence.
-In this default iteration cadence, you can continue to add, edit, and remove iterations.
+Prerequisites:
+- You must have created [iterations](#iterations) without cadences before enabling iteration cadences for your group.
To upgrade the iteration cadence to use the automation features:
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Issues > Iterations**.
1. Select the three-dot menu (**{ellipsis_v}**) > **Edit cadence** for the cadence you want to upgrade.
-1. Fill out required fields, and select **Save changes**.
+1. Complete the required fields **Duration** and **Upcoming iterations**.
+1. Select **Save changes**.
+
+#### Start dates of converted cadences
+
+The first iteration start date of your converted cadence is set to the start date of its
+**first** existing iteration.
+
+If you attempt to set a new start date, the conversion fails with an error message.
+If your manual cadence is empty, converting it to use automatic scheduling is effectively
+the same as creating a new automated cadence.
+
+GitLab will start scheduling new iterations on the same day of the week as the start date,
+starting from the nearest such day from the current date.
+
+During the conversion process GitLab does not delete or modify existing **ongoing** or
+**closed** iterations. If you have iterations with start dates in the future,
+they are updated to fit your cadence settings.
+
+#### Converted cadences example
+
+For example, suppose it's Friday, April 15, and you have three iterations in a manual cadence:
+
+- Monday, April 4 - Friday, April 8 (closed)
+- Tuesday, April 12 - Friday, April 15 (ongoing)
+- Tuesday, May 3 - Friday, May 6 (upcoming)
+
+On Friday, April 15, you convert the manual cadence
+to automate scheduling iterations every week, up to two upcoming iterations.
+
+The first iteration is closed, and the second iteration is ongoing,
+so they aren't deleted or modified in the conversion process.
+
+To observe the weekly duration, the third iteration is updated so that it:
+
+- Starts on Monday, April 18 - which is the nearest date that is Monday.
+- Ends on Sunday, April 24.
+
+Finally, to always have two upcoming iterations, an additional iteration is scheduled:
+
+- Monday, April 4 - Friday, April 8 (closed)
+- Tuesday, April 12 - Friday, April 15 (ongoing)
+- Monday, April 18 - Sunday, April 24 (upcoming)
+- Monday, April 25 - Sunday, May 1 (upcoming)
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 89c5c6ed466..10ca6d139ad 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -1,5 +1,4 @@
---
-type: reference
stage: Plan
group: Product Planning
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
@@ -7,7 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Roadmap **(PREMIUM)**
-> - Introduced in GitLab 10.5.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/198062) from GitLab Ultimate to GitLab Premium in 12.9.
> - In [GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/5164) and later, the epic bars show epics' title, progress, and completed weight percentage.
> - Milestones appear in roadmaps in [GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/6802), and later.
@@ -27,10 +25,10 @@ You can expand epics that contain child epics to show their child epics in the r
You can select the chevron (**{chevron-down}**) next to the epic title to expand and collapse the
child epics.
-On top of the milestone bars, you can see their title.
-When you hover over a milestone bar or title, a popover appears with its title, start date, and due
-date. You can also select the chevron (**{chevron-down}**) next to the **Milestones** heading to
-toggle the list of the milestone bars.
+On top of the milestone bars, you can see their title. When you point to a
+milestone bar or title, a popover appears with its title, start date, and due
+date. You can also select the chevron (**{chevron-down}**) next to the **Milestones**
+heading to toggle the list of the milestone bars.
![roadmap view](img/roadmap_view_v14_3.png)
@@ -41,8 +39,8 @@ toggle the list of the milestone bars.
> - Filtering by epic [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218623) in GitLab 13.11.
> - Filtering by milestone [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/323917) in GitLab 14.5.
-WARNING:
-Filtering roadmaps by milestone might not be available to you. Check the **version history** note above for details.
+NOTE:
+Filtering roadmaps by milestone might not be available to you. Be sure to review this section's version history for details.
When you want to explore a roadmap, there are several ways to make it easier by sorting epics or
filtering them by what's important for you.
@@ -52,8 +50,9 @@ You can sort epics in the Roadmap view by:
- Start date
- Due date
-Each option contains a button that toggles the sort order between **ascending** and **descending**.
-The sort option and order persist when browsing Epics, including the [epics list view](../epics/index.md).
+Each option contains a button that toggles the sort order between **ascending**
+and **descending**. The sort option and order persist when browsing Epics, including
+the [epics list view](../epics/index.md).
You can also filter epics in the Roadmap view by the epics':
@@ -66,7 +65,7 @@ You can also filter epics in the Roadmap view by the epics':
![roadmap date range in weeks](img/roadmap_filters_v13_11.png)
-Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
+You can also [visualize roadmaps inside of an epic](../epics/index.md#roadmap-in-epics).
### Roadmap settings
@@ -78,38 +77,40 @@ When you enable the roadmap settings sidebar, you can use it to refine epics sho
You can configure the following:
- Select date range.
-- Turn milestones on or off and select whether to show all, group, subgroup, or project milestones.
+- Turn milestones on or off, and select whether to show all, group, subgroup, or
+ project milestones.
- Show all, open, or closed epics.
- Turn progress tracking for child issues on or off and select whether
to use issue weights or counts.
- The progress tracking setting is not saved in user preferences but is saved or shared using URL parameters.
+The progress tracking setting isn't saved in user preferences, but is saved or
+shared using URL parameters.
## Timeline duration
-> - Introduced in GitLab 11.0.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/198062) from GitLab Ultimate to GitLab Premium in 12.9.
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/198062) from GitLab Ultimate to GitLab Premium in 12.9.
### Date range presets
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/204994) in GitLab 14.3. [Deployed behind the `roadmap_daterange_filter` flag](../../../administration/feature_flags.md), disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/204994) in GitLab 14.3 [with a flag](../../../administration/feature_flags.md) named `roadmap_daterange_filter`. Disabled by default.
> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/323917) in GitLab 14.3.
-> - [Feature flag `roadmap_daterange_filter` removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72419) in GitLab 14.5.
+> - Generally available in GitLab 14.5. [Feature flag `roadmap_daterange_filter`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72419) removed.
-Roadmap provides three date range options, each with predetermined timeline duration:
+Roadmap provides these date range options, each with a predetermined timeline duration:
-- **This quarter**: includes weeks present in current quarter.
-- **This year**: includes weeks or months present in current year.
-- **Within 3 years**: includes weeks, months, or quarters present in the previous 18 months and
- upcoming 18 months (that is, three years in total).
+- **This quarter**: Includes the weeks present in the current quarter.
+- **This year**: Includes the weeks or months present in the current year.
+- **Within 3 years**: Includes the weeks, months, or quarters present both in
+ the previous 18 months and the upcoming 18 months (three years in total).
### Layout presets
-Depending on selected [date range preset](#date-range-presets), Roadmap supports the following layout presets:
+Depending on selected [date range preset](#date-range-presets), Roadmap supports
+these layout presets:
-- **Quarters**: only available when the "Within 3 years" date range is selected.
-- **Months**: available when either "This year" or "Within 3 years" date range is selected.
-- **Weeks** (default): available for all the date range presets.
+- **Quarters**: Available only when the **Within 3 years** date range is selected.
+- **Months**: Available when either **This year** or **Within 3 years** date range is selected.
+- **Weeks** (default): Available for all the date range presets.
### Quarters
@@ -125,12 +126,11 @@ the timeline header represent the month of the quarter.
![roadmap date range in months](img/roadmap_timeline_months.png)
-In the **Months** preset, roadmap shows epics and milestones which have start or due dates
-**falling within** or
-**going through** currently selected date range preset, where **today**
-is shown by the vertical red line in the timeline. The sub-headers underneath the month name on
-the timeline header represent the date on starting day (Sunday) of the week. This preset is
-selected by default.
+In the **Months** preset, roadmap shows epics and milestones which have start or
+due dates **falling within** or **going through** currently selected date range
+preset, where **today** is shown by the vertical red line in the timeline. The
+sub-headers underneath the month name on the timeline header represent the date
+on the start day (Sunday) of the week. This preset is selected by default.
### Weeks
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index bffaef40800..6771ff8739a 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -107,14 +107,14 @@ Since personal access tokens are the only token needed for programmatic access t
### Set a limit
Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field
-is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens)
+is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens)
on the lifetime of personal access tokens apply.
To set a limit on how long personal access tokens are valid for users in a group managed account:
1. Navigate to the **Settings > General** page in your group's sidebar.
1. Expand the **Permissions and group features** section.
-1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field.
+1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
1. Click **Save changes**.
Once a lifetime for personal access tokens is set:
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 4d122e337db..1b480a52920 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -129,7 +129,7 @@ SSO has the following effects when enabled:
- For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or
pull from a GitLab repository.
- Git activity originating from CI/CD jobs do not have the SSO check enforced.
-- Credentials that are not tied to regular users (for example, access tokens and deploy keys) do not have the SSO check enforced.
+- Credentials that are not tied to regular users (for example, project and group access tokens, and deploy keys) do not have the SSO check enforced.
- Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md).
When SSO is enforced, users are not immediately revoked. If the user:
@@ -589,7 +589,7 @@ Here are possible causes and solutions:
| Cause | Solution |
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| You've tried to link multiple SAML identities to the same user, for a given identity provider. | Change the identity that you sign in with. To do so, [unlink the previous SAML identity](#unlinking-accounts) from this GitLab account before attempting to sign in again. |
-| The NameID changes everytime the user requests SSO identification | Check the NameID is not set with `Transient` format, or the NameID is not changing on subsequent requests.|
+| The NameID changes every time the user requests SSO identification | Check the NameID is not set with `Transient` format, or the NameID is not changing on subsequent requests.|
### Message: "SAML authentication failed: Email has already been taken"
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 3960c97142e..bc1799c2e54 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -110,7 +110,7 @@ Before you start this section:
After the above steps are complete:
1. Sign in to Okta.
-1. Ensure you are in the Admin section by selecting the **Admin** button located in the top right. The admin button is not visible from the admin page.
+1. Ensure you are in the Admin Area by selecting the **Admin** button located in the top right. The button is not visible from the Admin Area.
1. In the **Application** tab, select **Browse App Catalog**.
1. Search for **GitLab**, find and select on the 'GitLab' application.
1. On the GitLab application overview page, select **Add**.
diff --git a/doc/user/group/settings/group_access_tokens.md b/doc/user/group/settings/group_access_tokens.md
index 0666303bcf8..4b791d5a221 100644
--- a/doc/user/group/settings/group_access_tokens.md
+++ b/doc/user/group/settings/group_access_tokens.md
@@ -25,7 +25,7 @@ Group access tokens are similar to [project access tokens](../../project/setting
and [personal access tokens](../../profile/personal_access_tokens.md), except they are
associated with a group rather than a project or user.
-In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) as personal access tokens if the limit is set.
+In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
You can use group access tokens:
@@ -50,7 +50,7 @@ To create a group access token:
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Settings > Access Tokens**.
1. Enter a name. The token name is visible to any user with permissions to view the group.
-1. Optional. Enter an expiry date for the token. The token will expire on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
+1. Optional. Enter an expiry date for the token. The token will expire on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
1. Select a role for the token.
1. Select the [desired scopes](#scopes-for-a-group-access-token).
1. Select **Create group access token**.
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index 7b63466656d..23a638fb98c 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -86,7 +86,7 @@ To export the contents of a group:
NOTE:
The maximum import file size can be set by the Administrator, default is `0` (unlimited).
-As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](../../../api/settings.md#change-application-settings) or the [Admin UI](../../admin_area/settings/account_and_limit_settings.md). Default [modified](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50MB to 0 in GitLab 13.8.
+As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](../../../api/settings.md#change-application-settings) or the [Admin Area](../../admin_area/settings/account_and_limit_settings.md). Default [modified](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50MB to 0 in GitLab 13.8.
You can also use the [group import/export API](../../../api/group_import_export.md).
diff --git a/doc/user/group/value_stream_analytics/img/new_value_stream_v13_12.png b/doc/user/group/value_stream_analytics/img/new_value_stream_v13_12.png
deleted file mode 100644
index d64ec31aabf..00000000000
--- a/doc/user/group/value_stream_analytics/img/new_value_stream_v13_12.png
+++ /dev/null
Binary files differ
diff --git a/doc/user/group/value_stream_analytics/img/vsa_aggregated_data_toggle_v14_9.png b/doc/user/group/value_stream_analytics/img/vsa_aggregated_data_toggle_v14_9.png
deleted file mode 100644
index 5ad8026b8fd..00000000000
--- a/doc/user/group/value_stream_analytics/img/vsa_aggregated_data_toggle_v14_9.png
+++ /dev/null
Binary files differ
diff --git a/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png b/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png
deleted file mode 100644
index 9345c4023de..00000000000
--- a/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png
+++ /dev/null
Binary files differ
diff --git a/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png b/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png
deleted file mode 100644
index a29689a2c18..00000000000
--- a/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png
+++ /dev/null
Binary files differ
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index 3fce9baa9ce..4be97779603 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -11,6 +11,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Value stream analytics provides metrics about each stage of your software development process.
+A **value stream** is the entire work process that delivers value to customers. For example,
+the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
+with the "manage" stage and ends with the "protect" stage.
+
Use value stream analytics to identify:
- The amount of time it takes to go from an idea to production.
@@ -30,7 +34,7 @@ Value stream analytics is also available for [projects](../../analytics/value_st
Prerequisite:
- You must have at least the Reporter role to view value stream analytics for groups.
-- You must create a [custom value stream](#custom-value-streams). Value stream analytics only shows custom value streams created for your group.
+- You must create a [custom value stream](#create-a-value-stream-with-gitlab-default-stages). Value stream analytics only shows custom value streams created for your group.
To view value stream analytics for your group:
@@ -41,9 +45,6 @@ To view value stream analytics for your group:
1. Select the **Filter results** text box.
1. Select a parameter.
1. Select a value or enter text to refine the results.
- 1. Select whether to view metrics for items with a start or stop event:
- - To view items with a stop event in the date range, turn on the **Filter by stop date** toggle. Enabled by default.
- - To view items with a start event in the date range, turn off the **Filter by stop date** toggle.
1. To adjust the date range:
- In the **From** field, select a start date.
- In the **To** field, select an end date. The charts and list show workflow items created
@@ -78,9 +79,6 @@ To view the median time spent in each stage by a group:
1. Select the **Filter results** text box.
1. Select a parameter.
1. Select a value or enter text to refine the results.
- 1. Select whether to view metrics for items with a start or stop event:
- - To view items with a stop event in the date range, turn on the **Filter by stop date** toggle. Enabled by default.
- - To view items with a start event in the date range, turn off the **Filter by stop date** toggle.
1. To adjust the date range:
- In the **From** field, select a start date.
- In the **To** field, select an end date.
@@ -91,7 +89,10 @@ To view the median time spent in each stage by a group:
Value stream analytics shows the lead time and cycle time for issues in your groups:
- Lead time: Median time from when the issue was created to when it was closed.
-- Cycle time: Median time from first commit to issue closed. Commits are associated with issues when users [cross-link them in the commit message](../../project/issues/crosslinking_issues.md#from-commit-messages).
+- Cycle time: Median time from first commit to issue closed. GitLab measures cycle time from the earliest
+commit of a [linked issue's merge request](../../project/issues/crosslinking_issues.md#from-commit-messages)
+to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation
+is always later than commit time.
To view the lead time and cycle time for issues:
@@ -101,9 +102,6 @@ To view the lead time and cycle time for issues:
1. Select the **Filter results** text box.
1. Select a parameter.
1. Select a value or enter text to refine the results.
- 1. Select whether to view metrics for items with a start or stop event:
- - To view items with a stop event in the date range, turn on the **Filter by stop date** toggle. Enabled by default.
- - To view items with a start event in the date range, turn off the **Filter by stop date** toggle.
1. To adjust the date range:
- In the **From** field, select a start date.
- In the **To** field, select an end date.
@@ -124,9 +122,6 @@ To view the lead time for changes for merge requests in your group:
1. Select the **Filter results** text box.
1. Select a parameter.
1. Select a value or enter text to refine the results.
- 1. Select whether to view metrics for items with a start or stop event:
- - To view items with a stop event in the date range, turn on the **Filter by stop date** toggle. Enabled by default.
- - To view items with a start event in the date range, turn off the **Filter by stop date** toggle.
1. To adjust the date range:
- In the **From** field, select a start date.
- In the **To** field, select an end date.
@@ -140,7 +135,7 @@ The **Lead Time for Changes** metrics display below the **Filter results** text
To view deployment metrics, you must have a
[production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments).
-Value stream analytics shows the following deployment metrics for your group:
+Value stream analytics shows the following deployment metrics for your group:
- Deploys: The number of successful deployments in the date range.
- Deployment Frequency: The average number of successful deployments per day in the date range.
@@ -153,13 +148,14 @@ To view deployment metrics for your group:
1. Select the **Filter results** text box.
1. Select a parameter.
1. Select a value or enter text to refine the results.
- 1. Select whether to view metrics for items with a start or stop event:
- - To view items with a stop event in the date range, turn on the **Filter by stop date** toggle. Enabled by default.
- - To view items with a start event in the date range, turn off the **Filter by stop date** toggle.
1. To adjust the date range:
- In the **From** field, select a start date.
- In the **To** field, select an end date.
+NOTE:
+The date range selector filters items by the event time. This is the time when the currently
+selected stage finished for the given item.
+
The **Deploys** and **Deployment Frequency** metrics display below the **Filter results** text box.
Deployment metrics are calculated based on data from the
@@ -174,19 +170,22 @@ In GitLab 13.8 and earlier, metrics are calculated based on when the deployment
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335391) in GitLab 14.5 [with a flag](../../../administration/feature_flags.md) named `use_vsa_aggregated_tables`. Disabled by default.
> - Filter by stop date toggle [added](https://gitlab.com/gitlab-org/gitlab/-/issues/352428) in GitLab 14.9
> - Data refresh badge [added](https://gitlab.com/gitlab-org/gitlab/-/issues/341739) in GitLab 14.9
+> - Filter by stop date toggle [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84356) in GitLab 14.9
+> - Enable filtering by stop date [added](https://gitlab.com/gitlab-org/gitlab/-/issues/355000) in GitLab 15.0
-Plans for value stream analytics to filter items by stop event instead of start event are tracked in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/6046). With the completion of this work, value stream analytics will only display items with a stop event in the date range.
-
-To preview this functionality, you can use the **Filter by stop date** toggle to enable or disable this filter until the [default filtering mode is introduced](../../../update/deprecations.md#value-stream-analytics-filtering-calculation-change) and the toggle is removed.
+Value stream analytics uses a backend process to collect and aggregate stage-level data, which
+ensures it can scale for large groups with a high number of issues and merge requests. Due to this process,
+there may be a slight delay between when an action is taken (for example, closing an issue) and when the data
+displays on the value stream analytics page.
-If you turn on the **Filter by stop date** toggle, the results show items with a stop event within the date range. When this function is enabled, it may take up to 10 minutes for results to show due to data aggregation. There are occasions when it may take longer than 10 minutes for results to display:
+It may take up to 10 minutes to process the data and display results. Data collection may take
+longer than 10 minutes in the following cases:
-- If this is the first time you are viewing value stream analytics and have not yet [created a value stream](#create-a-value-stream).
+- If this is the first time you are viewing value stream analytics and have not yet [created a value stream](#create-a-value-stream-with-gitlab-default-stages).
- If the group hierarchy has been re-arranged.
- If there have been bulk updates on issues and merge requests.
-To view when the data was most recently updated, in the right corner next to **Edit**, hover over the **Last updated** badge. This badge is only available if you have turned on the **Filter by start date** toggle.
-![Aggregated data toggle](img/vsa_aggregated_data_toggle_v14_9.png "Aggregated data toggle")
+To view when the data was most recently updated, in the right corner next to **Edit**, hover over the **Last updated** badge.
## How value stream analytics measures stages
@@ -261,80 +260,58 @@ These patterns are not case-sensitive.
You can change the name of a project environment in your GitLab CI/CD configuration.
-## Custom value streams
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12196) in GitLab 12.9.
-
-Use custom value streams to create custom stages that align with your own development processes,
-and hide default stages. The dashboard depicts stages as a horizontal process
-flow.
-
-### Create a value stream
+## Create a value stream with GitLab default stages
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221202) in GitLab 13.3
-A default value stream is readily available for each group. You can create additional value streams
-based on the different areas of work that you would like to measure.
-
-Once created, a new value stream includes the stages that follow
-[GitLab workflow](../../../topics/gitlab_flow.md)
-best practices. You can customize this flow by adding, hiding or re-ordering stages.
-
-To create a value stream:
+When you create a value stream, you can use GitLab default stages and hide or re-order them to customize. You can also
+create custom stages in addition to those provided in the default template.
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Analytics > Value Stream**.
-1. If this is the first time you are creating a value stream, select **Create custom value stream**. Otherwise, in the top right, select the dropdown list and then **Create new Value Stream**.
-1. Enter a name for the new Value Stream.
- - You can [customize the stages](#create-a-value-stream-with-stages).
-1. Select **Create Value Stream**.
-
-![New value stream](img/new_value_stream_v13_12.png "Creating a new value stream")
+1. Select **Create new Value Stream**.
+1. Enter a name for the value stream.
+1. Select **Create from default template**.
+1. Customize the default stages:
+ - To re-order stages, select the up or down arrows.
+ - To hide a stage, select **Hide** (**{eye-slash}**).
+1. To add a custom stage, select **Add another stage**.
+ - Enter a name for the stage.
+ - Select a **Start event** and a **Stop event**.
+1. Select **Create value stream**.
NOTE:
If you have recently upgraded to GitLab Premium, it can take up to 30 minutes for data to collect and display.
-### Create a value stream with stages
+## Create a value stream with custom stages
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50229) in GitLab 13.7.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55572) in GitLab 13.10.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/294190) in GitLab 13.11.
-You can create value streams with stages, starting with a default or a blank template. You can
-add stages as desired.
-
-To create a value stream with stages:
+When you create a value stream, you can create and add custom stages that align with your own development workflows.
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Analytics > Value Stream**.
-1. If this is the first time you are creating a value stream, select **Create custom value stream**. Otherwise, in the top right, select the dropdown list and then **Create new Value Stream**.
-1. Select either **Create from default template** or **Create from no template**.
- - You can hide or re-order default stages in the value stream.
-
- ![Default stage actions](img/vsa_default_stage_v13_10.png "Default stage actions")
-
- - You can add new stages by selecting **Add another stage**.
- - You can select the name and start and end events for the stage.
-
- ![Custom stage actions](img/vsa_custom_stage_v13_10.png "Custom stage actions")
-1. Select **Create Value Stream**.
-
-### Label-based stages
-
-The pre-defined start and end events can cover many use cases involving both issues and merge requests.
+1. Select **Create value stream**.
+1. For each stage:
+ - Enter a name for the stage.
+ - Select a **Start event** and a **Stop event**.
+1. To add another stage, select **Add another stage**.
+1. To re-order the stages, select the up or down arrows.
+1. Select **Create value stream**.
-In more complex workflows, use stages based on group labels. These events are based on
-added or removed labels. In particular, [scoped labels](../../project/labels.md#scoped-labels)
-are useful for complex workflows.
+### Label-based stages for custom value streams
-In this example, we'd like to measure times for deployment from a staging environment to production. The workflow is the following:
+To measure complex workflows, you can use [scoped labels](../../project/labels.md#scoped-labels). For example, to measure deployment
+time from a staging environment to production, you could use the following labels:
- When the code is deployed to staging, the `workflow::staging` label is added to the merge request.
- When the code is deployed to production, the `workflow::production` label is added to the merge request.
![Label-based value stream analytics stage](img/vsa_label_based_stage_v14_0.png "Creating a label-based value stream analytics stage")
-### Edit a value stream
+## Edit a value stream
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267537) in GitLab 13.10.
@@ -342,19 +319,18 @@ After you create a value stream, you can customize it to suit your purposes. To
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Analytics > Value Stream**.
-1. In the top right, select the dropdown list and then select the relevant value stream.
+1. In the top right, select the dropdown list, and select a value stream.
1. Next to the value stream dropdown list, select **Edit**.
- The edit form is populated with the value stream details.
1. Optional:
- Rename the value stream.
- Hide or re-order default stages.
- Remove existing custom stages.
- - Add new stages by selecting the 'Add another stage' button
+ - To add new stages, select **Add another stage**.
- Select the start and end events for the stage.
1. Optional. To undo any modifications, select **Restore value stream defaults**.
1. Select **Save Value Stream**.
-### Delete a value stream
+## Delete a value stream
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221205) in GitLab 13.4.