Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/vue_shared/components/markdown/suggestion_diff_header.vue

@@ -139,7 +139,7 @@ export default {
       <gl-loading-icon size="sm" class="d-flex-center mr-2" />
       <span>{{ applyingSuggestionsMessage }}</span>
     </div>
-    <div v-else-if="canApply" class="d-flex align-items-center">
+    <div v-else-if="isLoggedIn" class="d-flex align-items-center">
       <div v-if="isBatched">
         <gl-button
           class="btn-inverted js-remove-from-batch-btn btn-grouped"
@@ -149,9 +149,8 @@ export default {
           {{ __('Remove from batch') }}
         </gl-button>
       </div>
-      <div v-else>
+      <div v-else-if="!isDisableButton && suggestionsCount > 1">
         <gl-button
-          v-if="!isDisableButton && suggestionsCount > 1"
           class="btn-inverted js-add-to-batch-btn btn-grouped"
           data-qa-selector="add_suggestion_batch_button"
           :disabled="isDisableButton"

db/migrate/20210908195506_add_data_to_vulnerability_finding_evidence.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+class AddDataToVulnerabilityFindingEvidence < Gitlab::Database::Migration[1.0]
+  def change
+    add_column :vulnerability_finding_evidences, :data, :jsonb, default: {}, null: false
+  end
+end

db/schema_migrations/20210908195506

@@ -0,0 +1 @@
+1ad794ac96f6297203046562c2ec422fbb4d1818a65266bb92179096040f7d82

db/structure.sql

@@ -20382,6 +20382,7 @@ CREATE TABLE vulnerability_finding_evidences (
     updated_at timestamp with time zone NOT NULL,
     vulnerability_occurrence_id bigint NOT NULL,
     summary text,
+    data jsonb DEFAULT '{}'::jsonb NOT NULL,
     CONSTRAINT check_5773b236fb CHECK ((char_length(summary) <= 8000000))
 );
 

doc/administration/gitaly/troubleshooting.md

@@ -365,6 +365,15 @@ To determine the current primary Gitaly node for a specific Praefect node:
   curl localhost:9652/metrics | grep gitaly_praefect_primaries`
   ```
 
+### Check that repositories are in sync
+
+Is [some cases](index.md#known-issues) the Praefect database can get out of sync with the underlying Gitaly nodes. To check that
+a given repository is fully synced on all nodes, run the [`gitlab:praefect:replicas` Rake task](../raketasks/praefect.md#replica-checksums)
+that checksums the repository on all Gitaly nodes.
+
+The [Praefect dataloss](praefect.md#check-for-data-loss) command only checks the state of the repo in the Praefect database, and cannot
+be relied to detect sync problems in this scenario.
+
 ### Relation does not exist errors
 
 By default Praefect database tables are created automatically by `gitlab-ctl reconfigure` task.

doc/api/access_requests.md

@@ -2,13 +2,10 @@
 stage: Manage
 group: Access
 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"
-type: reference, api
 ---
 
 # Group and project access requests API **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/18583) in GitLab 8.11.
-
 ## Valid access levels
 
 The access levels are defined in the `Gitlab::Access` module, and the

doc/integration/kerberos.md

@@ -2,7 +2,6 @@
 stage: Manage
 group: Access
 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"
-type: reference, how-to
 ---
 
 # Kerberos integration **(PREMIUM SELF)**
@@ -296,7 +295,7 @@ Kerberos ticket-based authentication.
 
 ## Upgrading from password-based to ticket-based Kerberos sign-ins
 
-Prior to GitLab 8.10 Enterprise Edition, users had to submit their
+In previous versions of GitLab users had to submit their
 Kerberos username and password to GitLab when signing in. We plan to
 remove support for password-based Kerberos sign-ins in a future
 release, so we recommend that you upgrade to ticket-based sign-ins.

doc/user/group/subgroups/index.md

@@ -136,7 +136,7 @@ the **Members** page of the group the member was added.
 You can tell if a member has inherited the permissions from a parent group by
 looking at the group's **Members** page.
 
-![Group members page](img/group_members_13_7.png)
+![Group members page](img/group_members_v14_4.png)
 
 From the image above, we can deduce the following things:
 

doc/user/permissions.md

@@ -33,8 +33,6 @@ usernames. A GitLab administrator can configure the GitLab instance to
 
 ## Project members permissions
 
-> The Master role was renamed to Maintainer in GitLab 11.0.
-
 The Owner role is only available at the group or personal namespace level (and for instance administrators) and is inherited by its projects.
 While Maintainer is the highest project-level role, some actions can only be performed by a personal namespace or group owner, or an instance administrator, who receives all permissions.
 For more information, see [projects members documentation](project/members/index.md).
@@ -269,9 +267,6 @@ Find the visibility permissions for the Container Registry, as described in the
 
 ## Group members permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 Any user can remove themselves from a group, unless they are the last Owner of
 the group.
 
@@ -442,8 +437,6 @@ free guest user.
 
 ## Auditor users **(PREMIUM SELF)**
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/998) in [GitLab Premium](https://about.gitlab.com/pricing/) 8.17.
-
 Auditor users are given read-only access to all projects, groups, and other
 resources on the GitLab instance.
 
@@ -454,7 +447,7 @@ with the permissions described on the documentation on [auditor users permission
 
 ## Users with minimal access **(PREMIUM)**
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40942) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40942) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
 
 Owners can add members with a "minimal access" role to a parent group. Such users don't
 automatically have access to projects and subgroups underneath. To support such access, owners must explicitly add these "minimal access" users to the specific subgroups/projects.
@@ -480,9 +473,6 @@ which visibility level you select on project settings.
 
 ## GitLab CI/CD permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 GitLab CI/CD permissions rely on the role the user has in GitLab. There are four
 roles:
 
@@ -513,9 +503,6 @@ instance and project.
 
 ### Job permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 This table shows granted privileges for jobs triggered by specific types of
 users:
 
@@ -555,7 +542,7 @@ for more information.
 
 ## LDAP users permissions
 
-In GitLab 8.15 and later, LDAP user permissions can now be manually overridden by an administrator.
+LDAP user permissions can be manually overridden by an administrator.
 Read through the documentation on [LDAP users permissions](group/index.md#manage-group-memberships-via-ldap) to learn more.
 
 ## Project aliases

doc/user/profile/account/two_factor_authentication.md

@@ -1,5 +1,4 @@
 ---
-type: howto
 stage: Manage
 group: Access
 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
@@ -235,8 +234,6 @@ Feature.disable(:forti_token_cloud, User.find(<user ID>))
 
 ### U2F device
 
-> Introduced in [GitLab 8.9](https://about.gitlab.com/blog/2016/06/22/gitlab-adds-support-for-u2f/).
-
 GitLab officially only supports [YubiKey](https://www.yubico.com/products/)
 U2F devices, but users have successfully used [SoloKeys](https://solokeys.com/)
 or [Google Titan Security Key](https://cloud.google.com/titan-security-key).

doc/user/project/members/index.md

@@ -87,7 +87,7 @@ A success message is displayed and the new members are now displayed in the list
 When your project belongs to a group, group members inherit their role
 from the group.
 
-![Project members page](img/project_members_v13_9.png)
+![Project members page](img/project_members_v14_4.png)
 
 In this example:
 
@@ -140,7 +140,7 @@ You can filter and sort members in a project.
 1. In the **Filter members** box, select `Membership` `=` `Inherited`.
 1. Press Enter.
 
-![Project members filter inherited](img/project_members_filter_inherited_v13_9.png)
+![Project members filter inherited](img/project_members_filter_inherited_v14_4.png)
 
 ### Display direct members
 
@@ -148,19 +148,19 @@ You can filter and sort members in a project.
 1. In the **Filter members** box, select `Membership` `=` `Direct`.
 1. Press Enter.
 
-![Project members filter direct](img/project_members_filter_direct_v13_9.png)
+![Project members filter direct](img/project_members_filter_direct_v14_4.png)
 
 ### Search
 
 You can search for members by name, username, or email.
 
-![Project members search](img/project_members_search_v13_9.png)
+![Project members search](img/project_members_search_v14_4.png)
 
 ### Sort
 
 You can sort members by **Account**, **Access granted**, **Max role**, or **Last sign-in** in ascending or descending order.
 
-![Project members sort](img/project_members_sort_v13_9.png)
+![Project members sort](img/project_members_sort_v14_4.png)
 
 ## Request access to a project
 

locale/gitlab.pot

@@ -30340,6 +30340,9 @@ msgstr ""
 msgid "SecurityReports|Oops, something doesn't seem right."
 msgstr ""
 
+msgid "SecurityReports|Operational vulnerabilities"
+msgstr ""
+
 msgid "SecurityReports|Project"
 msgstr ""
 

spec/db/schema_spec.rb

@@ -204,7 +204,8 @@ RSpec.describe 'Database schema' do
     "Operations::FeatureFlags::Strategy" => %w[parameters],
     "Packages::Composer::Metadatum" => %w[composer_json],
     "RawUsageData" => %w[payload], # Usage data payload changes often, we cannot use one schema
-    "Releases::Evidence" => %w[summary]
+    "Releases::Evidence" => %w[summary],
+    "Vulnerabilities::Finding::Evidence" => %w[data] # Validation work in progress
   }.freeze
 
   # We are skipping GEO models for now as it adds up complexity

spec/frontend/vue_shared/components/markdown/suggestion_diff_header_spec.js

@@ -230,5 +230,14 @@ describe('Suggestion Diff component', () => {
       expect(tooltip.modifiers.viewport).toBe(true);
       expect(tooltip.value).toBe('This also resolves this thread');
     });
+
+    it('renders the inapplicable reason in the tooltip when button is not applicable', () => {
+      const inapplicableReason = 'lorem';
+      createComponent({ canApply: false, inapplicableReason, batchSuggestionsCount: 0 });
+      const tooltip = findTooltip();
+
+      expect(tooltip.modifiers.viewport).toBe(true);
+      expect(tooltip.value).toBe(inapplicableReason);
+    });
   });
 });