+
{{
$options.I18N_BUTTON_SETUP
}}
diff --git a/app/assets/javascripts/deprecated_notes.js b/app/assets/javascripts/deprecated_notes.js
index 1041e7e38ab..a6166306a98 100644
--- a/app/assets/javascripts/deprecated_notes.js
+++ b/app/assets/javascripts/deprecated_notes.js
@@ -1536,7 +1536,7 @@ export default class Notes {
diff --git a/app/assets/javascripts/members/placeholders/components/placeholder_actions.vue b/app/assets/javascripts/members/placeholders/components/placeholder_actions.vue
index 739a5a4701f..84f69773267 100644
--- a/app/assets/javascripts/members/placeholders/components/placeholder_actions.vue
+++ b/app/assets/javascripts/members/placeholders/components/placeholder_actions.vue
@@ -281,13 +281,13 @@ export default {
-
+
{{ __('This field is required.') }}
+
+ {{ sourceUser.reassignmentError }}
+
diff --git a/app/assets/javascripts/members/placeholders/graphql/fragments/import_source_user.fragment.graphql b/app/assets/javascripts/members/placeholders/graphql/fragments/import_source_user.fragment.graphql
index 0eb19fe181e..23ea403d854 100644
--- a/app/assets/javascripts/members/placeholders/graphql/fragments/import_source_user.fragment.graphql
+++ b/app/assets/javascripts/members/placeholders/graphql/fragments/import_source_user.fragment.graphql
@@ -6,6 +6,7 @@ fragment ImportSourceUser on ImportSourceUser {
sourceName
sourceHostname
status
+ reassignmentError
placeholderUser {
...User
}
diff --git a/app/assets/javascripts/pages/profiles/two_factor_auths/index.js b/app/assets/javascripts/pages/profiles/two_factor_auths/index.js
index 41952a33c05..cebb24e133c 100644
--- a/app/assets/javascripts/pages/profiles/two_factor_auths/index.js
+++ b/app/assets/javascripts/pages/profiles/two_factor_auths/index.js
@@ -1,6 +1,10 @@
import { mount2faRegistration } from '~/authentication/mount_2fa';
import { initWebAuthnRegistration } from '~/authentication/webauthn/registration';
-import { initRecoveryCodes, initManageTwoFactorForm } from '~/authentication/two_factor_auth';
+import {
+ initRecoveryCodes,
+ initManageTwoFactorForm,
+ initTwoFactorConfirm,
+} from '~/authentication/two_factor_auth';
import { parseBoolean } from '~/lib/utils/common_utils';
const twoFactorNode = document.querySelector('.js-two-factor-auth');
@@ -21,3 +25,4 @@ mount2faRegistration();
initWebAuthnRegistration();
initRecoveryCodes();
initManageTwoFactorForm();
+initTwoFactorConfirm();
diff --git a/app/assets/javascripts/pages/users/index.js b/app/assets/javascripts/pages/users/index.js
index 134962721d2..872c71fa8b3 100644
--- a/app/assets/javascripts/pages/users/index.js
+++ b/app/assets/javascripts/pages/users/index.js
@@ -1,7 +1,7 @@
import $ from 'jquery';
import { setCookie } from '~/lib/utils/common_utils';
import UserCallout from '~/user_callout';
-import { initProfileTabs, initUserAchievements } from '~/profile';
+import { initUserAchievements, initUserProfileApp } from '~/profile';
import { initUserActionsApp } from '~/users/profile/actions';
import UserTabs from './user_tabs';
@@ -11,7 +11,7 @@ function initUserProfile(action) {
// See https://gitlab.com/gitlab-org/gitlab/-/issues/435899.
if (gon.features?.profileTabsVue) {
- initProfileTabs();
+ initUserProfileApp();
} else {
// eslint-disable-next-line no-new
new UserTabs({ parentEl: '.user-profile', action });
diff --git a/app/assets/javascripts/profile/components/app.vue b/app/assets/javascripts/profile/components/app.vue
new file mode 100644
index 00000000000..14313c92ab4
--- /dev/null
+++ b/app/assets/javascripts/profile/components/app.vue
@@ -0,0 +1,9 @@
+
+
+
+
NOTE:
-Before selecting an initial Reference Architecture, we recommended reviewing this section thoroughly to consider other factors such as High Availability (HA) or the use of Large Monorepos, as these may impact the choice beyond just RPS or user count.
+Before you select an initial architecture, review this section thoroughly. Consider other factors such as High Availability (HA) or use of large monorepos, as they may impact the choice beyond just RPS or user count.
NOTE:
-After selecting an initial Reference Architecture, it's possible to then [scale up and down](#scaling-an-environment) accordingly to your needs if metrics support.
+After you select an initial reference architecture, you can [scale up and down](#scaling-an-environment) according to your needs if metrics support.
### Standalone (non-HA)
-For environments serving 2,000 or fewer users, we generally recommend a standalone approach by deploying a non-highly available single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../administration/backup_restore/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery to provide a good level of RPO / RTO while avoiding the complexities that come with HA.
+For environments serving 2,000 or fewer users, we recommend a standalone approach by deploying a non-HA, single or multi-node environment. With this approach, you can employ strategies such as [automated backups](../../administration/backup_restore/backup_gitlab.md#configuring-cron-to-make-daily-backups) for recovery. These strategies provide a good level of recovery time objective (RPO) or recovery point objective (RTO) while avoiding the complexities that come with HA.
-*[RTO]: Recovery time objective
-*[RPO]: Recovery point objective
-
-With standalone setups, especially single node environments, there are [various options available for installation](../../install/index.md) and management including [the ability to deploy directly via select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further.
+With standalone setups, especially single node environments, various options are available for [installation](../../install/index.md) and management. The options include [the ability to deploy directly by using select cloud provider marketplaces](https://page.gitlab.com/cloud-partner-marketplaces.html) that reduce the complexity a little further.
### High Availability (HA)
High Availability ensures every component in the GitLab setup can handle failures through various mechanisms. However, to achieve this is complex, and the environments required can be sizable.
-For environments serving 3,000 or more users we generally recommend that a HA strategy is used as at this level outages have a bigger impact against more users. All the architectures in this range have HA built in by design for this reason.
+For environments serving 3,000 or more users, we generally recommend using an HA strategy. At this level, outages have a bigger impact against more users. All the architectures in this range have HA built in by design for this reason.
#### Do you need High Availability (HA)?
-As mentioned above, achieving HA does come at a cost. The environment requirements are sizable as each component needs to be multiplied, which comes with additional actual and maintenance costs.
+As mentioned previously, achieving HA comes at a cost. The environment requirements are sizable as each component needs to be multiplied, which comes with additional actual and maintenance costs.
-For a lot of our customers with fewer than 3,000 users, we've found a backup strategy is sufficient and even preferable. While this does have a slower recovery time, it also means you have a much smaller architecture and less maintenance costs as a result.
+For a lot of our customers with fewer than 3,000 users, we've found that a backup strategy is sufficient and even preferable. While this does have a slower recovery time, it also means you have a much smaller architecture and less maintenance costs as a result.
-In general then, we'd only recommend you employ HA in the following scenarios:
+As a general guideline, employ HA only in the following scenarios:
- When you have 3,000 or more users.
- When GitLab being down would critically impact your workflow.
-#### Scaled-down High Availability (HA) approaches
+#### Scaled-down High Availability (HA) approach
-If you still need to have HA for a lower number of users, this can be achieved with an adjusted [3K architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha).
+If you still need HA for fewer users, you can achieve it with an adjusted [3K architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha).
#### Zero-downtime upgrades
-[Zero-downtime upgrades](../../update/zero_downtime.md) are available for standard Reference Architecture environments with HA (Cloud Native Hybrid is [not supported](https://gitlab.com/groups/gitlab-org/cloud-native/-/epics/52)). This allows for an environment to stay up during an upgrade, but the process is more complex as a result and has some limitations as detailed in the documentation.
+[Zero-downtime upgrades](../../update/zero_downtime.md) are available for standard environments with HA (Cloud Native Hybrid is [not supported](https://gitlab.com/groups/gitlab-org/cloud-native/-/epics/52)). This allows for an environment to stay up during an upgrade. However, this process is more complex as a result and has some limitations as detailed in the documentation.
-When going through this process it's worth noting that there may still be brief moments of downtime when the HA mechanisms take effect.
+When going through this process, it's worth noting that there may still be brief moments of downtime when the HA mechanisms take effect.
-In most cases the downtime required for doing an upgrade shouldn't be substantial, so this is only recommended if it's a key requirement for you.
+In most cases, the downtime required for doing an upgrade shouldn't be substantial. Use this approach only if it's a key requirement for you.
### Cloud Native Hybrid (Kubernetes HA)
-As an additional layer of HA resilience you can deploy select components in Kubernetes, known as a Cloud Native Hybrid Reference Architecture. For stability
+As an additional layer of HA resilience, you can deploy select components in Kubernetes, known as a Cloud Native Hybrid reference architecture. For stability
reasons, stateful components such as Gitaly [cannot be deployed in Kubernetes](#stateful-components-in-kubernetes).
-This is an alternative and more **advanced** setup compared to a standard Reference Architecture. Running services in Kubernetes is well known to be complex. **This setup is only recommended** if you have strong working knowledge and experience in Kubernetes.
+Cloud Native Hybrid is an alternative and more **advanced** setup compared to a standard reference architecture. Running services in Kubernetes is complex. **Use this setup** only if you have strong working knowledge and experience in Kubernetes.
### GitLab Geo (Cross Regional Distribution / Disaster Recovery)
@@ -229,27 +226,27 @@ requires at least two separate environments:
If the primary site becomes unavailable, you can fail over to one of the secondary sites.
-This **advanced and complex** setup should only be undertaken if DR is
+Use this **advanced and complex** setup only if DR is
a key requirement for your environment. You must also make additional decisions
-on how each site is configured, such as if each secondary site would be the
-same architecture as the primary, or if each site is configured for HA.
+on how each site is configured. For example, if each secondary site would be the
+same architecture as the primary or if each site is configured for HA.
### Large monorepos / Additional workloads
-If you have any [large monorepos](#large-monorepos) or significant [additional workloads](#additional-workloads), these can affect the performance of the environment notably and adjustments may be required depending on the context.
+[Large monorepos](#large-monorepos) or significant [additional workloads](#additional-workloads) can affect the performance of the environment notably. Some adjustments may be required depending on the context.
-If either applies to you, it's encouraged for you to reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/)
+If this situation applies to you, reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/)
for further guidance.
### Cloud provider services
For all the previously described strategies, you can run select GitLab components on equivalent cloud provider services such as the PostgreSQL database or Redis.
-[For more information, see the recommended cloud providers and services](#recommended-cloud-providers-and-services).
+For more information, see the [recommended cloud providers and services](#recommended-cloud-providers-and-services).
### Decision Tree
-Below you can find the above guidance in the form of a decision tree. It's recommended you read through the above guidance in full first before though.
+Read through the above guidance in full first before you refer to the following decision tree.
```mermaid
%%{init: { 'theme': 'base' } }%%
@@ -296,75 +293,75 @@ linkStyle default fill:none,stroke:#7759C2
## Requirements
-Before implementing a reference architecture, refer to the following requirements and guidance.
+Before implementing a reference architecture, see the following requirements and guidance.
### Supported CPUs
-The reference architectures are built and tested across various cloud providers, primarily GCP and AWS, with
-CPU targets being the lowest common denominator to ensure the widest range of compatibility:
+The architectures are built and tested across various cloud providers, primarily GCP and AWS.
+To ensure the widest range of compatibility, CPU targets are intentionally set to the lowest common denominator across these platforms:
- The [`n1` series](https://cloud.google.com/compute/docs/general-purpose-machines#n1_machines) for GCP.
- The [`m5` series](https://aws.amazon.com/ec2/instance-types/) for AWS.
-Depending on other requirements such as memory or network bandwidth and cloud provider availability, different machine types are used accordingly throughout the architectures, but it is expected that the target CPUs above should perform well.
+Depending on other requirements such as memory or network bandwidth and cloud provider availability, different machine types are used accordingly throughout the architectures. We expect that the target CPUs above perform well.
If you want, you can select a newer machine type series and have improved performance as a result.
-Additionally, ARM CPUs are supported for Linux package environments and for any [Cloud Provider services](#cloud-provider-services) where applicable.
+Additionally, ARM CPUs are supported for Linux package environments and for any [cloud provider services](#cloud-provider-services).
NOTE:
Any "burstable" instance types are not recommended due to inconsistent performance.
### Supported disk types
-As a general guidance, most standard disk types are expected to work for GitLab, but be aware of the following specific call-outs:
+Most standard disk types are expected to work for GitLab. However, be aware of the following specific call-outs:
- [Gitaly](../gitaly/index.md#disk-requirements) requires at least 8,000 input/output operations per second (IOPS) for read operations, and 2,000 IOPS for write operations.
- We don't recommend the use of any disk types that are "burstable" due to inconsistent performance.
-Outside the above standard, disk types are expected to work for GitLab and the choice of each depends on your specific requirements around areas, such as durability or costs.
+Other disk types are expected to work with GitLab. Choose based on your requirements such as durability or cost.
### Supported infrastructure
-As a general guidance, GitLab should run on most infrastructure such as reputable Cloud Providers (AWS, GCP, Azure) and
+GitLab should run on most infrastructures such as reputable cloud providers (AWS, GCP, Azure) and
their services, or self-managed (ESXi) that meet both:
-- The specifications detailed in each reference architecture.
+- The specifications detailed in each architecture.
- Any requirements in this section.
-However, this does not constitute a guarantee for every potential permutation.
+However, this does not guarantee compatibility with every potential permutation.
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
### Large Monorepos
-The reference architectures were tested with repositories of varying sizes that follow best practices.
+The architectures were tested with repositories of varying sizes that follow best practices.
**However, [large monorepos](../../user/project/repository/monorepos/index.md) (several gigabytes or more) can significantly impact the performance of Git and in turn the environment itself.**
-Their presence, and how they are used, can put a significant strain on the entire system from Gitaly through to the underlying infrastructure.
+Their presence and how they are used can put a significant strain on the entire system from Gitaly to the underlying infrastructure.
The performance implications are largely software in nature. Additional hardware resources lead to diminishing returns.
WARNING:
-If this applies to you, we strongly recommended referring to the linked documentation and reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
+If this applies to you, we strongly recommend you follow the linked documentation and reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
-As such, large monorepos come with notable cost. If you have such a repository we strongly recommend
-the following guidance is followed to ensure the best chance of good performance and to keep costs in check:
+Large monorepos come with notable cost. If you have such a repository,
+follow these guidance to ensure good performance and to keep costs in check:
- [Optimize the large monorepo](../../user/project/repository/monorepos/index.md#optimize-gitlab-settings). Using features such as
[LFS](../../user/project/repository/monorepos/index.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
dramatically improve performance and reduce costs.
-- Depending on the monorepo, increased environment specifications may be required to compensate. Gitaly in particular will likely require additional resources along with Praefect, GitLab Rails, and Load Balancers. This depends notably on the monorepo itself and the usage against it.
-- When the monorepo is significantly large (20 gigabytes or more) further additional strategies maybe required such as even further increased specifications or in some cases a separate Gitaly backend for the monorepo alone.
-- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, it's possible to see bandwidth saturation if there's a high amount of concurrent clones (such as with CI). It's strongly recommended [reducing full clones wherever possible](../../user/project/repository/monorepos/index.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth, but this differs between cloud providers.
+- Depending on the monorepo, increased environment specifications may be required to compensate. Gitaly might require additional resources along with Praefect, GitLab Rails, and Load Balancers. This depends on the monorepo itself and its usage.
+- When the monorepo is significantly large (20 gigabytes or more), further additional strategies may be required such as even further increased specifications or in some cases, a separate Gitaly backend for the monorepo alone.
+- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, bandwidth saturation is possible if there's a high amount of concurrent clones (such as with CI). [Reduce full clones wherever possible](../../user/project/repository/monorepos/index.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth. This differs based on cloud providers.
### Additional workloads
-These reference architectures have been [designed and tested](index.md#validation-and-test-results) for standard GitLab
+These architectures have been [designed and tested](index.md#validation-and-test-results) for standard GitLab
setups based on real data.
However, additional workloads can multiply the impact of operations by triggering follow-up actions.
-You may need to adjust the suggested specifications to compensate if you use, for example:
+You may need to adjust the suggested specifications to compensate if you use:
- Security software on the nodes.
- Hundreds of concurrent CI jobs for [large repositories](../../user/project/repository/monorepos/index.md).
@@ -373,48 +370,48 @@ You may need to adjust the suggested specifications to compensate if you use, fo
- [Server hooks](../server_hooks.md).
- [System hooks](../system_hooks.md).
-As a general rule, you should have robust monitoring in place to measure the impact of any additional workloads to
-inform any changes needed to be made. It's also strongly encouraged for you to reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/)
+Generally, you should have robust monitoring in place to measure the impact of any additional workloads to
+inform any changes needed to be made. Reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/)
for further guidance.
### Load Balancers
-The Reference Architectures make use of up to two Load Balancers depending on the class:
+The architectures make use of up to two load balancers depending on the class:
-- External Load Balancer - Serves traffic to any external facing components, primarily Rails.
-- Internal Load Balancer - Serves traffic to select internal components that have been deployed in an HA fashion such as Praefect or PgBouncer.
+- External load balancer - Serves traffic to any external facing components, primarily Rails.
+- Internal load balancer - Serves traffic to select internal components that are deployed in an HA fashion such as Praefect or PgBouncer.
The specifics on which load balancer to use, or its exact configuration is beyond the scope of GitLab documentation. The most common options
-are to set up load balancers on machine nodes or to use a service such as one offered by Cloud Providers. If deploying a Cloud Native Hybrid environment the Charts can handle the set-up of the External Load Balancer via Kubernetes Ingress.
+are to set up load balancers on machine nodes or to use a service such as one offered by cloud providers. If deploying a Cloud Native Hybrid environment, the charts can handle the external load balancer setup by using Kubernetes Ingress.
-For each Reference Architecture class a base machine size has given to help get you started if you elect to deploy directly on machines, but these may need to be adjusted accordingly depending on the load balancer used and amount of workload. Of note machines can have varying [network bandwidth](#network-bandwidth) that should also be taken into consideration.
+Each architecture class includes a recommended base machine size to deploy directly on machines. However, they may need adjustment based on factors such as the chosen load balancer and expected workload. Of note machines can have varying [network bandwidth](#network-bandwidth) that should also be taken into consideration.
-Note the following sections of additional guidance for Load Balancers.
+The following sections provide additional guidance for load balancers.
#### Balancing algorithm
-We recommend that a least-connection-based load balancing algorithm or equivalent is used wherever possible to ensure equal spread of calls to the nodes and good performance.
+To ensure equal spread of calls to the nodes and good performance, use a least-connection-based load balancing algorithm or equivalent wherever possible.
-We don’t recommend the use of round-robin algorithms as they are known to not spread connections equally in practice.
+We don't recommend the use of round-robin algorithms as they are known to not spread connections equally in practice.
#### Network Bandwidth
-The total network bandwidth available to a load balancer when deployed on a machine can vary notably across Cloud Providers. In particular some Cloud Providers, like [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html), may operate on a burst system with credits to determine the bandwidth at any time.
+The total network bandwidth available to a load balancer when deployed on a machine can vary notably across cloud providers. Some cloud providers, like [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html), may operate on a burst system with credits to determine the bandwidth at any time.
-The network bandwidth your environment's load balancers will require is dependent on numerous factors such as data shape and workload. The recommended base sizes for each Reference Architecture class have been selected based on real data but in some scenarios, such as consistent clones of [large monorepos](#large-monorepos), the sizes may need to be adjusted accordingly.
+The required network bandwidth for your load balancers depends on factors such as data shape and workload. The recommended base sizes for each architecture class have been selected based on real data. However, in some scenarios such as consistent clones of [large monorepos](#large-monorepos), the sizes may need to be adjusted accordingly.
### No swap
Swap is not recommended in the reference architectures. It's a failsafe that impacts performance greatly. The
-reference architectures are designed to have enough memory in most cases to avoid needing swap.
+architectures are designed to have enough memory in most cases to avoid the need for swap.
### Praefect PostgreSQL
[Praefect requires its own database server](../gitaly/praefect.md#postgresql) and
-that to achieve full High Availability, a third-party PostgreSQL database solution is required.
+a third-party PostgreSQL database solution to achieve full HA.
-We hope to offer a built-in solution for these restrictions in the future. In the meantime, a non-HA PostgreSQL server
-can be set up using the Linux package as the specifications reflect. Refer to the following issues for more information:
+We hope to offer a built-in solution for these restrictions in the future. In the meantime, you can set up a
+non-HA PostgreSQL server using the Linux package as the specifications reflect. See the following issues for more information:
- [`omnibus-gitlab#7292`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
- [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
diff --git a/doc/administration/review_abuse_reports.md b/doc/administration/review_abuse_reports.md
index 33ca88bdc0d..7821e5e9ce0 100644
--- a/doc/administration/review_abuse_reports.md
+++ b/doc/administration/review_abuse_reports.md
@@ -83,7 +83,7 @@ After blocking, you can still either:
The following is an example of a blocked user listed on the **Abuse reports**
page:
-
+
## Related topics
diff --git a/doc/administration/settings/img/file_template_user_dropdown.png b/doc/administration/settings/img/file_template_user_dropdown_v11_4.png
similarity index 100%
rename from doc/administration/settings/img/file_template_user_dropdown.png
rename to doc/administration/settings/img/file_template_user_dropdown_v11_4.png
diff --git a/doc/administration/settings/img/rate_limits_on_raw_endpoints.png b/doc/administration/settings/img/rate_limits_on_raw_endpoints_v12_2.png
similarity index 100%
rename from doc/administration/settings/img/rate_limits_on_raw_endpoints.png
rename to doc/administration/settings/img/rate_limits_on_raw_endpoints_v12_2.png
diff --git a/doc/administration/settings/img/sign_up_terms.png b/doc/administration/settings/img/sign_up_terms_v11_0.png
similarity index 100%
rename from doc/administration/settings/img/sign_up_terms.png
rename to doc/administration/settings/img/sign_up_terms_v11_0.png
diff --git a/doc/administration/settings/img/two_factor_grace_period.png b/doc/administration/settings/img/two_factor_grace_period_v12_5.png
similarity index 100%
rename from doc/administration/settings/img/two_factor_grace_period.png
rename to doc/administration/settings/img/two_factor_grace_period_v12_5.png
diff --git a/doc/administration/settings/img/update-available.png b/doc/administration/settings/img/update_available_v10_6.png
similarity index 100%
rename from doc/administration/settings/img/update-available.png
rename to doc/administration/settings/img/update_available_v10_6.png
diff --git a/doc/administration/settings/instance_template_repository.md b/doc/administration/settings/instance_template_repository.md
index 6c5d1bc100b..2e3bccc85f5 100644
--- a/doc/administration/settings/instance_template_repository.md
+++ b/doc/administration/settings/instance_template_repository.md
@@ -69,7 +69,7 @@ extension and not be empty. So, the hierarchy should look like this:
Your custom templates are displayed on the dropdown list when a new file is added through the GitLab UI:
-
+
If this feature is disabled or no templates are present,
no **Custom** section displays in the selection dropdown list.
diff --git a/doc/administration/settings/rate_limits_on_raw_endpoints.md b/doc/administration/settings/rate_limits_on_raw_endpoints.md
index 7e98941b1b1..5332c4c3159 100644
--- a/doc/administration/settings/rate_limits_on_raw_endpoints.md
+++ b/doc/administration/settings/rate_limits_on_raw_endpoints.md
@@ -18,7 +18,7 @@ This setting defaults to `300` requests per minute, and allows you to rate limit
For example, requests over `300` per minute to `https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/controllers/application_controller.rb` are blocked. Access to the raw file is released after 1 minute.
-
+
This limit is:
diff --git a/doc/administration/settings/sign_in_restrictions.md b/doc/administration/settings/sign_in_restrictions.md
index e26571c5353..183cc89681b 100644
--- a/doc/administration/settings/sign_in_restrictions.md
+++ b/doc/administration/settings/sign_in_restrictions.md
@@ -167,7 +167,7 @@ After the two-factor authentication is configured as mandatory, users are allowe
to skip forced configuration of two-factor authentication for the configurable grace
period in hours.
-
+
## Email notification for unknown sign-ins
diff --git a/doc/administration/settings/sign_up_restrictions.md b/doc/administration/settings/sign_up_restrictions.md
index d0b3cfcf63e..5cae04fbd9e 100644
--- a/doc/administration/settings/sign_up_restrictions.md
+++ b/doc/administration/settings/sign_up_restrictions.md
@@ -258,13 +258,13 @@ See the [documentation on setting up an LDAP user filter](../auth/ldap/index.md#
DETAILS:
**Tier:** Ultimate
**Offering:** Self-managed, GitLab Dedicated
+**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/433166) in GitLab 16.9 [with a flag](../feature_flags.md) named `member_promotion_management`.
+> - Feature flag `member_promotion_management` [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/167757/) from `wip` to `beta` and enabled by default in GitLab 17.5.
FLAG:
The availability of this feature is controlled by a feature flag.
-For more information, see the history.
-This feature is available for testing, but not ready for production use.
In the **Ultimate** tier, [non billable roles](../../subscriptions/gitlab_com/index.md#billable-users), can be promoted to a billable role in any Project or Group, resulting in the increase of billable seats, without admins having any control on this promotion.
To prevent existing users of the subscription from being promoted to a billable role, you can enable role promotion approval.
diff --git a/doc/administration/settings/terms.md b/doc/administration/settings/terms.md
index ea606b8e048..25d915820cf 100644
--- a/doc/administration/settings/terms.md
+++ b/doc/administration/settings/terms.md
@@ -39,7 +39,7 @@ If an authenticated user declines the terms, they are signed out.
When enabled, it adds a mandatory checkbox to the sign up page for new users:
-
+