Add latest changes from gitlab-org/gitlab@master

6 files changed, 33 insertions, 19 deletions

diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 8efcd3c44c1..45568c700c7 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -44,7 +44,7 @@ A good example is as follows:
 ```ruby
 desc 'Get all broadcast messages' do
   detail 'This feature was introduced in GitLab 8.12.'
-  success Entities::BroadcastMessage
+  success Entities::System::BroadcastMessage
 end
 params do
   optional :page,     type: Integer, desc: 'Current page number'
@@ -53,7 +53,7 @@ end
 get do
   messages = System::BroadcastMessage.all
 
-  present paginate(messages), with: Entities::BroadcastMessage
+  present paginate(messages), with: Entities::System::BroadcastMessage
 end
 ```
 
diff --git a/doc/topics/manage_code.md b/doc/topics/manage_code.md
index 5e9160338a9..e8a4267973c 100644
--- a/doc/topics/manage_code.md
+++ b/doc/topics/manage_code.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Manage your code **(FREE)**
 
-Store your source files in a repository, create merge requests, and compile code hosted on GitLab.
+Store your source files in a repository and create merge requests. Write, debug, and compile code hosted on GitLab.
 
 - [Repositories](../user/project/repository/index.md)
 - [Merge requests](../user/project/merge_requests/index.md)
diff --git a/doc/user/application_security/policies/scan-result-policies.md b/doc/user/application_security/policies/scan-result-policies.md
index 0aac36988d4..211ea811d29 100644
--- a/doc/user/application_security/policies/scan-result-policies.md
+++ b/doc/user/application_security/policies/scan-result-policies.md
@@ -77,6 +77,12 @@ the following sections and tables provide an alternative.
 
 ## `scan_finding` rule type
 
+> - The scan result policy field `vulnerability_attributes` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123052) in GitLab 16.2 [with a flag](../../../administration/feature_flags.md) named `enforce_vulnerability_attributes_rules`. Disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/418784) in GitLab 16.3.
+
+FLAG:
+On self-managed GitLab, by default the `vulnerability_attributes` field is available. To hide the feature, an administrator can [disable the feature flag](../../../administration/feature_flags.md) named `enforce_vulnerability_attributes_rules`.
+On GitLab.com, this feature is available.
 This rule enforces the defined actions based on security scan findings.
 
 | Field | Type | Required | Possible values | Description |
@@ -88,6 +94,7 @@ This rule enforces the defined actions based on security scan findings.
 | `vulnerabilities_allowed` | `integer` | true | Greater than or equal to zero | Number of vulnerabilities allowed before this rule is considered. |
 | `severity_levels` | `array` of `string` | true | `info`, `unknown`, `low`, `medium`, `high`, `critical` | The severity levels for this rule to consider. |
 | `vulnerability_states` | `array` of `string` | true | `newly_detected`, `detected`, `confirmed`, `resolved`, `dismissed`, `new_needs_triage`, `new_dismissed` | All vulnerabilities fall into two categories:<br><br>**Newly Detected Vulnerabilities** - the `newly_detected` policy option covers vulnerabilities identified in the merge request branch itself but that do not currently exist on the default branch. This policy option requires a pipeline to complete before the rule is evaluated so that it knows whether vulnerabilities are newly detected or not. Merge requests are blocked until the pipeline and necessary security scans are complete. The `newly_detected` option considers both of the following statuses:<br><br> • Detected<br> • Dismissed<br><br> The `new_needs_triage` option considers the status<br><br> • Detected<br><br> The `new_dismissed` option considers the status<br><br> • Dismissed<br><br>**Pre-Existing Vulnerabilities** - these policy options are evaluated immediately and do not require a pipeline complete as they consider only vulnerabilities previously detected in the default branch.<br><br> • `Detected` - the policy looks for vulnerabilities in the detected state.<br> • `Confirmed` - the policy looks for vulnerabilities in the confirmed state.<br> • `Dismissed` - the policy looks for vulnerabilities in the dismissed state.<br> • `Resolved` - the policy looks for vulnerabilities in the resolved state. |
+| `vulnerability_attributes` | `object` | false | `{false_positive: boolean, fix_available: boolean}` | All vulnerability findings are considered by default. But filters can be applied for attributes to consider only vulnerability findings: <br><br> • With a fix available (`fix_available: true`)<br><br> • With no fix available (`fix_available: false`)<br> • That are false positive (`false_positive: true`)<br> • That are not false positive (`false_positive: false`)<br> • Or a combination of both. For example (`fix_available: true, false_positive: false`) |
 
 ## `license_finding` rule type
 
@@ -150,6 +157,9 @@ scan_result_policy:
     - critical
     vulnerability_states:
     - newly_detected
+    vulnerability_attributes:
+      false_positive: true
+      fix_available: true
   actions:
   - type: require_approval
     approvals_required: 1
