Add latest changes from gitlab-org/gitlab@master

.gitlab/issue_templates/Bug.md

@@ -88,6 +88,20 @@ will also determine whether the bug is fixed in a more recent version. -->
 
 <!-- If you can, link to the line of code that might be responsible for the problem. -->
 
+### Patch release information for backports
+
+If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version
+under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the
+[patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md).
+
+Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1)
+for information about the next patch release, including the targeted versions, expected release date, and current status.
+
+#### High-severity bug remediation
+
+To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances,
+refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).
+
 /label ~"type::bug"
 <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->
 

.rubocop_todo/capybara/visibility_matcher.yml

@@ -43,7 +43,6 @@ Capybara/VisibilityMatcher:
     - 'spec/features/users/email_verification_on_login_spec.rb'
     - 'spec/features/users/overview_spec.rb'
     - 'spec/features/users/user_browses_projects_on_user_page_spec.rb'
-    - 'spec/features/webauthn_spec.rb'
     - 'spec/support/helpers/features/canonical_link_helpers.rb'
     - 'spec/support/shared_examples/features/discussion_comments_shared_example.rb'
     - 'spec/support/shared_examples/features/page_description_shared_examples.rb'

app/assets/javascripts/batch_comments/components/review_drawer.vue

@@ -153,6 +153,9 @@ export default {
       'discardDrafts',
       'clearDrafts',
     ]),
