Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/related_issues/index.js

@@ -17,6 +17,8 @@ export function initRelatedIssues(issueType = 'issue') {
     provide: {
       fullPath: el.dataset.fullPath,
       hasIssueWeightsFeature: parseBoolean(el.dataset.hasIssueWeightsFeature),
+      hasIterationsFeature: parseBoolean(el.dataset.hasIterationsFeature),
+      projectNamespace: el.dataset.projectNamespace,
     },
     render: (createElement) =>
       createElement(RelatedIssuesRoot, {

app/views/projects/issues/_related_issues.html.haml

@@ -4,4 +4,6 @@
     full_path: @project.full_path,
     has_issue_weights_feature: @project.licensed_feature_available?(:issue_weights).to_s,
     help_path: help_page_path('user/project/issues/related_issues'),
-    show_categorized_issues: @project.licensed_feature_available?(:blocked_issues).to_s } }
+    show_categorized_issues: @project.licensed_feature_available?(:blocked_issues).to_s,
+    project_namespace: @project.namespace.path,
+    has_iterations_feature: @project.licensed_feature_available?(:iterations).to_s } }

db/migrate/20221103131409_add_partial_index_on_primary_key_of_security_scans.rb

@@ -0,0 +1,15 @@
+# frozen_string_literal: true
+
+class AddPartialIndexOnPrimaryKeyOfSecurityScans < Gitlab::Database::Migration[2.0]
+  INDEX_NAME = :index_security_scans_on_id_for_non_purged_records
+  PURGED_STATE = 6
+  disable_ddl_transaction!
+
+  def up
+    add_concurrent_index :security_scans, :id, where: "status != #{PURGED_STATE}", name: INDEX_NAME
+  end
+
+  def down
+    remove_concurrent_index_by_name :security_scans, INDEX_NAME
+  end
+end

db/schema_migrations/20221103131409

@@ -0,0 +1 @@
+cb301b88dc9b0f5bffd9d1a4419c5923e8145cb8770e576d88dc7881c1c9e39c

db/structure.sql

@@ -30479,6 +30479,8 @@ CREATE INDEX index_security_scans_on_created_at ON security_scans USING btree (c
 
 CREATE INDEX index_security_scans_on_date_created_at_and_id ON security_scans USING btree (date(timezone('UTC'::text, created_at)), id);
 
+CREATE INDEX index_security_scans_on_id_for_non_purged_records ON security_scans USING btree (id) WHERE (status <> 6);
+
 CREATE INDEX index_security_scans_on_length_of_errors ON security_scans USING btree (pipeline_id, jsonb_array_length(COALESCE((info -> 'errors'::text), '[]'::jsonb)));
 
 CREATE INDEX index_security_scans_on_length_of_warnings ON security_scans USING btree (pipeline_id, jsonb_array_length(COALESCE((info -> 'warnings'::text), '[]'::jsonb)));

doc/security/two_factor_authentication.md

@@ -99,7 +99,7 @@ This is a permanent and irreversible action. Users must reactivate 2FA to use it
 
 ### For a single user
 
-To disable 2FA for non-administrator users, we recommend using the [API endpoint](../api/users.md#disable-two-factor-authentication)
+To disable 2FA for non-administrator users, you should use the [API endpoint](../api/users.md#disable-two-factor-authentication)
 instead of the Rails console.
 Using the [Rails console](../administration/operations/rails_console.md), 2FA for a single user can be disabled.
 Connect to the Rails console and run:
@@ -113,7 +113,6 @@ user_to_disable = User.find_by_username('<USERNAME>')
 TwoFactor::DestroyService.new(admin, user: user_to_disable).execute
 ```
 
-NOTE:
 The target user is notified that 2FA has been disabled.
 
 ### For all users

doc/subscriptions/self_managed/index.md

@@ -463,10 +463,9 @@ apply, contact [GitLab Support](https://support.gitlab.com/hc/en-us/requests/new
 
 ### Check daily and historical billable users
 
-You can get a list of daily and historical billable users in your GitLab instance.
-
-1. [Start a rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
+Administrators can get a list of daily and historical billable users in your GitLab instance.
 
+1. [Start a Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
 1. Count the number of users in the instance:
 
    ```ruby
@@ -481,17 +480,16 @@ You can get a list of daily and historical billable users in your GitLab instanc
 
 ### Update daily billable and historical users
 
-You can trigger a manual update of the daily and historical billable users in your GitLab instance.
-
-1. [Start a rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
+Administrators can trigger a manual update of the daily and historical billable users in your GitLab instance.
 
+1. [Start a Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
 1. Force an update of the daily billable users:
 
    ```ruby
    identifier = Analytics::UsageTrends::Measurement.identifiers[:billable_users]
    ::Analytics::UsageTrends::CounterJobWorker.new.perform(identifier, User.minimum(:id), User.maximum(:id), Time.zone.now)
    ```
-   
+
 1. Force an update of the historical max billable users:
 
    ```ruby

doc/user/admin_area/moderate_users.md

@@ -288,7 +288,9 @@ Before 15.1, additionally groups of which deleted user were the only owner among
 
 When moderating users, you may need to perform bulk actions on them based on certain conditions. The following rails console scripts show some examples of this. You may [start a rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session) and use scripts similar to the following:
 
-### Deactivate Users that have no recent activity
+### Deactivate users that have no recent activity
+
+Administrators can deactivate users that have no recent activity.
 
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
@@ -303,7 +305,9 @@ inactive_users.each do |user|
 end
 ```
 
-### Block Users that have no recent activity
+### Block users that have no recent activity
+
+Administrators can block users that have no recent activity.
 
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
@@ -316,9 +320,11 @@ inactive_users.each do |user|
     puts "user '#{user.username}': #{user.last_activity_on}"
     user.block!
 end
-``` 
+```
 
-### Block or Delete Users that have no projects or groups
+### Block or delete users that have no projects or groups
+
+Administrators can block or delete users that have no projects or groups.
 
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

doc/user/admin_area/settings/sign_in_restrictions.md

@@ -32,27 +32,70 @@ In the event of an external authentication provider outage, use the [GitLab Rail
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2158) in GitLab 13.10.
 
-When this feature is enabled, instance administrators are limited as regular users. During that period,
-they do not have access to all projects, groups, or the **Admin Area** menu.
+If you are an administrator, you might want to work in GitLab without the access that
+comes from being an administrator. While you could create a separate user account that
+doesn't have administrator access, a more secure solution is to use *Admin Mode*.
 
-To access potentially dangerous resources, an administrator can activate Admin Mode by:
+With Admin Mode, your account does not have administrative access by default.
+You can continue to access groups and projects you are a member of, but to access
+administrative functionality, you must authenticate.
 
-- Selecting the *Enable Admin Mode* button
-- Trying to access any part of the UI that requires administrator access, specifically those which call `/admin` endpoints.
+When Admin Mode is enabled, it applies to all administrators on the instance.
 
-The main use case allows administrators to perform their regular tasks as a regular
-user, based on their memberships, without having to set up a second account for
-security reasons.
+When Admin Mode is enabled for an instance, administrators:
 
-When Admin Mode status is disabled, administrative users cannot access resources unless
-they've been explicitly granted access. For example, when Admin Mode is disabled, they
-get a `404` error if they try to open a private group or project, unless
-they are members of that group or project.
+- Are allowed to access group and projects for which they are members.
+- Cannot access the **Admin Area**.
 
-2FA should be enabled for administrators and is supported for the Admin Mode flow, as are
-OmniAuth providers and LDAP auth. The Admin Mode status is stored in the active user
-session and remains active until it is explicitly disabled (it will be disabled
-automatically after a timeout otherwise).
+### Enable Admin Mode for your instance
+
+Administrators can enable Admin Mode though the API, the Rails console, or the UI.
+
+#### Use the API to enable Admin Mode
+
+Make the following request to your instance endpoint:
+
+```shell
+curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab.example.com>/api/v4/application/settings?admin_mode=true"
+```
+
+Replace `<gitlab.example.com>` with your instance URL.
+
+For more information, see the [list of settings that can be accessed through API calls](../../../api/settings.md).
+
+#### Use the Rails console to enable Admin Mode
+
+Open the [Rails console](../../../administration/operations/rails_console.md) and run the following:
+
+```ruby
+::Gitlab::CurrentSettings.update_attributes!(admin_mode: true)
+```
+
+#### Use the UI to enable Admin Mode
+
+To enable Admin Mode through the UI:
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Sign-in restrictions**.
+1. In the **Admin Mode** section, select the **Require additional authentication for administrative tasks** checkbox.
+
+### Turn on Admin Mode for your session
+
+To turn on Admin Mode for your current session and access potentially dangerous resources:
+
+1. On the top bar, select **Enable Admin Mode**.
+1. Try to access any part of the UI with `/admin` in the URL (which requires administrator access).
+
+When Admin Mode status is disabled or turned off, administrators cannot access resources unless
+they've been explicitly granted access. For example, administrators get a `404` error
+if they try to open a private group or project, unless they are members of that group or project.
+
+2FA should be enabled for administrators. 2FA, OmniAuth providers, and LDAP
+authentication are supported by Admin Mode. Admin Mode status is stored in the current user session and remains active until either:
+
+- It is explicitly disabled.
+- It is disabled automatically after a timeout.
 
 ### Limitations of Admin Mode
 

doc/user/application_security/dependency_scanning/index.md

@@ -1310,6 +1310,11 @@ gemnasium-python-dependency_scanning:
     - apt-get update && apt-get install -y libpq-dev
 ```
 
+### `NoSuchOptionException` when using `poetry config http-basic` with `CI_JOB_TOKEN`
+
+This error can occur when the automatically generated `CI_JOB_TOKEN` starts with a hyphen (`-`).
+To avoid this error, follow [Poetry's configuration advice](https://python-poetry.org/docs/repositories/#configuring-credentials).
+
 ### Error: Project has `<number>` unresolved dependencies
 
 The error message `Project has <number> unresolved dependencies` indicates a dependency resolution problem caused by your `gradle.build` or `gradle.build.kts` file. In the current release, `gemnasium-maven` cannot continue processing when an unresolved dependency is encountered. However, There is an [open issue](https://gitlab.com/gitlab-org/gitlab/-/issues/337083) to allow `gemnasium-maven` to recover from unresolved dependency errors and produce a dependency graph. Until this issue has been resolved, you'll need to consult the [Gradle dependency resolution docs](https://docs.gradle.org/current/userguide/dependency_resolution.html) for details on how to fix your `gradle.build` file.

doc/user/group/manage.md

@@ -652,16 +652,21 @@ Commands that change data can cause damage if not run correctly or under the rig
 GroupDestroyWorker.new.perform(group_id, user_id)
 ```
 
-### Find a user's max permissions for a group or project
+### Find a user's maximum permissions for a group or project
 
-```ruby
-user = User.find_by_username 'username'
-project = Project.find_by_full_path 'group/project'
-user.max_member_access_for_project project.id
-```
+Administrators can find a user's maximum permissions for a group or project.
 
-```ruby
-user = User.find_by_username 'username'
-group = Group.find_by_full_path 'group'
-user.max_member_access_for_group group.id
-```
+1. Start a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
+1. Run the following commands:
+
+   ```ruby
+   user = User.find_by_username 'username'
+   project = Project.find_by_full_path 'group/project'
+   user.max_member_access_for_project project.id
+   ```
+
+   ```ruby
+   user = User.find_by_username 'username'
+   group = Group.find_by_full_path 'group'
+   user.max_member_access_for_group group.id
+   ```

doc/user/profile/account/create_accounts.md

@@ -55,10 +55,13 @@ Users are:
 WARNING:
 Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
 
-To create a user through the rails console, [start a console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session) and run the following commands:
+To create a user through the Rails console:
 
-```ruby
-u = User.new(username: 'test_user', email: 'test@example.com', name: 'Test User', password: 'password', password_confirmation: 'password')
-u.skip_confirmation! # Use it only if you wish user to be automatically confirmed. If skipped, user receives confirmation e-mail
-u.save!
-```
+1. [Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+1. Run the following commands:
+
+   ```ruby
+   u = User.new(username: 'test_user', email: 'test@example.com', name: 'Test User', password: 'password', password_confirmation: 'password')
+   u.skip_confirmation! # Use it only if you wish user to be automatically confirmed. If skipped, user receives confirmation e-mail
+   u.save!
+   ```

spec/support/redis.rb

@@ -19,4 +19,10 @@ RSpec.configure do |config|
       public_send("redis_#{underscored_name}_cleanup!")
     end
   end
+
+  config.before(:suite) do
+    Gitlab::Redis::ALL_CLASSES.each do |instance_class|
+      instance_class.with(&:flushdb)
+    end
+  end
 end