diff --git a/doc/user/group/saml_sso/troubleshooting_scim.md b/doc/user/group/saml_sso/troubleshooting_scim.md
index e4531882fc1..7d2aa8faa99 100644
--- a/doc/user/group/saml_sso/troubleshooting_scim.md
+++ b/doc/user/group/saml_sso/troubleshooting_scim.md
@@ -40,41 +40,43 @@ To check if a user's SAML `NameId` matches their SCIM `externalId`:
 
 - Administrators can use the Admin Area to [list SCIM identities for a user](../../../administration/admin_area.md#user-identities).
 - Group owners can see the list of users and the identifier stored for each user in the group SAML SSO Settings page.
-- You can use the [SCIM API](../../../api/scim.md) to manually retrieve the `external_uid` GitLab has stored for users and compare the value for each user from the [SAML API](../../../api/saml.md) .
-- Have the user use a [SAML Tracer](troubleshooting.md#saml-debugging-tools) and compare the `external_uid` to
+- You can use the [SCIM API](../../../api/scim.md) to manually retrieve the `extern_uid` GitLab has stored for users and compare the value for each user from the [SAML API](../../../api/saml.md) .
+- Have the user use a [SAML Tracer](troubleshooting.md#saml-debugging-tools) and compare the `extern_uid` to
   the value returned as the SAML `NameId`.
 
 ## Mismatched SCIM `extern_uid` and SAML `NameId`
 
 Whether the value was changed or you need to map to a different field, the following must map to the same field:
 
-- `id`
 - `externalId`
 - `NameId`
 
-If the GitLab `extern_uid` doesn't match the SAML `NameId`, it must be updated for the user to sign in. Your identity
-provider should be configured to do this update. In some cases the identity provider cannot do the update, for example
-when a user lookup fails because of an ID change.
+If the GitLab `extern_uid` does not match the SAML `NameId`, you must update the GitLab `extern_uid` to enable the user to sign in.
 
-Be cautious if you revise the fields used by your SCIM identity provider, typically `id` and `externalId`.
-GitLab uses these IDs to look up users. If the identity provider does not know the current values for these fields,
-that provider may create duplicate users.
+Be cautious if you revise the fields used by your SCIM identity provider, typically `externalId`.
+Your identity provider should be configured to do this update.
+In some cases the identity provider cannot do the update, for example when a user lookup fails.
 
-If the `extern_uid` for a user is not correct, and also doesn't match the SAML `NameID`, either:
+GitLab uses these IDs to look up users.
+If the identity provider does not know the current values for these fields,
+that provider may create duplicate users, or fail to complete expected actions.
 
-- Have users unlink and relink themselves, based on the
+To change the identifier values to match:
+
+1. Have users unlink and relink themselves, based on the
   [SAML authentication failed: User has already been taken](troubleshooting.md#message-saml-authentication-failed-user-has-already-been-taken)
   section.
-- Unlink all users simultaneously by removing all users from the SCIM app while provisioning is turned on.
-- Use the [SCIM API](../../../api/scim.md) to manually correct the `extern_uid` stored for users to match the SAML
-  `NameId`. To look up a user, you must know the desired value that matches the `NameId` as well as the current
-  `extern_uid`.
+1. Unlink all users simultaneously by removing all users from the SCIM app while provisioning is turned on.
+1. Use the [SAML API](../../../api/saml.md) or [SCIM API](../../../api/scim.md) to manually correct the `extern_uid` stored for users to match the SAML
+  `NameId` or SCIM `externalId`.
 
 You must not:
 
 - Update these to incorrect values because this causes users to be unable to sign in.
 - Assign a value to the wrong user because this causes users to be signed in to the wrong account.
 
+Additionally, the user's primary email must match the email in your SCIM identity provider.
+
 ## Change SCIM app
 
 When the SCIM app changes:
diff --git a/doc/user/project/merge_requests/commit_templates.md b/doc/user/project/merge_requests/commit_templates.md
index c930c5c6f7f..0da7bb2537f 100644
--- a/doc/user/project/merge_requests/commit_templates.md
+++ b/doc/user/project/merge_requests/commit_templates.md
@@ -72,6 +72,7 @@ GitLab creates a squash commit message with this template:
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/26303) `all_commits` variable in GitLab 14.9.
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/378352) `reviewed_by` variable in GitLab 15.7.
 > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/199823) `local_reference` variable in GitLab 16.1.
+> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128553) `source_project_id` variables in GitLab 16.3.
 
 Commit message templates support these variables:
 
@@ -84,6 +85,7 @@ Commit message templates support these variables:
 | `%{description}`   | Description of the merge request. | `Merge request description.`<br>`Can be multiline.` |
 | `%{reference}`     | Reference to the merge request. | `group-name/project-name!72359` |
 | `%{local_reference}` | Local reference to the merge request. | `!72359` |
+| `%{source_project_id}` | ID of the merge request's source project. | `123` |
 | `%{first_commit}`  | Full message of the first commit in merge request diff. | `Update README.md` |
 | `%{first_multiline_commit}` | Full message of the first commit that's not a merge commit and has more than one line in message body. Merge request title if all commits aren't multiline. | `Update README.md`<br><br>`Improved project description in readme file.` |
 | `%{url}`           | Full URL to the merge request. | `https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1` |
diff --git a/doc/user/project/remote_development/index.md b/doc/user/project/remote_development/index.md
index ccb1745d490..a0020199766 100644
--- a/doc/user/project/remote_development/index.md
+++ b/doc/user/project/remote_development/index.md
@@ -34,7 +34,7 @@ With remote development, you can use:
 
 For a complete IDE experience, connect the Web IDE to a development environment configured to run as a remote host. You can create this environment [inside](../../workspace/index.md) or [outside](connect_machine.md) of GitLab.
 
-## Workspace
+## Workspaces **(PREMIUM)**
 
 A [workspace](../../workspace/index.md) is a virtual sandbox environment for your code in GitLab that includes: