diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-05-19 15:08:42 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-05-19 15:08:42 +0300 |
commit | 0eea37aefa31ed22e32eadbe6164dd92e3c64ec2 (patch) | |
tree | e1ec47e8160c6c36a8ae08ba1d39902be068ef05 /doc/user | |
parent | 3fbfc0075a306ad85c70c006b978a2e96bd4283a (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user')
-rw-r--r-- | doc/user/crm/index.md | 8 | ||||
-rw-r--r-- | doc/user/permissions.md | 1 | ||||
-rw-r--r-- | doc/user/project/merge_requests/getting_started.md | 29 | ||||
-rw-r--r-- | doc/user/project/merge_requests/index.md | 29 |
4 files changed, 36 insertions, 31 deletions
diff --git a/doc/user/crm/index.md b/doc/user/crm/index.md index 7a400205e30..bec67acae3e 100644 --- a/doc/user/crm/index.md +++ b/doc/user/crm/index.md @@ -33,9 +33,13 @@ To read more about what is planned for the future, see [issue 2256](https://gitl ## Enable customer relations management (CRM) -To enable customer relations management in a group: +Customer relations management features must be enabled at the group level. If your +group also contains subgroups, and you want to use CRM features in the subgroup, +you must enable CRM features for the subgroup. -1. On the top bar, select **Menu > Groups** and find your group. +To enable customer relations management in a group or subgroup: + +1. On the top bar, select **Menu > Groups** and find your group or subgroup. 1. On the left sidebar, select **Settings > General**. 1. Expand the **Permissions and group features** section. 1. Select **Enable customer relations**. diff --git a/doc/user/permissions.md b/doc/user/permissions.md index d28cf75d11f..433274c63b9 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -428,6 +428,7 @@ The following table lists group permissions available for each role: | View [Billing](../subscriptions/gitlab_com/index.md#view-your-gitlab-saas-subscription) | | | | | ✓ (4) | | View group [Usage Quotas](usage_quotas.md) page | | | | | ✓ (4) | | Manage group runners | | | | | ✓ | +| GitLab migration | | | | | ✓ | <!-- markdownlint-disable MD029 --> diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md index c1986a80ca0..1bfaef9d82b 100644 --- a/doc/user/project/merge_requests/getting_started.md +++ b/doc/user/project/merge_requests/getting_started.md @@ -140,35 +140,6 @@ is set for deletion, the merge request widget displays the ![Delete source branch status](img/remove_source_branch_status.png) -### Branch retargeting on merge **(FREE SELF)** - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. -> - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. -> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) GitLab 13.10. - -In specific circumstances, GitLab can retarget the destination branch of -open merge request, if the destination branch merges while the merge request is -open. Merge requests are often chained in this manner, with one merge request -depending on another: - -- **Merge request 1**: merge `feature-alpha` into `main`. -- **Merge request 2**: merge `feature-beta` into `feature-alpha`. - -These merge requests are usually handled in one of these ways: - -- Merge request 1 is merged into `main` first. Merge request 2 is then - retargeted to `main`. -- Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which - now contains the contents of `feature-alpha` and `feature-beta`, is merged into `main`. - -GitLab retargets up to four merge requests when their target branch is merged into -`main`, so you don't need to perform this operation manually. Merge requests from -forks are not retargeted. - -The feature today works only on merge. Clicking the **Remove source branch** button -after the merge request was merged will not automatically retarget a merge request. -This improvement is [tracked as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559). - ## Recommendations and best practices for merge requests - When working locally in your branch, add multiple commits and only push when diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index 510dcd82907..cac7aca7639 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -136,6 +136,35 @@ To delete a merge request: 1. Go to the merge request you want to delete, and select **Edit**. 1. Scroll to the bottom of the page, and select **Delete merge request**. +### Update merge requests when target branch merges **(FREE SELF)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. +> - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. +> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) GitLab 13.10. + +Merge requests are often chained together, with one merge request depending on +the code added or changed in another merge request. To support keeping individual +merge requests small, GitLab can update up to four open merge requests when their +target branch merges into `main`. For example: + +- **Merge request 1**: merge `feature-alpha` into `main`. +- **Merge request 2**: merge `feature-beta` into `feature-alpha`. + +If these merge requests are open at the same time, and merge request 1 (`feature-alpha`) +merges into `main`, GitLab updates the destination of merge request 2 from `feature-alpha` +to `main`. + +Merge requests with interconnected content updates are usually handled in one of these ways: + +- Merge request 1 is merged into `main` first. Merge request 2 is then + retargeted to `main`. +- Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which + now contains the contents of `feature-alpha` and `feature-beta`, is merged into `main`. + +This feature works only when a merge request is merged. Selecting **Remove source branch** +after merging does not retarget open merge requests. This improvement is +[proposed as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559). + ## Request attention to a merge request > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/343528) in GitLab 14.10 [with a flag](../../../administration/feature_flags.md) named `mr_attention_requests`. Disabled by default. |