+    isOnLatestDiff(draft) {
+      return draft.position?.head_sha === this.getNoteableData.diff_head_sha;
+    },
     async onClickDraft(draft) {
       if (this.viewDiffsFileByFile) {
         await this.goToFile({ path: draft.file_path });

app/assets/javascripts/ci/pipeline_details/graph/components/job_group_dropdown.vue

@@ -118,16 +118,16 @@ export default {
       <button
         type="button"
         :class="[cssClassJobName, { 'ci-job-item-failed': isFailed }]"
-        class="gl-w-full gl-bg-transparent gl-pr-4"
+        class="gl-bg-transparent"
       >
-        <div class="gl-flex gl-items-stretch gl-justify-between">
+        <div class="gl-flex gl-items-center gl-justify-between">
           <job-item
             :type="$options.jobItemTypes.jobDropdown"
             :job="group"
             :stage-name="stageName"
             hide-tooltip
           />
-          <gl-badge variant="muted" class="-gl-ml-5 -gl-mr-2 gl-self-center">
+          <gl-badge variant="muted">
             {{ group.size }}
           </gl-badge>
         </div>

app/assets/javascripts/ci/pipeline_details/graph/components/job_item.vue

@@ -335,7 +335,7 @@ export default {
       :title="tooltipText"
       :href="detailsPath"
       :class="jobClasses"
-      class="menu-item gl-w-full gl-rounded-base gl-text-strong hover:gl-bg-strong hover:gl-no-underline focus:gl-bg-strong focus:gl-no-underline active:gl-no-underline dark:hover:gl-bg-gray-200 dark:focus:gl-bg-gray-200"
+      class="!gl-no-underline"
       data-testid="ci-job-item-content"
       @click="jobItemClick"
       @mouseout="hideTooltips"

app/assets/javascripts/ci/pipeline_details/graph/components/stage_column_component.vue

@@ -77,17 +77,7 @@ export default {
       required: true,
     },
   },
-  jobClasses: [
-    'gl-p-3',
-    'gl-border-0',
-    '!gl-rounded-base',
-    'hover:gl-bg-strong',
-    'dark:hover:gl-bg-gray-200',
-    'focus:gl-bg-strong',
-    'dark:focus:gl-bg-gray-200',
-    'hover:gl-text-strong',
-    'focus:gl-text-strong',
-  ],
+  jobClasses: ['gl-w-full', 'gl-p-3', 'gl-border-0', '!gl-rounded-base', 'pipeline-job-action'],
   data() {
     return {
       showConfirmationModal: false,

app/assets/stylesheets/page_bundles/pipeline.scss

@@ -110,9 +110,23 @@
   min-height: calc(#{$dropdown-max-height-lg} + #{$gl-spacing-scale-6});
 }
 
+.pipeline-job-action {
+  &:hover {
+    background-color: var(--gl-action-neutral-background-color-hover);
+  }
+
+  &:focus {
+    background-color: var(--gl-action-neutral-background-color-focus);
+  }
+
+  &:active {
+    background-color: var(--gl-action-neutral-background-color-active);
+  }
+}
+
 // stylelint-disable-next-line gitlab/no-gl-class
 .gl-pipeline-job-width {
-  width: 100%;
+  @apply gl-w-full;
   max-width: 400px;
 
   .pipeline-graph-container & {

config/gitlab_loose_foreign_keys.yml

@@ -167,6 +167,10 @@ ci_runner_projects:
   - table: projects
     column: project_id
     on_delete: async_delete
+ci_runner_taggings:
+  - table: tags
+    column: tag_id
+    on_delete: async_delete
 ci_runner_taggings_group_type:
   - table: namespaces
     column: sharding_key_id

data/deprecations/14-8-compliance-required-pipeline-configuration-premium.yml

@@ -6,7 +6,7 @@
   body: |  # Do not modify this line, instead modify the lines below.
     The [required pipeline configuration](https://docs.gitlab.com/administration/settings/continuous_integration/#required-pipeline-configuration-deprecated) feature is deprecated in GitLab 14.8 for Premium customers and is scheduled for removal in GitLab 15.0. This feature is not deprecated for GitLab Ultimate customers.
 
-    This change to move the feature to GitLab Ultimate tier is intended to help our features better align with our [pricing philosophy](https://handbook.gitlab.com/handbook/company/pricing/#three-tiers) as we see demand for this feature originating primarily from executives.
+    This change to move the feature to GitLab Ultimate tier is intended to help our features better align with our pricing philosophy as we see demand for this feature originating primarily from executives.
 
     This change will also help GitLab remain consistent in its tiering strategy with the other related Ultimate-tier features of:
     [Security policies](https://docs.gitlab.com/user/application_security/policies/) and [compliance framework pipelines](https://docs.gitlab.com/user/project/settings/#compliance-pipeline-configuration).

data/deprecations/14-8-sast-analyzer-removals.yml

@@ -7,7 +7,7 @@
     GitLab SAST uses various [analyzers](https://docs.gitlab.com/user/application_security/sast/analyzers/) to scan code for vulnerabilities.
 
     We are reducing the number of analyzers used in GitLab SAST as part of our long-term strategy to deliver a better and more consistent user experience.
-    Streamlining the set of analyzers will also enable faster [iteration](https://handbook.gitlab.com/handbook/values/#iteration), better [results](https://handbook.gitlab.com/handbook/values/#results), and greater [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) (including a reduction in CI runner usage in most cases).
+    Streamlining the set of analyzers will also enable faster iteration, better results, and greater efficiency (including a reduction in CI runner usage in most cases).
 
     In GitLab 15.4, GitLab SAST will no longer use the following analyzers:
 
@@ -21,7 +21,7 @@
     These analyzers will be removed from the [GitLab-managed SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) and replaced with the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep).
     Effective immediately, they will receive only security updates; other routine improvements or updates are not guaranteed.
     After these analyzers reach End of Support, no further updates will be provided.
-    We will not delete container images previously published for these analyzers; any such change would be announced as a [deprecation, removal, or breaking change announcement](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes).
+    We will not delete container images previously published for these analyzers; any such change would be announced as a deprecation, removal, or breaking change announcement.
 
     We will also remove Java from the scope of the [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) analyzer and replace it with the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep).
     This change will make it simpler to scan Java code; compilation will no longer be required.

data/deprecations/15-8-third-party-registries.yml

@@ -8,7 +8,7 @@
   body: |  # (required) Do not modify this line, instead modify the lines below.
     Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts users on GitLab Self-Managed that have connected their external registry to the GitLab user interface to find, view, and delete container images.
 
-    Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://handbook.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
+    Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility, and hinders our ability to stay efficient. As a result we will not support this functionality moving forward.
 
     This change will not impact your ability to pull and push container images to external registries using pipelines.
 

db/migrate/20250514150058_add_active_column_to_external_audit_event_destinations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToExternalAuditEventDestinations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_external_audit_event_destinations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_external_audit_event_destinations, :active
+  end
+end

db/migrate/20250514150138_add_active_column_to_amazon_s3_configurations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToAmazonS3Configurations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_amazon_s3_configurations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_amazon_s3_configurations, :active
+  end
+end

db/migrate/20250514150201_add_active_column_to_google_cloud_logging_configurations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToGoogleCloudLoggingConfigurations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_google_cloud_logging_configurations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_google_cloud_logging_configurations, :active
+  end
+end

db/migrate/20250514150707_add_active_column_to_group_external_streaming_destinations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToGroupExternalStreamingDestinations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_group_external_streaming_destinations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_group_external_streaming_destinations, :active
+  end
+end

db/migrate/20250514152911_add_active_column_to_instance_external_audit_event_destination.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToInstanceExternalAuditEventDestination < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_instance_external_audit_event_destinations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_instance_external_audit_event_destinations, :active
+  end
+end

db/migrate/20250514152921_add_active_column_to_instance_amazon_s3_configurations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToInstanceAmazonS3Configurations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_instance_amazon_s3_configurations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_instance_amazon_s3_configurations, :active
+  end
+end

db/migrate/20250514152941_add_active_column_to_instance_external_streaming_destinations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToInstanceExternalStreamingDestinations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_instance_external_streaming_destinations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_instance_external_streaming_destinations, :active
+  end
+end

db/migrate/20250514152958_add_active_column_to_instance_google_cloud_logging_configurations.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class AddActiveColumnToInstanceGoogleCloudLoggingConfigurations < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def up
+    add_column :audit_events_instance_google_cloud_logging_configurations, :active, :boolean, null: false, default: true
+  end
+
+  def down
+    remove_column :audit_events_instance_google_cloud_logging_configurations, :active
+  end
+end

db/migrate/20250514220951_add_validity_checks_enabled_to_project_security_settings.rb

@@ -0,0 +1,10 @@
+# frozen_string_literal: true
+
+class AddValidityChecksEnabledToProjectSecuritySettings < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  def change
+    add_column :project_security_settings, :validity_checks_enabled, :boolean, null: false,
+      default: false
+  end
+end

db/post_migrate/20250508094430_drop_tags_foreign_key_on_ci_runner_taggings.rb

@@ -0,0 +1,22 @@
+# frozen_string_literal: true
+
+class DropTagsForeignKeyOnCiRunnerTaggings < Gitlab::Database::Migration[2.3]
+  include Gitlab::Database::PartitioningMigrationHelpers::ForeignKeyHelpers
+
+  disable_ddl_transaction!
+  milestone '18.1'
+
+  TAGGINGS_TABLE = :ci_runner_taggings
+  FK_NAME = :fk_rails_6d510634c7
+
+  def up
+    with_lock_retries do
+      remove_foreign_key_if_exists(TAGGINGS_TABLE, name: FK_NAME)
+    end
+  end
+
+  def down
+    add_concurrent_partitioned_foreign_key TAGGINGS_TABLE, :tags, name: FK_NAME, column: :tag_id,
+      on_delete: :cascade
+  end
+end

db/post_migrate/20250514161148_cleanup_bigint_conversion_for_pkgs_terraform_module_metadata_semver_patch.rb

@@ -0,0 +1,16 @@
+# frozen_string_literal: true
+
+class CleanupBigintConversionForPkgsTerraformModuleMetadataSemverPatch < Gitlab::Database::Migration[2.3]
+  milestone '18.1'
+
+  TABLE = :packages_terraform_module_metadata
+  COLUMN = :semver_patch
+
+  def up
+    cleanup_conversion_of_integer_to_bigint(TABLE, COLUMN)
+  end
+
+  def down
+    restore_conversion_of_integer_to_bigint(TABLE, COLUMN)
+  end
+end

db/schema_migrations/20250508094430

@@ -0,0 +1 @@
+76e71c5ce5d5d18bb34e466bd046cc6ed0df80cc7baf65b9491199c071353e6d

db/schema_migrations/20250514150058

@@ -0,0 +1 @@
+4ef746635c683b5f79753a5f038b6e991ea91e245f490e0cb24b3a5f773a157f

db/schema_migrations/20250514150138

@@ -0,0 +1 @@
+6e377f334ba24148900b2be615536cbf76c7f5d1cbe9f1bc4bce6aad8e984f72

db/schema_migrations/20250514150201

@@ -0,0 +1 @@
+30e156a02697a1b3b2577ec6c581cbca78ffe00a2a7a8d6ff52a9947e043a4d2

db/schema_migrations/20250514150707

@@ -0,0 +1 @@
+d756bf56cf4a1b9799c4afbe348ee29dc87de596e59fd6fea6d4e0a41df5d7f1

db/schema_migrations/20250514152911

@@ -0,0 +1 @@
+7f2870649c103ad4a5c537532f808d8525d7f24333d35d4e21da352a0cab99f1

db/schema_migrations/20250514152921

@@ -0,0 +1 @@
+9c917959a926e546fd6f7588e88a7d5c7e17a7a78fa8debfade37c91aec7f708

db/schema_migrations/20250514152941

@@ -0,0 +1 @@
+b15723b276542b3ee17e33c49e7232a876293b2af3931e61563c66abaa976540

db/schema_migrations/20250514152958

@@ -0,0 +1 @@
+f7ef28330c8d8ad5ccf5d5ba15dddda5290a0c99d6106d86c5ae191d66f27b6f

db/schema_migrations/20250514161148

@@ -0,0 +1 @@
+5a515f8cd2100cb0e098a9be9b401d5e1e20f4afda55ef41ff9e5e58d0dd6a93

db/schema_migrations/20250514220951

@@ -0,0 +1 @@
+5066fcfc16857f3b7013d132e86346155e5cd4c6c2b079ce9af7edd9c8225e9f

db/structure.sql

@@ -3854,20 +3854,6 @@ RETURN NEW;
 END
 $$;
 
-CREATE FUNCTION trigger_dd7cb7bd6c9e() RETURNS trigger
-    LANGUAGE plpgsql
-    AS $$
-DECLARE
-  row_data JSONB;
-BEGIN
-  row_data := to_jsonb(NEW);
-  IF row_data ? 'semver_patch_convert_to_bigint' THEN
-    NEW."semver_patch_convert_to_bigint" := NEW."semver_patch";
-  END IF;
-  RETURN NEW;
-END;
-$$;
-
 CREATE FUNCTION trigger_de59b81d3044() RETURNS trigger
     LANGUAGE plpgsql
     AS $$
@@ -9537,6 +9523,7 @@ CREATE TABLE audit_events_amazon_s3_configurations (
     encrypted_secret_access_key bytea NOT NULL,
     encrypted_secret_access_key_iv bytea NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_3a41f4ea06 CHECK ((char_length(bucket_name) <= 63)),
     CONSTRAINT check_72b5aaa71b CHECK ((char_length(aws_region) <= 50)),
     CONSTRAINT check_90505816db CHECK ((char_length(name) <= 72)),
@@ -9561,6 +9548,7 @@ CREATE TABLE audit_events_external_audit_event_destinations (
     verification_token text,
     name text NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_2feafb9daf CHECK ((char_length(destination_url) <= 255)),
     CONSTRAINT check_8ec80a7d06 CHECK ((char_length(verification_token) <= 24)),
     CONSTRAINT check_c52ff8e90e CHECK ((char_length(name) <= 72))
@@ -9587,6 +9575,7 @@ CREATE TABLE audit_events_google_cloud_logging_configurations (
     encrypted_private_key_iv bytea NOT NULL,
     name text NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_0ef835c61e CHECK ((char_length(client_email) <= 254)),
     CONSTRAINT check_55783c7c19 CHECK ((char_length(google_project_id_name) <= 30)),
     CONSTRAINT check_898a76b005 CHECK ((char_length(log_id_name) <= 511)),
@@ -9613,6 +9602,7 @@ CREATE TABLE audit_events_group_external_streaming_destinations (
     encrypted_secret_token bytea NOT NULL,
     encrypted_secret_token_iv bytea NOT NULL,
     legacy_destination_ref bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_97d157fbd0 CHECK ((char_length(name) <= 72))
 );
 
@@ -9664,6 +9654,7 @@ CREATE TABLE audit_events_instance_amazon_s3_configurations (
     encrypted_secret_access_key bytea NOT NULL,
     encrypted_secret_access_key_iv bytea NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_1a908bd36f CHECK ((char_length(name) <= 72)),
     CONSTRAINT check_8083750c42 CHECK ((char_length(bucket_name) <= 63)),
     CONSTRAINT check_d2ca3eb90e CHECK ((char_length(aws_region) <= 50)),
@@ -9688,6 +9679,7 @@ CREATE TABLE audit_events_instance_external_audit_event_destinations (
     encrypted_verification_token_iv bytea NOT NULL,
     name text NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_433fbb3305 CHECK ((char_length(name) <= 72)),
     CONSTRAINT check_4dc67167ce CHECK ((char_length(destination_url) <= 255))
 );
@@ -9711,6 +9703,7 @@ CREATE TABLE audit_events_instance_external_streaming_destinations (
     encrypted_secret_token bytea NOT NULL,
     encrypted_secret_token_iv bytea NOT NULL,
     legacy_destination_ref bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_219decfb51 CHECK ((char_length(name) <= 72))
 );
 
@@ -9734,6 +9727,7 @@ CREATE TABLE audit_events_instance_google_cloud_logging_configurations (
     encrypted_private_key bytea NOT NULL,
     encrypted_private_key_iv bytea NOT NULL,
     stream_destination_id bigint,
+    active boolean DEFAULT true NOT NULL,
     CONSTRAINT check_0da5c76c49 CHECK ((char_length(client_email) <= 254)),
     CONSTRAINT check_74fd943192 CHECK ((char_length(log_id_name) <= 511)),
     CONSTRAINT check_ab65f57721 CHECK ((char_length(google_project_id_name) <= 30)),
@@ -19623,7 +19617,6 @@ CREATE TABLE packages_terraform_module_metadata (
     fields jsonb NOT NULL,
     semver_major integer,
     semver_minor integer,
-    semver_patch_convert_to_bigint integer,
     semver_prerelease text,
     semver_patch bigint,
     CONSTRAINT check_46aa6c883a CHECK ((char_length(semver_prerelease) <= 255)),
@@ -21213,6 +21206,7 @@ CREATE TABLE project_security_settings (
     container_scanning_for_registry_enabled boolean DEFAULT false NOT NULL,
     pre_receive_secret_detection_enabled boolean DEFAULT false NOT NULL,
     secret_push_protection_enabled boolean DEFAULT false,
+    validity_checks_enabled boolean DEFAULT false NOT NULL,
     CONSTRAINT check_20a23efdb6 CHECK ((secret_push_protection_enabled IS NOT NULL))
 );
 
@@ -41549,8 +41543,6 @@ CREATE TRIGGER trigger_dbe374a57cbb BEFORE INSERT OR UPDATE ON status_page_publi
 
 CREATE TRIGGER trigger_dc13168b8025 BEFORE INSERT OR UPDATE ON vulnerability_flags FOR EACH ROW EXECUTE FUNCTION trigger_dc13168b8025();
 
-CREATE TRIGGER trigger_dd7cb7bd6c9e BEFORE INSERT OR UPDATE ON packages_terraform_module_metadata FOR EACH ROW EXECUTE FUNCTION trigger_dd7cb7bd6c9e();
-
 CREATE TRIGGER trigger_de59b81d3044 BEFORE INSERT OR UPDATE ON bulk_import_export_batches FOR EACH ROW EXECUTE FUNCTION trigger_de59b81d3044();
 
 CREATE TRIGGER trigger_delete_project_namespace_on_project_delete AFTER DELETE ON projects FOR EACH ROW WHEN ((old.project_namespace_id IS NOT NULL)) EXECUTE FUNCTION delete_associated_project_namespace();
@@ -44770,9 +44762,6 @@ ALTER TABLE ONLY vulnerability_management_policy_rules
 ALTER TABLE ONLY ml_model_version_metadata
     ADD CONSTRAINT fk_rails_6b8fcb2af1 FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
 
-ALTER TABLE ci_runner_taggings
-    ADD CONSTRAINT fk_rails_6d510634c7 FOREIGN KEY (tag_id) REFERENCES tags(id) ON DELETE CASCADE;
-
 ALTER TABLE ONLY term_agreements
     ADD CONSTRAINT fk_rails_6ea6520e4a FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
 

doc/.vale/gitlab_base/OutdatedVersions.yml

@@ -10,4 +10,4 @@ level: suggestion
 nonword: true
 ignorecase: true
 tokens:
-  - "GitLab v?(2[^0-9]|[4-9]|1[0-4])"
+  - "GitLab v?(2[^0-9]|[4-9]|1[0-5])"

doc/administration/guest_users.md

@@ -73,4 +73,3 @@ Users with the Guest role cannot:
 - Modify existing data that they have not created.
 - View code in GitLab projects by default.
 - Create projects, groups, and snippets in their personal namespaces.
-- Access internal or private projects or groups without administrator access.

doc/api/oauth2.md

@@ -414,7 +414,7 @@ detailed flow description.
 Resource owner password credentials are disabled for users with
 [two-factor authentication](../user/profile/account/two_factor_authentication.md) turned on
 and [enterprise users](../user/enterprise_user/_index.md)
-with [password authentication disabled for their group](../user/enterprise_user/_index.md#disable-authentication-methods).
+with [password authentication disabled for their group](../user/enterprise_user/_index.md#restrict-authentication-methods).
 These users can access the API using [personal access tokens](../user/profile/personal_access_tokens.md)
 instead.
 {{< /alert >}}

doc/development/ai_features/availability.md

@@ -0,0 +1,279 @@
+---
+stage: AI-powered
+group: AI Framework
+info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
+title: GitLab Duo Feature Availability and Configuration
+---
+
+This document explains how GitLab Duo features are controlled, who can access them, and how they are configured across GitLab deployments.
+
+## Controlling GitLab Duo Feature Availability
+
+Various settings control when and how users can interact with GitLab Duo features. The
+[end-user documentation](../../user/gitlab_duo/turn_on_off.md) explains this from a
+user perspective. This document explains the implementation logic from a
+developer perspective and includes technical details.
+
+### UI Options and Database States
+
+In the UI, the "GitLab Duo Enterprise availability" setting shows 3 options:
+
+1. **On by default** - Features are enabled and child entities inherit this setting
+1. **Off by default** - Features are disabled but can be overridden by child entities
+1. **Always off** - Features are disabled and cannot be overridden by child entities
+
+These UI options map directly to the following database states:
+
+| UI Option | `duo_features_enabled` | `lock_duo_features_enabled` |
+|-----------|------------------------|----------------------------|
+| On by default | `true` | `false` |
+| Off by default | `false` | `false` |
+| Always off | `false` | `true` |
+
+### Cascading Settings Implementation
+
+The `duo_features_enabled` setting is a [cascading setting](../cascading_settings.md), which impacts how GitLab Duo features are propagated through the hierarchy.
+
+This cascading behavior means:
+
+1. The setting can be configured at any level: instance, group, subgroup, or project
+1. For GitLab.com, the instance-wide setting is always `true`
+1. Child entities can override their parent's setting. For example:
+   - An instance with `duo_features_enabled: false` can have a group with `duo_features_enabled: true`
+   - A group with `duo_features_enabled: true` can have a subgroup with `duo_features_enabled: false`
+1. When the setting is `true` at a parent level, all child entities are reset to `true`
+1. When the setting is `false` at a parent level, all child entities are reset to `false`
+1. A parent entity can "lock" the setting using `lock_duo_features_enabled: true` (displayed as "Always off" in the UI)
+   - When locked, child entities *cannot* override the parent setting
+   - This effectively disables GitLab Duo features for the entire hierarchy below that point
+
+## Feature Accessibility By Context
+
+### Where Users Can Access GitLab Duo Features
+
+Users with a paid GitLab Duo license (Duo Pro or Duo Enterprise) can access Chat and Code Suggestions in both the Web UI and IDE for:
+
+1. Resources that cannot disable GitLab Duo features:
+   - [Personal GitLab namespaces and projects](https://gitlab.com/gitlab-org/gitlab/-/issues/493850#note_2128888470)
+   - Free tier GitLab groups and projects
+   - Premium and Ultimate groups and projects without a paid GitLab Duo license
+
+1. Resources where GitLab Duo features are enabled:
+   - In GitLab Self-Managed and GitLab Dedicated: Groups or projects in an instance with a paid GitLab Duo license
+   - In GitLab.com: Groups or projects in a group with a paid GitLab Duo license
+
+### Additional IDE Access Scenarios
+
+In the IDE environment specifically, users with a GitLab Duo license can always use Chat and Code Suggestions for:
+
+1. Repositories without Git configuration
+1. Repositories with Git configuration pointing to unknown origins (such as GitHub or other GitLab instances where the user is not authenticated)
+
+## Platform-Specific Behavior
+
+### GitLab.com License Assignment
+
+On GitLab.com, a GitLab Duo license is associated with the individual user to
+whom it is assigned, not the group that assigned the seat. User accounts on
+GitLab.com are independent entities that belong to the entire GitLab instance
+rather than being "owned" by any specific group.
+
+#### Impact on Feature Availability
+
+Disabling GitLab Duo features (`duo_features_enabled: false`) in a group:
+
+- Does not revoke GitLab Duo access for group members who have GitLab Duo licenses
+- Only prevents licensed users from using GitLab Duo features with resources belonging to that group
+
+#### Example Scenario
+
+If a user has a GitLab Duo license but belongs to a group where GitLab Duo features are set to "Always off", they can still:
+
+- Use GitLab Duo Chat for questions about issues in free projects
+- Use Code Suggestions on their personal projects
+- Ask GitLab Duo Chat general coding questions or questions about GitLab
+- Use GitLab Duo features with resources from other groups where GitLab Duo features are enabled
+
+This flow diagram shows how GitLab Duo feature availability works on GitLab.com:
+
+```mermaid
+flowchart TD
+    A[Start] --> B{Member of Premium/Ultimate group?}
+    B -->|No| C[Cannot use GitLab Duo]
+    B -->|Yes| D{Has Duo Pro/Enterprise license?}
+    D -->|No| E[Cannot use GitLab Duo]
+    D -->|Yes| F{Using Duo with specific\ngroup/project resource?}
+    F -->|No| G[Can use GitLab Duo]
+    F -->|Yes| H{Group/Project has\nDuo features enabled?}
+    H -->|No| I[Cannot use Duo with\nthis resource]
+    H -->|Yes| J[Can use Duo with\nthis resource]
+```
+
+#### GitLab.com with Duo Core, Duo Pro, and Duo Enterprise
+
+GitLab offers three tiers of AI functionality:
+
+1. **Duo Core** - Basic AI capabilities
+1. **Duo Pro** - Enhanced AI capabilities with more advanced features
+1. **Duo Enterprise** - Comprehensive AI capabilities with additional controls and features
+
+##### Duo Core Configuration
+
+With the introduction of Duo Core, a new setting is available for top-level Premium and Ultimate groups.
+
+This setting allows group owners to control Duo Core availability:
+
+- When Duo Core is enabled ("on"): Every member of the group automatically receives a Duo Core seat
+- When Duo Core is disabled ("off"): No members of the group have Duo Core seats
+
+##### Feature Availability by License Tier
+
+| Feature | Duo Core | Duo Pro | Duo Enterprise |
+|---------|----------|---------|----------------|
+| Chat | Limited to IDE | Full functionality | Full functionality |
+| Code Suggestions | Availble in IDE and Web IDE | Available in IDE and Web IDE | Available in IDE and Web IDE |
+| Additional AI features | Not available | Some Available | All Available |
+
+This flow diagram shows how GitLab Duo feature availability works on GitLab.com with
+Duo Core settings taken into consideration:
+
+```mermaid
+flowchart TD
+    A[Start] --> B{Member of Premium/Ultimate group?}
+    B -->|No| C[Cannot use GitLab Duo]
+    B -->|Yes| D{Has Duo Pro/Enterprise license?}
+    D -->|Yes| E[Can use GitLab Duo]
+    D -->|No| F{Any Premium/Ultimate group has\nDuo Core enabled?}
+    F -->|No| G[Cannot use GitLab Duo]
+    F -->|Yes| H{Using Chat or\nCode Suggestions in IDE?}
+    H -->|No| I[Cannot use GitLab Duo]
+    H -->|Yes| J{Using Duo with specific\ngroup/project resource?}
+    J -->|No| K[Can use GitLab Duo]
+    J -->|Yes| L{Group/Project has\nDuo features enabled?}
+    L -->|Yes| M[Can use Duo with\nthis resource]
+    L -->|No| N[Cannot use Duo with\nthis resource]
+```
+
+### Configuration Locations
+
+#### GitLab.com Settings Pages
+
+The following settings pages are available for configuring GitLab Duo on GitLab.com:
+
+##### Admin Level
+
+- `/admin/gitlab_duo`
+  - Onboard GitLab Duo Workflow
+
+##### Top-Level Group Settings
+
+- `/groups/$GROUP_FULL_PATH/-/settings/gitlab_duo`
+  - Assign paid GitLab Duo seats (if available)
+  - Access GitLab Duo Configuration
+- `/groups/$GROUP_PATH/-/settings/gitlab_duo/configuration`
+  - Configure GitLab Duo availability ("On by default", "Off by default", or "Always off")
+  - Enable experimental and beta GitLab Duo features
+
+##### Subgroup Settings
+
+- `/groups/$GROUP_FULL_PATH/-/edit`
+  - Configure GitLab Duo availability for the subgroup and all its children
+
+##### Project Settings
+
+- `/$PROJECT_FULL_PATH/edit`
+  - Under "Visibility, project features, permissions" section
+  - Configure GitLab Duo availability for the specific project
+
+### GitLab Self-Managed and Dedicated Instances
+
+For Premium and Ultimate GitLab Self-Managed and Dedicated instances, the feature availability logic follows similar patterns as GitLab.com with one key difference:
+
+Instance administrators have the ability to set GitLab Duo features to "Always off" at the instance level. When configured this way, all GitLab Duo features are disabled for all users across the entire instance, regardless of individual license assignments.
+
+```mermaid
+flowchart TD
+    A[Start] --> B{Instance has Duo features\nset to 'Always off'?}
+    B -->|Yes| C[Cannot use GitLab Duo]
+    B -->|No| D{Has Duo Pro/Enterprise license?}
+    D -->|No| E[Cannot use GitLab Duo]
+    D -->|Yes| F{Using Duo with specific\ngroup/project resource?}
+    F -->|No| G[Can use GitLab Duo]
+    F -->|Yes| H{Group/Project has\nDuo features enabled?}
+    H -->|No| I[Cannot use Duo with\nthis resource]
+    H -->|Yes| J[Can use Duo with\nthis resource]
+```
+
+#### GitLab Self-Managed and Dedicated with Duo Core, Duo Pro, and Duo Enterprise
+
+##### Instance-Wide Duo Core Configuration
+
+For GitLab Self-Managed and Dedicated instances, Duo Core is controlled through an instance-level setting.
+This setting is available to all Premium and Ultimate instances.
+
+Instance administrators can:
+
+- Enable Duo Core ("on") - Every user in the instance automatically receives a Duo Core seat
+- Disable Duo Core ("off") - No users in the instance have Duo Core seats
+
+##### License Tier Differences in Self-Managed and Dedicated Instances
+
+The same feature differentiation between Duo Core, Duo Pro, and Duo Enterprise applies to self-managed and dedicated instances:
+
+- **Duo Core**: Basic AI capabilities limited to IDE use cases and general coding assistance
+- **Duo Pro**: Enhanced AI capabilities with broader feature access
+- **Duo Enterprise**: Comprehensive AI capabilities with additional enterprise controls
+
+Self-managed instances have additional configuration options for integrating with self-hosted AI models and controlling feature behavior.
+
+This flow diagram shows how Duo feature availability works on non-GitLab.com
+instances with Duo Core settings taken into consideration:
+
+```mermaid
+flowchart TD
+    A[Start] --> B{Instance has Duo features\nset to 'Always off'?}
+    B -->|Yes| C[Cannot use GitLab Duo]
+    B -->|No| D{Has Duo Pro/Enterprise license?}
+    D -->|Yes| E[Can use GitLab Duo]
+    D -->|No| F{Instance has Duo Core enabled?}
+    F -->|No| G[Cannot use GitLab Duo]
+    F -->|Yes| H{Using Chat or\nCode Suggestions in IDE?}
+    H -->|No| I[Cannot use GitLab Duo]
+    H -->|Yes| J{Using Duo with specific\ngroup/project resource?}
+    J -->|No| K[Can use GitLab Duo]
+    J -->|Yes| L{Group/Project has\nDuo features enabled?}
+    L -->|Yes| M[Can use Duo with\nthis resource]
+    L -->|No| N[Cannot use Duo with\nthis resource]
+```
+
+#### GitLab Self-Managed and Dedicated Settings Pages
+
+The following settings pages are available for configuring GitLab Duo on self-managed and dedicated instances:
+
+##### Instance Admin Settings
+
+- `/admin/gitlab_duo`
+  - Assign paid GitLab Duo seats to users
+  - Access GitLab Duo Configuration
+- `/admin/gitlab_duo/configuration`
+  - Configure instance-wide GitLab Duo availability
+  - Enable experimental and beta GitLab Duo features
+  - Configure Duo Chat conversation expiration periods
+  - Enable Code Suggestions direct connections
+  - Enable beta AI models for self-hosted deployments
+  - Configure AI logging settings
+  - Set AI Gateway URL for self-hosted deployments
+- `/admin/ai/duo_self_hosted`
+  - Configure self-hosted AI model integrations
+  - Select specific self-hosted models for different GitLab Duo features
+
+##### Group and Subgroup Settings
+
+- `/groups/$GROUP_FULL_PATH/-/edit`
+  - Configure GitLab Duo availability for the group and all its child entities
+
+##### Project Settings
+
+- `/$PROJECT_FULL_PATH/edit`
+  - Under "Visibility, project features, permissions" section
+  - Configure GitLab Duo availability for the specific project

doc/development/documentation/styleguide/_index.md

@@ -1013,6 +1013,11 @@ Sometimes they are more precise and will be maintained more actively.
 
 For each external link you add, weigh the customer benefit with the maintenance difficulties.
 
+### Links to handbook
+
+Limit links to the handbook. Some links are unavoidable, like licensing terms, data usage and access policies,
+testing agreements, and terms and conditions.
+
 ### Confidential or restricted access links
 
 Don't link directly to:

doc/development/documentation/styleguide/word_list.md

@@ -178,6 +178,17 @@ The token generated when you create an agent for Kubernetes. Use **agent access
 - secret token
 - authentication token
 
+## Agentic Chat, GitLab Duo Agentic Chat
+
+GitLab Duo Agentic Chat is an experimental, enhanced version of [GitLab Duo Chat](#chat-gitlab-duo-chat).
+
+Use **Agentic Chat** with a capital `a` and `c` for **Agentic Chat** or **GitLab Duo Agentic Chat**.
+
+On first use on a page, use **GitLab Duo Agentic Chat**.
+Thereafter, use **Agentic Chat** by itself.
+
+Do not use **Duo Agentic Chat**.
+
 ## agnostic
 
 Instead of **agnostic**, use **platform-independent** or **vendor-neutral**.
@@ -409,6 +420,11 @@ Instead of:
 
 ## Chat, GitLab Duo Chat
 
+GitLab Duo Chat is an AI-native assistant that helps developers with contextual,
+conversational code explanations, troubleshooting, and guidance.
+
+It is different from [GitLab Duo Agentic Chat](#agentic-chat-gitlab-duo-agentic-chat).
+
 Use **Chat** with a capital `c` for **Chat** or **GitLab Duo Chat**.
 
 On first use on a page, use **GitLab Duo Chat**.

doc/editor_extensions/visual_studio_code/_index.md

@@ -83,7 +83,7 @@ To select an account:
 1. Expand **Issues and Merge Requests**.
 1. Select the line containing **(multiple projects)** to expand the list of accounts.
 1. Select your desired project:
-   ![select project-account combination](../img/select-project-account_v17_7.png)
+   ![select project-account combination](img/select-project-account_v17_7.png)
 
 The **Issues and Merge requests** list updates with your selected project's information.
 
@@ -184,7 +184,7 @@ Use this extension to review, comment on, and approve merge requests without lea
 1. To review the proposed changes to a file, select the file from the list to show it in a VS Code tab.
    GitLab shows diff comments inline in the tab. In the list, deleted files are marked in red:
 
-   ![An alphabetical list of files changed in this merge request, including the change types.](../img/vscode_view_changed_file_v17_6.png)
+   ![An alphabetical list of files changed in this merge request, including the change types.](img/vscode_view_changed_file_v17_6.png)
 
 Use the diff to:
 

doc/editor_extensions/visual_studio_code/cicd.md

@@ -13,7 +13,7 @@ shows either:
 - The status of its most recent pipeline.
 - **No pipeline** if a pipeline hasn't run yet.
 
-![The bottom status bar, showing the most recent pipeline has failed.](../img/status_bar_pipeline_v17_6.png)
+![The bottom status bar, showing the most recent pipeline has failed.](img/status_bar_pipeline_v17_6.png)
 
 Possible statuses include:
 
@@ -49,7 +49,7 @@ To view pipeline information:
 
 This extension can display an alert in VS Code when a pipeline for your current branch completes:
 
-![Alert showing a pipeline failure](../img/pipeline_alert_v17_6.png)
+![Alert showing a pipeline failure](img/pipeline_alert_v17_6.png)
 
 To show alerts for your current Git branch:
 
@@ -66,7 +66,7 @@ To view the output for a CI/CD job for your current branch:
 1. On the sidebar, expand **For current branch** to show its most recent pipeline.
 1. Select your desired job to open it in a new VS Code tab:
 
-   ![A pipeline containing CI/CD jobs that are passing, allowed to fail, and failing.](../img/view_job_output_v17_6.png)
+   ![A pipeline containing CI/CD jobs that are passing, allowed to fail, and failing.](img/view_job_output_v17_6.png)
 
 ### Test GitLab CI/CD configuration
 
@@ -87,7 +87,7 @@ Use this command to see a preview of your merged CI/CD configuration file, with
 1. In VS Code, open your `.gitlab-ci.yml` file, and ensure the file's tab is in focus.
 1. On the top right, select **Show Merged GitLab CI/CD Configuration**:
 
-   ![The VS Code application, showing the icon for viewing merged results.](../img/show_merged_configuration_v17_6.png)
+   ![The VS Code application, showing the icon for viewing merged results.](img/show_merged_configuration_v17_6.png)
 
 VS Code opens a new tab (`.gitlab-ci (Merged).yml`) with full information.
 
@@ -107,4 +107,4 @@ To autocomplete a variable:
 1. Begin entering the name of a variable to display auto-complete options.
 1. Select an option to use it:
 
-   ![Autocomplete options shown for a string](../img/ci_variable_autocomplete_v16_6.png)
+   ![Autocomplete options shown for a string](img/ci_variable_autocomplete_v16_6.png)

doc/integration/advanced_search/elasticsearch.md

@@ -570,9 +570,17 @@ in your Sidekiq logs. For more information, see
 
 - Indexing all project records [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/428070) in GitLab 16.7 [with a flag](../../administration/feature_flags.md) named `search_index_all_projects`. Disabled by default.
 - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148111) in GitLab 16.11. Feature flag `search_index_all_projects` removed.
+- Indexing vulnerability records [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/536299) on GitLab.com and GitLab Dedicated in GitLab 18.1 [with a flag](../../administration/feature_flags.md) named `vulnerability_es_ingestion`. Disabled by default.
 
 {{< /history >}}
 
+{{< alert type="flag" >}}
+
+The availability of this feature is controlled by a feature flag.
+For more information, see the history.
+
+{{< /alert >}}
+
 When you select the **Limit the amount of namespace and project data to index** checkbox,
 you can specify namespaces and projects to index.
 If the namespace is a group, any subgroups and projects in these subgroups are also indexed.
@@ -581,6 +589,8 @@ When you enable this setting:
 
 - Namespaces or projects must be specified for full indexing.
 - Project records (metadata like project names and descriptions) are always indexed for all projects.
+- Vulnerability records are always indexed for all projects and namespaces
+  to support filtering in security reports.
 - [Associated data](#advanced-search-index-scopes) is indexed only for the namespaces and projects you specify.
 
 {{< alert type="warning" >}}
@@ -998,6 +1008,11 @@ When performing a search, the GitLab index uses the following scopes:
 | `users`          | Users                  |
 | `epics`          | Epic data              |
 
+On GitLab.com and GitLab Dedicated, vulnerability records are always indexed
+for all projects and namespaces to support features outside of search.
+Indexing vulnerability records on GitLab Self-Managed is proposed in
+[issue 525484](https://gitlab.com/gitlab-org/gitlab/-/issues/525484).
+
 ## Tuning
 
 ### Guidance on choosing optimal cluster configuration

doc/security/two_factor_authentication.md

@@ -186,6 +186,22 @@ when they next sign in to GitLab.
 
 {{< /alert >}}
 
+### For all users
+
+To disable 2FA for all users even when forced 2FA is disabled, use the following Rake task.
+
+- For installations that use the Linux package:
+
+  ```shell
+  sudo gitlab-rake gitlab:two_factor:disable_for_all_users
+  ```
+
+- For self-compiled installations:
+
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production
+  ```
+
 ### For a single user
 
 #### Administrators
@@ -212,21 +228,31 @@ You can disable 2FA for your own account.
 
 You cannot use the API endpoint to disable 2FA for administrators.
 
-### For all users
+#### Enterprise users
 
-To disable 2FA for all users even when forced 2FA is disabled, use the following Rake task.
+{{< details >}}
 
-- For installations that use the Linux package:
+- Tier: Premium, Ultimate
+- Offering: GitLab.com
 
-  ```shell
-  sudo gitlab-rake gitlab:two_factor:disable_for_all_users
-  ```
+{{< /details >}}
 
-- For self-compiled installations:
+{{< history >}}
 
-  ```shell
-  sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production
-  ```
+- [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9484) in GitLab 15.8.
+
+{{< /history >}}
+
+Top-level group Owners can disable two-factor authentication (2FA) for enterprise users.
+
+To disable 2FA:
+
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Manage > Members**.
+1. Find a user with the **Enterprise** and **2FA** badges.
+1. Select **More actions** ({{< icon name="ellipsis_v" >}}) and select **Disable two-factor authentication**.
+
+You can also [use the API](../api/group_enterprise_users.md#disable-two-factor-authentication-for-an-enterprise-user) to disable 2FA for enterprise users.
 
 ## 2FA for Git over SSH operations
 

doc/update/deprecations.md

@@ -5698,7 +5698,7 @@ You can use the `vulnerabilityFindingDismiss` GraphQL mutation to set the status
 
 Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts users on GitLab Self-Managed that have connected their external registry to the GitLab user interface to find, view, and delete container images.
 
-Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://handbook.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
+Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility, and hinders our ability to stay efficient. As a result we will not support this functionality moving forward.
 
 This change will not impact your ability to pull and push container images to external registries using pipelines.
 
@@ -6041,7 +6041,7 @@ This is not expected to cause any incompatibilities with the previous version of
 GitLab SAST uses various [analyzers](https://docs.gitlab.com/user/application_security/sast/analyzers/) to scan code for vulnerabilities.
 
 We are reducing the number of analyzers used in GitLab SAST as part of our long-term strategy to deliver a better and more consistent user experience.
-Streamlining the set of analyzers will also enable faster [iteration](https://handbook.gitlab.com/handbook/values/#iteration), better [results](https://handbook.gitlab.com/handbook/values/#results), and greater [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) (including a reduction in CI runner usage in most cases).
+Streamlining the set of analyzers will also enable faster iteration, better results, and greater efficiency (including a reduction in CI runner usage in most cases).
 
 In GitLab 15.4, GitLab SAST will no longer use the following analyzers:
 
@@ -6055,7 +6055,7 @@ This change was originally planned for GitLab 15.0 and was postponed to GitLab 1
 These analyzers will be removed from the [GitLab-managed SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) and replaced with the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep).
 Effective immediately, they will receive only security updates; other routine improvements or updates are not guaranteed.
 After these analyzers reach End of Support, no further updates will be provided.
-We will not delete container images previously published for these analyzers; any such change would be announced as a [deprecation, removal, or breaking change announcement](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes).
+We will not delete container images previously published for these analyzers; any such change would be announced as a deprecation, removal, or breaking change announcement.
 
 We will also remove Java from the scope of the [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) analyzer and replace it with the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep).
 This change will make it simpler to scan Java code; compilation will no longer be required.
@@ -6995,7 +6995,7 @@ For more information, check the [summary section of the deprecation issue](https
 
 The [required pipeline configuration](https://docs.gitlab.com/administration/settings/continuous_integration/#required-pipeline-configuration-deprecated) feature is deprecated in GitLab 14.8 for Premium customers and is scheduled for removal in GitLab 15.0. This feature is not deprecated for GitLab Ultimate customers.
 
-This change to move the feature to GitLab Ultimate tier is intended to help our features better align with our [pricing philosophy](https://handbook.gitlab.com/handbook/company/pricing/#three-tiers) as we see demand for this feature originating primarily from executives.
+This change to move the feature to GitLab Ultimate tier is intended to help our features better align with our pricing philosophy as we see demand for this feature originating primarily from executives.
 
 This change will also help GitLab remain consistent in its tiering strategy with the other related Ultimate-tier features of:
 [Security policies](https://docs.gitlab.com/user/application_security/policies/) and [compliance framework pipelines](https://docs.gitlab.com/user/project/settings/#compliance-pipeline-configuration).

doc/user/application_security/api_fuzzing/configuration/enabling_the_analyzer.md

@@ -428,15 +428,15 @@ requests. These placeholders are called variables, as explained in [using variab
 You can use variables to store and reuse values in your requests and scripts. For example, you can
 edit the collection to add variables to the document:
 
-![Edit collection variable tab View](../img/api_fuzzing_postman_collection_edit_variable_v13_9.png)
+![Edit collection variable tab View](img/api_fuzzing_postman_collection_edit_variable_v13_9.png)
 
 Or alternatively, you can add variables in an environment:
 
-![Edit environment variables View](../img/api_fuzzing_postman_environment_edit_variable_v13_9.png)
+![Edit environment variables View](img/api_fuzzing_postman_environment_edit_variable_v13_9.png)
 
 You can then use the variables in sections such as URL, headers, and others:
 
-![Edit request using variables View](../img/api_fuzzing_postman_request_edit_v13_9.png)
+![Edit request using variables View](img/api_fuzzing_postman_request_edit_v13_9.png)
 
 Postman has grown from a basic client tool with a nice UX experience to a more complex ecosystem that allows testing APIs with scripts, creating complex collections that trigger secondary requests, and setting variables along the way. Not every feature in the Postman ecosystem is supported. For example, scripts are not supported. The main focus of the Postman support is to ingest Postman Collection definitions that are used by the Postman Client and their related variables defined in the workspace, environments, and the collections themselves.
 

doc/user/application_security/api_security_testing/configuration/enabling_the_analyzer.md

@@ -359,15 +359,15 @@ requests. These placeholders are called variables, as explained in [using variab
 You can use variables to store and reuse values in your requests and scripts. For example, you can
 edit the collection to add variables to the document:
 
-![Edit collection variable tab View](../img/dast_api_postman_collection_edit_variable_v13_9.png)
+![Edit collection variable tab View](img/dast_api_postman_collection_edit_variable_v13_9.png)
 
 Or alternatively, you can add variables in an environment:
 
-![Edit environment variables View](../img/dast_api_postman_environment_edit_variable_v13_9.png)
+![Edit environment variables View](img/dast_api_postman_environment_edit_variable_v13_9.png)
 
 You can then use the variables in sections such as URL, headers, and others:
 
-![Edit request using variables View](../img/dast_api_postman_request_edit_v13_9.png)
+![Edit request using variables View](img/dast_api_postman_request_edit_v13_9.png)
 
 Postman has grown from a basic client tool with a nice UX experience to a more complex ecosystem that allows testing APIs with scripts, creating complex collections that trigger secondary requests, and setting variables along the way. Not every feature in the Postman ecosystem is supported. For example, scripts are not supported. The main focus of the Postman support is to ingest Postman Collection definitions that are used by the Postman Client and their related variables defined in the workspace, environments, and the collections themselves.
 

doc/user/application_security/dast/browser/configuration/authentication.md

@@ -404,10 +404,10 @@ Chrome DevTools element selector tool is an effective way to find a selector.
 1. Open Chrome and go to the page where you would like to find a selector, for example, the login page for your site.
 1. Open the `Elements` tab in Chrome DevTools with the keyboard shortcut `Command + Shift + c` in macOS or `Ctrl + Shift + c` in Windows or Linux.
 1. Select the `Select an element in the page to select it` tool.
-   ![search-elements](../img/dast_auth_browser_scan_search_elements_v16_9.png)
+   ![search-elements](img/dast_auth_browser_scan_search_elements_v16_9.png)
 1. Select the field on your page that you would like to know the selector for.
 1. After the tool is active, highlight a field you wish to view the details of.
-   ![highlight](../img/dast_auth_browser_scan_highlight_v16_9.png)
+   ![highlight](img/dast_auth_browser_scan_highlight_v16_9.png)
 1. Once highlighted, you can see the element's details, including attributes that would make a good candidate for a selector.
 
 In this example, the `id="user_login"` appears to be a good candidate. You can use this as a selector as the DAST username field by setting
@@ -578,7 +578,7 @@ An authentication report can be saved as a CI/CD job artifact to assist with und
 
 The report contains steps performed during the login process, HTTP requests and responses, the Document Object Model (DOM) and screenshots.
 
-![dast-auth-report](../img/dast_auth_report_v16_9.jpg)
+![dast-auth-report](img/dast_auth_report_v16_9.jpg)
 
 An example configuration where the authentication debug report is exported may look like the following:
 

doc/user/application_security/sast/gitlab_advanced_sast.md

@@ -221,7 +221,7 @@ The code flow information is shown the **Code flow** tab and includes:
 - The steps from source to sink.
 - The relevant files, including code snippets.
 
-![A code flow of a Python application across two files](../vulnerabilities/img/code_flow_view_v17_7.png)
+![A code flow of a Python application across two files](img/code_flow_view_v17_7.png)
 
 ## Troubleshooting
 

doc/user/clusters/agent/vulnerabilities.md

@@ -306,7 +306,7 @@ To view vulnerability information in GitLab:
 1. Select the **Agent** tab.
 1. Select an agent to view the cluster vulnerabilities.
 
-![Cluster agent security tab UI](../img/cluster_agent_security_tab_v14_8.png)
+![Cluster agent security tab UI](img/cluster_agent_security_tab_v14_8.png)
 
 This information can also be found under [operational vulnerabilities](../../application_security/vulnerability_report/_index.md#operational-vulnerabilities).
 

doc/user/enterprise_user/_index.md

@@ -16,19 +16,21 @@ description: Domain verification, two-factor authentication, enterprise user man
 Enterprise users have user accounts that are administered by an organization that
 has [verified their email domain](#verified-domains-for-groups) and purchased a [GitLab subscription](../../subscriptions/_index.md).
 
-Enterprise users are identified by the **Enterprise** badge
+Enterprise users are identified by the `Enterprise` badge
 next to their names on the [Members list](../group/_index.md#filter-and-sort-members-in-a-group).
 
+You can also [use the API](../../api/group_enterprise_users.md) to interact with enterprise users.
+
 ## Automatic claims of enterprise users
 
-A user is automatically claimed as an enterprise user of a group when **both** of the following conditions are met:
+A user is automatically claimed as an enterprise user of a group when both of the following conditions are met:
 
-1. The user's primary email has a domain that has been [verified](#verified-domains-for-groups) by the paid group.
-1. The user account meets at least **one** of the following conditions:
-   - It was created February 1, 2021 or later.
-   - It has a SAML or SCIM identity tied to the organization's group.
-   - It has a `provisioned_by_group_id` value that is the same as the organization's group's ID.
-   - It is a member of the organization's group, where the subscription was purchased or renewed February 1, 2021 or later.
+- The user's primary email has a domain that has been [verified](#verified-domains-for-groups) by the paid group.
+- The user account meets at least one of the following conditions:
+  - It was created February 1, 2021 or later.
+  - It has a SAML or SCIM identity tied to the organization's group.
+  - It has a `provisioned_by_group_id` value that is the same as the group ID of the organization.
+  - It is a member of the organization's group, where the subscription was purchased or renewed February 1, 2021 or later.
 
 After the user is claimed as an enterprise user:
 
@@ -38,31 +40,31 @@ After the user is claimed as an enterprise user:
 If a group's purchased subscription expires or is canceled:
 
 - Users claimed as enterprise users remain enterprise users of that group.
-- The group is not able to [manage their enterprise users](#manage-enterprise-users-in-a-namespace).
-- [Enterprise user restrictions](#enterprise-user-restrictions) apply to those user accounts.
+- The group is not able to [manage their enterprise users](#manage-enterprise-users).
+- Primary emails for user accounts must be from a verified domain.
 - No new users can be [automatically associated with the group](#automatic-claims-of-enterprise-users) until the paid subscription is renewed.
 
 If a group's verified domains are removed:
 
 - Users claimed as enterprise users remain enterprise users of that group.
-- [Enterprise user restrictions](#enterprise-user-restrictions) apply to those user accounts.
+- Primary emails for user accounts must be from a verified domain.
 - No new users can be [automatically associated with the group](#automatic-claims-of-enterprise-users) until domains are verified.
 
 If the organization moves its verified domains to another paid group, its enterprise users are [automatically claimed](#automatic-claims-of-enterprise-users) as enterprise users of that group.
 
 ### Identifying unclaimed users
 
-If a user is not automatically claimed as an Enterprise User, their existing access will not be revoked.
+If a user is not automatically claimed as an enterprise user, their existing access will not be revoked.
 A group with domain verification enabled can have both claimed and unclaimed users as members.
 
-The only difference between a member claimed as an Enterprise User and one that isn't is that a Group Owner cannot [manage unclaimed users](#manage-enterprise-users-in-a-namespace).
+The only difference between a member claimed as an enterprise user and a member that is not is that a Group Owner cannot [manage unclaimed users](#manage-enterprise-users).
 
-### Identifying group members that have not been claimed as Enterprise users
+### Identifying group members that have not been claimed as enterprise users
 
 Groups that enable domain verification can have both claimed and unclaimed users as members.
 Unclaimed users retain their existing access, but are not managed by group Owners.
 
-See [Manage enterprise users in a namespace](#manage-enterprise-users-in-a-namespace).
+See [Manage enterprise users in a namespace](#manage-enterprise-users).
 
 You can discover any unclaimed users in your group by accessing and analyzing your list of billable
 users at: `https://gitlab.com/groups/<group_id>/-/usage_quotas#seats-quota-tab`.
@@ -75,17 +77,6 @@ From this list, unclaimed users one of the following:
 To claim these users, they must update their primary email address to match the verified domain.
 These users are automatically claimed when the next scheduled claim worker runs.
 
-## Enterprise user restrictions
-
-### Primary email change
-
-An enterprise user can only change their primary email to an email their organization owns as per its verified domains.
-If an organization removes all its verified domains, its enterprise users are not able to change their primary email address.
-
-Only GitLab administrators can change enterprise users' primary email address to an email with a non-verified domain.
-
-Providing the ability to group Owners to change their enterprise users' primary email to an email with a non-verified domain is proposed in [issue 412966](https://gitlab.com/gitlab-org/gitlab/-/issues/412966).
-
 ## Verified domains for groups
 
 The following automated processes use verified domains to run:
@@ -159,7 +150,7 @@ A valid certificate is not required for domain verification. You can ignore erro
 After you create a new domain, the verification code prompts you. Copy the values from GitLab
 and paste them in your domain's control panel as a `TXT` record.
 
-![Get the verification code](../img/get_domain_verification_code_v16_0.png)
+![Get the verification code](img/get_domain_verification_code_v16_0.png)
 
 #### 3. Verify the domain's ownership
 
@@ -169,7 +160,7 @@ After you have added all the DNS records:
 1. Select **Settings > Domain Verification**.
 1. On the domain table row, Select **Retry verification** ({{< icon name="retry" >}}).
 
-![Verify your domain](../img/retry_domain_verification_v16_0.png)
+![Verify your domain](img/retry_domain_verification_v16_0.png)
 
 {{< alert type="warning" >}}
 
@@ -210,30 +201,58 @@ To edit or remove a domain:
 1. When viewing **Domain Verification**, select the project listed next to the relevant domain.
 1. Edit or remove a domain following the relevant [GitLab Pages custom domains](../project/pages/custom_domains_ssl_tls_certification/_index.md) instructions.
 
-## Manage enterprise users in a namespace
+## Manage enterprise users
 
-A top-level Owner of a namespace on a paid plan can retrieve information about and
-manage enterprise user accounts in that namespace.
+In addition to the standard [group member permissions](../permissions.md#group-members-permissions),
+Owners of a top-level group can also manage enterprise users in their group.
 
-These enterprise user-specific actions are in addition to the standard
-[group member permissions](../permissions.md#group-members-permissions).
+### Restrict authentication methods
 
-### Disable two-factor authentication
+You can restrict the specific authentication methods available to enterprise users, which can help
+reduce the security footprint of your users.
 
-{{< history >}}
+- [Disable password authentication](../group/saml_sso/_index.md#disable-password-authentication-for-enterprise-users).
+- [Disable personal access tokens](../../user/profile/personal_access_tokens.md#disable-personal-access-tokens-for-enterprise-users).
+- [Disable two-factor authentication](../../security/two_factor_authentication.md#enterprise-users).
 
-- [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9484) in GitLab 15.8.
+### Restrict group and project creation
 
-{{< /history >}}
+You can restrict group and project creation for enterprise users, which helps you define:
 
-Top-level group Owners can disable two-factor authentication (2FA) for enterprise users.
+- If enterprise users can create top-level groups.
+- The maximum number of personal projects each enterprise user can create.
 
-To disable 2FA:
+These restrcitions are defined in the SAML response. For more information, see [configure enterprise user settings from the SAML response](../group/saml_sso/_index.md#configure-enterprise-user-settings-from-saml-response).
 
-1. On the left sidebar, select **Search or go to** and find your group.
+### Bypass email confirmation for provisioned users
+
+By default, users provisioned with SAML or SCIM are sent a verification email to verify their identity. Instead, you can configure GitLab with a custom domain and GitLab automatically confirms user accounts. Users still receive an enterprise user welcome email.
+
+For more information, see [bypass user email confirmation with verified domains](../group/saml_sso/_index.md#bypass-user-email-confirmation-with-verified-domains).
+
+### View the email addresses for an enterprise user
+
+A top-level group Owner can use the UI to access enterprise users' email addresses:
+
+1. On the left sidebar, select **Search or go to** and find your project or group.
 1. Select **Manage > Members**.
-1. Find a user with the **Enterprise** and **2FA** badges.
-1. Select **More actions** ({{< icon name="ellipsis_v" >}}) and select **Disable two-factor authentication**.
+1. In the group or project members page, hover over the enterprise user's name to
+   see their email address.
+
+A group Owner can also use the [group and project members API](../../api/members.md)
+to access users' information. For enterprise users of the group, this information
+includes users' email addresses.
+
+### Release an enterprise user
+
+It's possible to remove enterprise management features from a user account. This might be required if, for
+example, a user wants to keep their GitLab account after leaving their company. Releasing a user
+does not alter their account roles or permissions, but does remove the management options
+for the group Owner.
+
+To release the user, GitLab support must update the user's primary email address to an email address from a non-verified domain. This action automatically releases the account.
+
+Allowing group Owners to change primary emails is proposed in [issue 412966](https://gitlab.com/gitlab-org/gitlab/-/issues/412966).
 
 ### Enable the extension marketplace for the Web IDE and workspaces
 
@@ -278,51 +297,10 @@ To enable the extension marketplace for the
 1. Under **Web IDE and workspaces**, select the **Enable extension marketplace** checkbox.
 1. Select **Save changes**.
 
-### Prevent enterprise users from creating groups and projects outside the corporate group
-
-A SAML identity administrator can configure the SAML response to set:
-
-- Whether enterprise users can create new top-level groups.
-- The maximum number of personal projects enterprise users can create.
-
-For more information, see how to [configure enterprise user settings from the SAML response](../group/saml_sso/_index.md#configure-enterprise-user-settings-from-saml-response).
-
-### Bypass email confirmation for provisioned users
-
-A top-level group Owner can [set up verified domains to bypass confirmation emails](../group/saml_sso/_index.md#bypass-user-email-confirmation-with-verified-domains).
-
-### Get users' email addresses
-
-A top-level group Owner can use the UI to access enterprise users' email addresses:
-
-1. On the left sidebar, select **Search or go to** and find your project or group.
-1. Select **Manage > Members**.
-1. In the group or project members page, hover over the enterprise user's name to
-   see their email address.
-
-A group Owner can also use the [group and project members API](../../api/members.md)
-to access users' information. For enterprise users of the group, this information
-includes users' email addresses.
-
-### Remove enterprise management features from an account
-
-Changing an enterprise user's primary email to an email from a non-verified domain automatically removes the enterprise badge from the account. This does not alter any account roles or permissions for the user, but does limit the group Owner's ability to manage this account.
-
-### Disable authentication methods
-
-A top-level group Owner can disable specific authentication methods to reduce the security footprint.
-
-Within the top-level group, the Owner can:
-
-- [Disable password authentication](../group/saml_sso/_index.md#disable-password-authentication-for-enterprise-users).
-- [Disable personal access tokens](../../user/profile/personal_access_tokens.md#disable-personal-access-tokens-for-enterprise-users).
-
-## Related topics
-
-- [Group enterprise users API](../../api/group_enterprise_users.md)
-
 ## Troubleshooting
 
 ### Cannot disable two-factor authentication for an enterprise user
 
-If an enterprise user does not have an **Enterprise** badge, a top-level group Owner cannot [disable or reset 2FA](#disable-two-factor-authentication) for that user. Instead, the Owner should tell the enterprise user to consider available [recovery options](../profile/account/two_factor_authentication_troubleshooting.md#recovery-options-and-2fa-reset).
+If a user does not have an **Enterprise** badge, a group Owner cannot disable or reset 2FA for their
+account. Instead, the Owner should tell the enterprise user to consider available
+[recovery options](../profile/account/two_factor_authentication_troubleshooting.md#recovery-options-and-2fa-reset).

doc/user/group/epics/epic_boards.md

@@ -107,7 +107,7 @@ To create a new list:
 1. Select **New list**.
    The new list panel opens.
 
-   ![creating a new list between two lists in an issue board](../../project/img/issue_board_add_list_between_lists_v17_6.png)
+   ![creating a new list between two lists in an issue board](img/issue_board_add_list_between_lists_v17_6.png)
 1. In the **New list** column expand the **Select a label** dropdown list and select the label to use as
    list scope.
 1. Select **Add to board**.

doc/user/packages/terraform_module_registry/_index.md

@@ -19,52 +19,48 @@ title: Terraform Module Registry
 
 {{< /history >}}
 
-With the Terraform Module Registry, you can use GitLab projects as a
-private registry for terraform modules. You can create and publish
+With the Terraform Module Registry, you can:
+
+- Use GitLab projects as a
+private registry for Terraform modules.
+- Create and publish
 modules with GitLab CI/CD, which can then be consumed from other private
 projects.
 
-## View Terraform modules
-
-{{< history >}}
-
-- Support for Readme files [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/438060) in GitLab 17.2.
-
-{{< /history >}}
-
-To view Terraform modules in your project or group:
-
-1. On the left sidebar, select **Search or go to** and find your project or group.
-1. Select **Operate > Terraform modules**.
-
-You can search, sort, and filter modules on this page.
-
-You can also view the module's Readme file by selecting a module, and then selecting **Readme**.
-
 ## Authenticate to the Terraform Module Registry
 
 To authenticate to the Terraform Module Registry, you need either:
 
-- A [personal access token](../../../api/rest/authentication.md#personalprojectgroup-access-tokens) with at least `read_api` rights.
+- A [personal access token](../../../api/rest/authentication.md#personalprojectgroup-access-tokens) with at least the `read_api` scope.
 - A [CI/CD job token](../../../ci/jobs/ci_job_token.md).
 - A [deploy token](../../project/deploy_tokens/_index.md) with the `read_package_registry` or `write_package_registry` scope, or both.
 
+When using the API:
+
+- If you authenticate with a deploy token, you must apply the `write_package_registry` scope to publish a module. To download a module, apply the `read_package_registry` scope.
+- If you authenticate with a personal access token, you must configure it with at least the `read_api` scope.
+
 Do not use authentication methods other than the methods documented here. Undocumented authentication methods might be removed in the future.
 
+## Prerequisites
+
+To publish a Terraform module:
+
+- You must have at least the Developer role.
+
+To delete a module:
+
+- You must have at least the Maintainer role.
+
 ## Publish a Terraform module
 
-When you publish a Terraform module, if it does not exist, it is created.
+Publishing a Terraform module creates it if it does not exist.
 
-### Using the API
+After you publish a Terraform module, you can [view it in the **Terraform Module Registry**](#view-terraform-modules) page.
 
-You can publish Terraform modules by using the [Terraform Module Registry API](../../../api/packages/terraform-modules.md).
+### With the API
 
-Prerequisites:
-
-- Unless [duplicates are allowed](#allow-duplicate-terraform-modules), the module name [must be unique in the top-level namespace](#how-module-resolution-works). Otherwise, an [error occurs](#troubleshooting).
-- The module name and version must be unique in the project.
-- Your project and group names must not include a dot (`.`). For example, `source = "gitlab.example.com/my.group/project.name"`.
-- You must [authenticate with the API](../../../api/rest/authentication.md). If authenticating with a deploy token, it must be configured with the `write_package_registry` scope.
+Publish Terraform modules by using the [Terraform Module Registry API](../../../api/packages/terraform-modules.md).
 
 ```plaintext
 PUT /projects/:id/packages/terraform/modules/:module-name/:module-system/:module-version/file
@@ -73,32 +69,43 @@ PUT /projects/:id/packages/terraform/modules/:module-name/:module-system/:module
 | Attribute          | Type            | Required | Description                                                                                                                      |
 | -------------------| --------------- | ---------| -------------------------------------------------------------------------------------------------------------------------------- |
 | `id`               | integer/string  | yes      | The ID or [URL-encoded path of the project](../../../api/rest/_index.md#namespaced-paths).                                    |
-| `module-name`      | string          | yes      | The module name. **Supported syntax**: One to 64 ASCII characters, including lowercase letters (a-z) and digits (0-9). The module name can't exceed 64 characters. |
-| `module-system`    | string          | yes      | The module system. **Supported syntax**: One to 64 ASCII characters, including lowercase letters (a-z) and digits (0-9). The module system can't exceed 64 characters. More information can be found in the [Terraform Module Registry protocol documentation](https://www.terraform.io/internals/module-registry-protocol). |
-| `module-version`   | string          | yes      | The module version. It must be valid according to the [semantic versioning specification](https://semver.org/). |
+| `module-name`      | string          | yes      | The module name. **Supported syntax**: 1 to 64 ASCII characters, including lowercase letters (a-z) and digits (0-9). |
+| `module-system`    | string          | yes      | The module system. **Supported syntax**: 1 to 64 ASCII characters, including lowercase letters (a-z) and digits (0-9). For more information, see [Module Registry Protocol](https://opentofu.org/docs/internals/module-registry-protocol/). |
+| `module-version`   | string          | yes      | The module version. Should follow the [semantic versioning specification](https://semver.org/). |
 
 Provide the file content in the request body.
 
-As the following example shows, requests must end with `/file`.
-If you send a request ending with something else, it results in a 404
-error `{"error":"404 Not Found"}`.
+Requests must end with `/file`.
+If you send a request ending with something else, it results in a `404 Not Found` error.
+
+{{< tabs >}}
+
+{{< tab title="Personal access token" >}}
 
 Example request using a personal access token:
 
 ```shell
 curl --fail-with-body --header "PRIVATE-TOKEN: <your_access_token>" \
      --upload-file path/to/file.tgz \
-     "https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/terraform/modules/my-module/my-system/0.0.1/file"
+     --url "https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/terraform/modules/<your_module>/<your_system>/0.0.1/file"
 ```
 
+{{< /tab >}}
+
+{{< tab title="Deploy token" >}}
+
 Example request using a deploy token:
 
 ```shell
 curl --fail-with-body --header "DEPLOY-TOKEN: <deploy_token>" \
      --upload-file path/to/file.tgz \
-     "https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/terraform/modules/my-module/my-system/0.0.1/file"
+     --url "https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/terraform/modules/<your_module>/<your_system>/0.0.1/file"
 ```
 
+{{< /tab >}}
+
+{{< /tabs >}}
+
 Example response:
 
 ```json
@@ -107,7 +114,7 @@ Example response:
 }
 ```
 
-### Using a CI/CD template (recommended)
+### With a CI/CD template (recommended)
 
 {{< history >}}
 
@@ -117,7 +124,7 @@ Example response:
 
 You can use the [`Terraform-Module.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform-Module.gitlab-ci.yml)
 or the advanced [`Terraform/Module-Base.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform/Module-Base.gitlab-ci.yml)
-CI/CD template to publish a Terraform module to the GitLab terraform registry:
+CI/CD template to publish a Terraform module to the GitLab Terraform Module Registry:
 
 ```yaml
 include:
@@ -126,27 +133,28 @@ include:
 
 The pipeline contains the following jobs:
 
-- `fmt` - Validate the formatting of the Terraform module.
-- `kics-iac-sast` - Test the Terraform module for security issues.
-- `deploy` - For tag pipelines only. Deploy the Terraform module to the Terraform Module Registry.
+- `fmt`: Validates the formatting of the Terraform module
+- `kics-iac-sast`: Tests the Terraform module for security issues
+- `deploy`: Deploys the Terraform module to the Terraform Module Registry (for tag pipelines only)
 
-#### Pipeline variables
+#### Use pipeline variables
 
-You can configure the pipeline with the following variables:
+Configure the pipeline with the following variables:
 
 | Variable                   | Default              | Description                                                                                     |
 |----------------------------|----------------------|-------------------------------------------------------------------------------------------------|
 | `TERRAFORM_MODULE_DIR`     | `${CI_PROJECT_DIR}`  | The relative path to the root directory of the Terraform project.                               |
-| `TERRAFORM_MODULE_NAME`    | `${CI_PROJECT_NAME}` | The name of your Terraform module. Must not contain any spaces or underscores.                  |
-| `TERRAFORM_MODULE_SYSTEM`  | `local`              | The system or provider of your Terraform module targets. For example, `local`, `aws`, `google`. |
-| `TERRAFORM_MODULE_VERSION` | `${CI_COMMIT_TAG}`   | The Terraform module version. You should follow the semantic versioning specification.          |
+| `TERRAFORM_MODULE_NAME`    | `${CI_PROJECT_NAME}` | The module name. Must not contain any spaces or underscores.                  |
+| `TERRAFORM_MODULE_SYSTEM`  | `local`              | The system or provider of your module targets. For example, `local`, `aws`, or `google`. |
+| `TERRAFORM_MODULE_VERSION` | `${CI_COMMIT_TAG}`   | The module version. Should follow the [semantic versioning specification](https://semver.org/).          |
 
-### Using CI/CD manually
+### Configure CI/CD manually
 
-To work with Terraform modules in [GitLab CI/CD](../../../ci/_index.md), you can use
+To work with Terraform modules in [GitLab CI/CD](../../../ci/_index.md), use a
 `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
-For example, this job uploads a new module for the `local` [system provider](https://registry.terraform.io/browse/providers) and uses the module version from the Git commit tag:
+For example, this job uploads a new module for the `local` [system provider](https://registry.terraform.io/browse/providers)
+and uses the module version from the Git commit tag:
 
 ```yaml
 stages:
@@ -170,8 +178,44 @@ upload:
     - if: $CI_COMMIT_TAG
 ```
 
-To trigger this upload job, add a Git tag to your commit. Ensure the tag follows the [Semantic versioning specification](https://semver.org/) that Terraform requires. The `rules:if: $CI_COMMIT_TAG` ensures that only tagged commits to your repository trigger the module upload job.
-For other ways to control jobs in your CI/CD pipeline, refer to the [CI/CD YAML syntax reference](../../../ci/yaml/_index.md).
+To trigger this upload job, add a Git tag to your commit.
+Ensure the tag follows the required [semantic versioning specification](https://semver.org/) for Terraform.
+The `rules:if: $CI_COMMIT_TAG` ensures
+that only tagged commits to your repository trigger the module upload job.
+
+For other ways to control jobs in your CI/CD pipeline, see the [CI/CD YAML syntax reference](../../../ci/yaml/_index.md).
+
+### Module resolution workflow
+
+When you upload a new module, GitLab generates a path for the module. For example:
+
+- `https://gitlab.example.com/parent-group/my-infra-package`
+
+This path conforms with [the Terraform Module Registry Protocol](https://opentofu.org/docs/internals/module-registry-protocol/), where:
+
+- `gitlab.example.com` is the hostname.
+- `parent-group` is the unique, top-level [namespace](../../namespace/_index.md) of the Terraform Module Registry.
+- `my-infra-package` is the name of the module.
+
+If [duplicates are not allowed](#allow-duplicate-terraform-modules), the module name and version must be unique in all groups, subgroups, and projects under `parent-group`. Otherwise, you receive the following error:
+
+- `{"message":"A module with the same name already exists in the namespace."}`
+
+If [duplicates are allowed](#allow-duplicate-terraform-modules), module resolution is based on the most recently published module.
+
+For example, if:
+
+- The project is `gitlab.example.com/parent-group/subgroup/my-project`.
+- The Terraform module is `my-infra-package`.
+If duplicates are allowed, `my-infra-package` is a valid module. 
+If duplicates are not allowed, the module name must be unique in all 
+projects in all groups under `parent-group`.
+
+When you name a module, keep these naming conventions in mind:
+
+- Your project and group names must not include a dot (`.`).
+For example, `source = "gitlab.example.com/my.group/project.name"` is invalid.
+- Module versions should follow the [semantic versioning specification](https://semver.org/).
 
 ### Allow duplicate Terraform modules
 
@@ -207,20 +251,41 @@ To allow duplicates with specific names:
 1. Use `terraform_module_duplicate_exception_regex` to define a regex pattern for the module names you want to allow duplicates for.
 
 The top-level namespace setting takes precedence over the child namespace settings.
-For example, if you enable `terraform_module_duplicates_allowed` for a group, and disable it for a subgroup, duplicates are allowed for all projects in the group and its subgroups.
+For example, if you enable `terraform_module_duplicates_allowed` for a group, and disable it for a subgroup,
+duplicates are allowed for all projects in the group and its subgroups.
+
+For more information on module resolution, see [module resolution workflow](#module-resolution-workflow)
+
+## View Terraform modules
+
+{{< history >}}
+
+- Support for `README` files [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/438060) in GitLab 17.2.
+
+{{< /history >}}
+
+To view Terraform modules in your project or group:
+
+1. On the left sidebar, select **Search or go to** and find your project or group.
+1. Select **Operate > Terraform modules**.
+
+You can search, sort, and filter modules on this page.
+
+To view a module's `README` file:
+
+1. From the **Terraform Module Registry** page, select a Terraform module.
+1. Select **`README`**.
 
 ## Reference a Terraform module
 
-Prerequisites:
-
-- You need to [authenticate with the API](../../../api/rest/authentication.md). If authenticating with a personal access token, it must be configured with the `read_api` scope.
+Reference a module from a group or project.
 
 ### From a namespace
 
 You can provide authentication tokens (job tokens, personal access tokens, or deploy tokens) for `terraform` in environment variables.
 
 You should add the prefix `TF_TOKEN_` to the domain name of environment variables, with periods encoded as underscores.
-See the [Terraform CLI configuration documentation](https://developer.hashicorp.com/terraform/cli/config/config-file#environment-variable-credentials).
+For more information, see [Environment Variable Credentials](https://opentofu.org/docs/cli/config/config-file/#environment-variable-credentials).
 
 For example, the value of a variable named `TF_TOKEN_gitlab_com` is used as a deploy token when the CLI makes service requests to the hostname `gitlab.com`:
 
@@ -228,15 +293,17 @@ For example, the value of a variable named `TF_TOKEN_gitlab_com` is used as a de
 export TF_TOKEN_gitlab_com='glpat-<deploy_token>'
 ```
 
-This method is preferred for enterprise implementations. For local or temporary environments, you might want to create a `~/.terraformrc` or `%APPDATA%/terraform.rc` file:
+This method is preferred for enterprise implementations. For local or temporary environments,
+you might want to create a `~/.terraformrc` or `%APPDATA%/terraform.rc` file:
 
 ```terraform
-credentials "gitlab.com" {
+credentials "<gitlab.com>" {
   token = "<TOKEN>"
 }
 ```
 
-Where `gitlab.com` can be replaced with the hostname of GitLab Self-Managed.
+Where `gitlab.com` can be replaced with the hostname of
+your GitLab Self-Managed instance.
 
 You can then refer to your Terraform module from a downstream Terraform project:
 
@@ -246,21 +313,21 @@ module "<module>" {
 }
 ```
 
-Where `<namespace>` is the [namespace](../../namespace/_index.md) of the Terraform Module Registry.
-
 ### From a project
 
-To reference a Terraform module using a project-level source, use the [fetching archives over HTTP](https://developer.hashicorp.com/terraform/language/modules/sources#fetching-archives-over-http) source type provided by Terraform.
+To reference a Terraform module using a project source,
+use the [fetching archives over HTTP](https://developer.hashicorp.com/terraform/language/modules/sources#fetching-archives-over-http) source type provided by Terraform.
 
 You can provide authentication tokens (job tokens, personal access tokens, or deploy tokens) for `terraform` in your `~/.netrc` file:
 
 ```plaintext
-machine gitlab.com
+machine <gitlab.com>
 login <USERNAME>
 password <TOKEN>
 ```
 
-Where `gitlab.com` can be replaced with the hostname of GitLab Self-Managed, and `<USERNAME>` is your token username.
+Where `gitlab.com` can be replaced with the hostname of your GitLab Self-Managed instance,
+and `<USERNAME>` is your token username.
 
 You can refer to your Terraform module from a downstream Terraform project:
 
@@ -280,31 +347,13 @@ To download a Terraform module:
 
 1. On the left sidebar, select **Operate > Terraform modules**.
 1. Select the name of the module you want to download.
-1. In the **Activity** section, select the name of the module you want to download.
-
-## How module resolution works
-
-When you upload a new module, GitLab generates a path for the module, for example, `https://gitlab.example.com/parent-group/my-infra-package`.
-
-- This path conforms with [the Terraform spec](https://www.terraform.io/internals/module-registry-protocol).
-- The name of the path must be unique in the namespace.
-
-For projects in subgroups where [duplicates are not allowed](#allow-duplicate-terraform-modules), GitLab checks that the module name does not already exist anywhere in the namespace, including all subgroups and the parent group.
-
-For example, if:
-
-- The project is `gitlab.example.com/parent-group/subgroup/my-project`.
-- The Terraform module is `my-infra-package`.
-
-The module name must be unique in all projects in all groups under `parent-group`. If [duplicates are allowed](#allow-duplicate-terraform-modules), module resolution is based on the most recently published module.
+1. From the **Assets** table, select the module you want to download.
 
 ## Delete a Terraform module
 
 You cannot edit a Terraform module after you publish it in the Terraform Module Registry. Instead, you
 must delete and recreate it.
 
-To delete a module, you must have suitable [permissions](../../permissions.md).
-
 You can delete modules by using [the packages API](../../../api/packages.md#delete-a-project-package) or the UI.
 
 To delete a module in the UI, from your project:
@@ -320,24 +369,18 @@ The package is permanently deleted.
 The Terraform Module Registry is automatically enabled.
 
 For GitLab Self-Managed instances, a GitLab administrator can
-[disable](../../../administration/packages/_index.md) **Packages and registries**,
+[disable](../../../administration/packages/_index.md#enable-or-disable-the-package-registry) **Packages and registries**,
 which removes this menu item from the sidebar.
 
 You can also remove the Terraform Module Registry for a specific project:
 
 1. In your project, go to **Settings > General**.
-1. Expand the **Visibility, project features, permissions** section and toggle **Packages** off (in gray).
+1. Expand the **Visibility, project features, permissions** section and toggle **Packages** off.
 1. Select **Save changes**.
 
-To enable it back, follow the same steps above and toggle it on (in blue).
-
 ## Example projects
 
 For examples of the Terraform Module Registry, check the projects below:
 
 - The [_GitLab local file_ project](https://gitlab.com/mattkasa/gitlab-local-file) creates a minimal Terraform module and uploads it into the Terraform Module Registry using GitLab CI/CD.
 - The [_Terraform module test_ project](https://gitlab.com/mattkasa/terraform-module-test) uses the module from the previous example.
-
-## Troubleshooting
-
-- Publishing a module with a duplicate name results in a `{"message":"A module with the same name already exists in the namespace."}` error.

doc/user/profile/account/two_factor_authentication_troubleshooting.md

@@ -138,4 +138,4 @@ To create a support request:
 ### Reset 2FA for enterprise users
 
 If you are a top-level group Owner on a paid plan, you can disable 2FA for enterprise users.
-For more information, see [Disable two-factor-authentication](../../enterprise_user/_index.md#disable-two-factor-authentication).
+For more information, see [disable 2FA for enterprise users](../../../security/two_factor_authentication.md#enterprise-users).

doc/user/project/codeowners/_index.md

@@ -21,7 +21,7 @@ Define the owners of files and directories in a repository to:
   see [Code Owners and protected branches](#code-owners-and-protected-branches).
 - Identify owners. Code Owner names are displayed on the files and directories they own:
 
-  ![Code Owners displayed in UI](../img/codeowners_in_UI_v15_10.png)
+  ![Code Owners displayed in UI](img/codeowners_in_UI_v15_10.png)
 
 ## Code Owners and approval rules
 

doc/user/project/codeowners/advanced.md

@@ -150,7 +150,7 @@ For example, to require two approvals for the `[Documentation]` section:
 
 The `Documentation` Code Owners section in the Approvals area displays two approvals are required:
 
-![MR widget - Multiple Approval Code Owners sections](../img/multi_approvals_code_owners_sections_v15_9.png)
+![MR widget - Multiple Approval Code Owners sections](img/multi_approvals_code_owners_sections_v15_9.png)
 
 ## Group inheritance and eligibility
 

doc/user/project/codeowners/reference.md

@@ -107,7 +107,7 @@ internal/README.md @user2
 Each Code Owner in the merge request widget is listed under a label.
 The following image shows `Default`, `Frontend`, and `Technical Writing` sections:
 
-![MR widget - Sectional Code Owners](../img/sectional_code_owners_v17_4.png)
+![MR widget - Sectional Code Owners](img/sectional_code_owners_v17_4.png)
 
 For more section configuration options, see:
 
@@ -208,7 +208,7 @@ In this example, the `[Go]` section is optional:
 
 The optional Code Owners section displays in merge requests under the description:
 
-![MR widget - Optional Code Owners sections](../img/optional_code_owners_sections_v17_4.png)
+![MR widget - Optional Code Owners sections](img/optional_code_owners_sections_v17_4.png)
 
 If a section is duplicated in the file, and one of them is marked as optional and the other isn't, the section is required.
 
@@ -333,11 +333,11 @@ In this example:
 - The group `group-name` is listed under the `[Maintainers]` section.
 - The `group-name` contains the following direct members:
 
-  ![List of group members.](../img/direct_group_members_v17_9.png)
+  ![List of group members.](img/direct_group_members_v17_9.png)
 
 - In the merge request approval widget, the same direct members are listed as `Maintainers`:
 
-  ![Merge request maintainers.](../img/merge_request_maintainers_v17_9.png)
+  ![Merge request maintainers.](img/merge_request_maintainers_v17_9.png)
 
 {{< alert type="note" >}}
 

doc/user/project/description_templates.md

@@ -183,7 +183,7 @@ To re-use templates [you've created](description_templates.md#create-an-issue-te
 1. From the dropdown list, select your template project as the template repository at group level.
 1. Select **Save changes**.
 
-![Group template settings](../group/img/group_file_template_settings_v11_5.png)
+![Group template settings](img/group_file_template_settings_v11_5.png)
 
 You might also be interested in templates for various
 [file types in groups](../group/manage.md#group-file-templates).

doc/user/project/issues/managing_issues.md

@@ -401,7 +401,7 @@ to close. Users can include issue closing patterns in the merge request descript
 of a commit message. Closing messages in commit messages are easy to miss. In both cases, the merge request widget
 shows information about the issue to close on merge:
 
-![This merge request closes issue #2754.](../merge_requests/img/closing_pattern_v17_4.png)
+![This merge request closes issue #2754.](img/closing_pattern_v17_4.png)
 
 When you merge a merge request, GitLab checks that you have permission to close the targeted issues.
 In public repositories, this check is important, because external users can create both merge requests

doc/user/project/merge_requests/changes.md

@@ -285,7 +285,7 @@ To explain the code in a merge request:
 1. On the new tab, select the lines you want to have explained.
 1. On the left side, select the question mark ({{< icon name="question" >}}). You might have to scroll to the first line of your selection to view it.
 
-   ![explain code in a merge request](../repository/img/explain_code_v17_1.png)
+   ![explain code in a merge request](img/explain_code_v17_1.png)
 
 Duo Chat explains the code. It might take a moment for the explanation to be generated.
 

doc/user/project/merge_requests/creating_merge_requests.md

@@ -146,7 +146,7 @@ You can create a merge request from your fork to contribute back to the main pro
       [default target](#set-the-default-target-project) for your fork.
    1. Select a branch from the upstream repository:
 
-      ![Selecting branches](../repository/img/forking_workflow_branch_select_v15_9.png)
+      ![Selecting branches](img/forking_workflow_branch_select_v15_9.png)
 
    {{< alert type="note" >}}
 

doc/user/project/pages/getting_started/pages_forked_sample_project.md

@@ -61,7 +61,7 @@ you can rename it to `<namespace>.gitlab.io`, where `<namespace>` is your GitLab
    If you set the repository path to `gitlab-tests.gitlab.io`,
    the resulting URL for your Pages website is `https://gitlab-tests.gitlab.io`.
 
-   ![Change repository's path](../img/change_path_v12_10.png)
+   ![Change repository's path](img/change_path_v12_10.png)
 
 1. Open your SSG configuration file and change the [base URL](../getting_started_part_one.md#urls-and-base-urls)
    from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the configuration file.

doc/user/project/repository/code_suggestions/set_up.md

@@ -123,14 +123,14 @@ Code Suggestions provides a LSP (Language Server Protocol) server, to support th
 All editor extensions from GitLab, except Neovim, add an icon to your IDE's status bar.
 For example, in Visual Studio:
 
-![The status bar in Visual Studio.](../../../../editor_extensions/img/visual_studio_status_bar_v17_4.png)
+![The status bar in Visual Studio.](img/visual_studio_status_bar_v17_4.png)
 
 | Icon | Status | Meaning |
 | :--- | :----- | :------ |
 | {{< icon name="tanuki-ai" >}} | **Ready** | You've configured and enabled GitLab Duo, and you're using a language that supports Code Suggestions. |
 | {{< icon name="tanuki-ai-off" >}} | **Not configured** | You haven't entered a personal access token, or you're using a language that Code Suggestions doesn't support. |
-| ![The status icon for fetching Code Suggestions.](../../../../editor_extensions/img/code_suggestions_loading_v17_4.svg) | **Loading suggestion** | GitLab Duo is fetching Code Suggestions for you. |
-| ![The status icon for a Code Suggestions error.](../../../../editor_extensions/img/code_suggestions_error_v17_4.svg) | **Error** | GitLab Duo has encountered an error. |
+| ![The status icon for fetching Code Suggestions.](img/code_suggestions_loading_v17_4.svg) | **Loading suggestion** | GitLab Duo is fetching Code Suggestions for you. |
+| ![The status icon for a Code Suggestions error.](img/code_suggestions_error_v17_4.svg) | **Error** | GitLab Duo has encountered an error. |
 
 ## Turn off Code Suggestions
 

doc/user/project/repository/code_suggestions/troubleshooting.md

@@ -111,7 +111,7 @@ as taking longer to resolve. To disable streaming:
 1. In VS Code, on the top bar, go to **Code > Settings > Settings**.
 1. On the top right corner, select **Open Settings (JSON)** to edit your `settings.json` file:
 
-   ![The icons on the top right corner of VS Code, including 'Open Settings.'](../../../../editor_extensions/visual_studio_code/img/open_settings_v17_5.png)
+   ![The icons on the top right corner of VS Code, including 'Open Settings.'](img/open_settings_v17_5.png)
 1. In your `settings.json` file, add this line, or set it to `false` it already exists:
 
    ```json