diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-08-19 09:08:42 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-08-19 09:08:42 +0000 |
| commit | b76ae638462ab0f673e5915986070518dd3f9ad3 (patch) | |
| tree | bdab0533383b52873be0ec0eb4d3c66598ff8b91 /doc/user/admin_area | |
| parent | 434373eabe7b4be9593d18a585fb763f1e5f1a6f (diff) | |
| download | gitlab-ce-b76ae638462ab0f673e5915986070518dd3f9ad3.tar.gz | |
Add latest changes from gitlab-org/gitlab@14-2-stable-eev14.2.0-rc42
Diffstat (limited to 'doc/user/admin_area')
36 files changed, 479 insertions, 374 deletions
diff --git a/doc/user/admin_area/abuse_reports.md b/doc/user/admin_area/abuse_reports.md deleted file mode 100644 index 4bfa277fc9f..00000000000 --- a/doc/user/admin_area/abuse_reports.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -redirect_to: 'review_abuse_reports.md' -remove_date: '2021-07-21' ---- - -This file was moved to [another location](review_abuse_reports.md). - -<!-- This redirect file can be deleted after <2021-07-21>. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/activating_deactivating_users.md b/doc/user/admin_area/activating_deactivating_users.md deleted file mode 100644 index e89c42b34ba..00000000000 --- a/doc/user/admin_area/activating_deactivating_users.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -redirect_to: 'moderate_users.md' -remove_date: '2021-08-12' ---- - -This document was moved to [another location](moderate_users.md). - -<!-- This redirect file can be deleted after <2021-08-12>. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md index 89d8a5ea054..f07ccc11c60 100644 --- a/doc/user/admin_area/analytics/dev_ops_report.md +++ b/doc/user/admin_area/analytics/dev_ops_report.md @@ -40,12 +40,11 @@ feature is available. ## DevOps Adoption **(ULTIMATE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta). -> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. -> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59267) in GitLab 14.0. -> - Enabled on GitLab.com. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-or-enable-devops-adoption). **(ULTIMATE SELF)** > - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1. > - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1. +> - Fuzz Testing metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/330398) in GitLab 14.2. +> - Dependency Scanning metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328034) in GitLab 14.2. +> - Multi-select [added](https://gitlab.com/gitlab-org/gitlab/-/issues/333586) in GitLab 14.2. DevOps Adoption shows you which groups in your organization are using the most essential features of GitLab: @@ -56,36 +55,20 @@ DevOps Adoption shows you which groups in your organization are using the most e - Merge requests - Sec - DAST + - Dependency Scanning + - Fuzz Testing - SAST - Ops - Deployments - Pipelines - Runners -To add your groups, in the top right-hand section the page, select **Add group to table**. +To add or remove your groups, in the top right-hand section the page, select **Add or remove groups**. DevOps Adoption allows you to: - Verify whether you are getting the return on investment that you expected from GitLab. -- Identify specific groups that are lagging in their adoption of GitLab so you can help them along in their DevOps journey. -- Find the groups that have adopted certain features and can provide guidance to other groups on how to use those features. +- Identify specific groups that are lagging in their adoption of GitLab, so you can help them along in their DevOps journey. +- Find the groups that have adopted certain features, and can provide guidance to other groups on how to use those features. - - -### Disable or enable DevOps Adoption - -DevOps Adoption is deployed behind a feature flag that is **enabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can opt to disable it. - -To disable it: - -```ruby -Feature.disable(:devops_adoption_feature) -``` - -To reenable it: - -```ruby -Feature.enable(:devops_adoption_feature) -``` + diff --git a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png Binary files differdeleted file mode 100644 index 79481e43e8e..00000000000 --- a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png +++ /dev/null diff --git a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_2.png b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_2.png Binary files differnew file mode 100644 index 00000000000..d4b3436f3ee --- /dev/null +++ b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_2.png diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md index 2852f73ffc8..fdf0c7edfc7 100644 --- a/doc/user/admin_area/approving_users.md +++ b/doc/user/admin_area/approving_users.md @@ -1,58 +1,9 @@ --- -stage: Manage -group: Access -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments -type: howto +redirect_to: 'moderate_users.md' +remove_date: '2021-10-20' --- -# Users pending approval +This document was moved to [another location](moderate_users.md). -A user in _pending approval_ state requires action by an administrator. A user sign up can be in a -pending approval state because an administrator has enabled either, or both, of the following -options: - -- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting. -- [User cap](settings/sign_up_restrictions.md#user-cap). - -When a user registers for an account while this setting is enabled: - -- The user is placed in a **Pending approval** state. -- The user sees a message telling them their account is awaiting approval by an administrator. - -A user pending approval: - -- Is functionally identical to a [blocked](moderate_users.md#blocking-a-user) user. -- Cannot sign in. -- Cannot access Git repositories or the GitLab API. -- Does not receive any notifications from GitLab. -- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). - -An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to -sign in. - -## View user sign ups pending approval - -To view user sign ups pending approval: - -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. On the left sidebar, select **Overview > Users**. -1. Select the **Pending approval** tab. - -## Approve or reject a user sign up - -A user sign up pending approval can be approved or rejected from the Admin Area. - -To approve or reject a user sign up: - -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. On the left sidebar, select **Overview > Users**. -1. Select the **Pending approval** tab. -1. (Optional) Select a user. -1. Select the **{settings}** **User administration** dropdown. -1. Select **Approve** or **Reject**. - -Approving a user: - -- Activates their account. -- Changes the user's state to active. -- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users). +<!-- This redirect file can be deleted after <2021-10-20>. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/blocking_unblocking_users.md b/doc/user/admin_area/blocking_unblocking_users.md deleted file mode 100644 index e89c42b34ba..00000000000 --- a/doc/user/admin_area/blocking_unblocking_users.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -redirect_to: 'moderate_users.md' -remove_date: '2021-08-12' ---- - -This document was moved to [another location](moderate_users.md). - -<!-- This redirect file can be deleted after <2021-08-12>. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/custom_project_templates.md b/doc/user/admin_area/custom_project_templates.md index 12d143b3a13..8c0586e5851 100644 --- a/doc/user/admin_area/custom_project_templates.md +++ b/doc/user/admin_area/custom_project_templates.md @@ -18,9 +18,13 @@ is created, based on the user's access permissions: - Public projects can be selected by any signed-in user as a template for a new project, if all enabled [project features](../project/settings/index.md#sharing-and-permissions) - except for GitLab Pages are set to **Everyone With Access**. + except for **GitLab Pages** and **Security & Compliance** are set to **Everyone With Access**. + The same applies to internal projects. - Private projects can be selected only by users who are members of the projects. +The **Metrics Dashboard** is set to **Only Project Members** when you create a new project. Make +sure you change it to **Everyone With Access** before making it a project template. + Repository and database information that are copied over to each new project are identical to the data exported with the [GitLab Project Import/Export](../project/settings/import_export.md). diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md index 19a76d0938b..861d3644ab3 100644 --- a/doc/user/admin_area/geo_nodes.md +++ b/doc/user/admin_area/geo_nodes.md @@ -5,61 +5,60 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: howto --- -# Geo nodes Admin Area **(PREMIUM SELF)** +# Geo sites Admin Area **(PREMIUM SELF)** -You can configure various settings for GitLab Geo nodes. For more information, see +You can configure various settings for GitLab Geo sites. For more information, see [Geo documentation](../../administration/geo/index.md). -On either the primary or secondary node: +On either the primary or secondary site: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Geo > Nodes**. ## Common settings -All Geo nodes have the following settings: +All Geo sites have the following settings: | Setting | Description | | --------| ----------- | -| Primary | This marks a Geo Node as **primary** node. There can be only one **primary** node; make sure that you first add the **primary** node and then all the others. | -| Name | The unique identifier for the Geo node. Must match the setting `gitlab_rails['geo_node_name']` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. | +| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. | +| Name | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, then the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. | | URL | The instance's user-facing URL. | -The node you're reading from is indicated with a green `Current node` label, and -the **primary** node is given a blue `Primary` label. Remember that you can only make -changes on the **primary** node! +The site you're currently browsing is indicated with a blue `Current` label, and +the **primary** node is listed first as `Primary site`. -## **Secondary** node settings +## **Secondary** site settings -**Secondary** nodes have a number of additional settings available: +**Secondary** sites have a number of additional settings available: | Setting | Description | |---------------------------|-------------| -| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** node. | -| Repository sync capacity | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling repositories. | -| File sync capacity | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling files. | +| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. | +| Repository sync capacity | Number of concurrent requests this **secondary** site will make to the **primary** site when backfilling repositories. | +| File sync capacity | Number of concurrent requests this **secondary** site will make to the **primary** site when backfilling files. | ## Geo backfill -**Secondary** nodes are notified of changes to repositories and files by the **primary** node, +**Secondary** sites are notified of changes to repositories and files by the **primary** site, and will always attempt to synchronize those changes as quickly as possible. -Backfill is the act of populating the **secondary** node with repositories and files that -existed *before* the **secondary** node was added to the database. Since there may be +Backfill is the act of populating the **secondary** site with repositories and files that +existed *before* the **secondary** site was added to the database. Since there may be extremely large numbers of repositories and files, it's infeasible to attempt to download them all at once, so GitLab places an upper limit on the concurrency of these operations. How long the backfill takes is a function of the maximum concurrency, but higher -values place more strain on the **primary** node. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3107), -the limits are configurable. If your **primary** node has lots of surplus capacity, +values place more strain on the **primary** site. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3107), +the limits are configurable. If your **primary** site has lots of surplus capacity, you can increase the values to complete backfill in a shorter time. If it's under heavy load and backfill is reducing its availability for normal requests, you can decrease them. ## Using a different URL for synchronization -The **primary** node's Internal URL is used by **secondary** nodes to contact it +The **primary** site's Internal URL is used by **secondary** sites to contact it (to sync repositories, for example). The name Internal URL distinguishes it from [External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab) which is used by users. Internal URL does not need to be a private address. @@ -68,13 +67,13 @@ Internal URL defaults to external URL, but you can also customize it: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Geo > Nodes**. -1. Select **Edit** on the node you want to customize. +1. Select **Edit** on the site you want to customize. 1. Edit the internal URL. 1. Select **Save changes**. WARNING: -We recommend using an HTTPS connection while configuring the Geo nodes. To avoid -breaking communication between **primary** and **secondary** nodes when using +We recommend using an HTTPS connection while configuring the Geo sites. To avoid +breaking communication between **primary** and **secondary** sites when using HTTPS, customize your Internal URL to point to a load balancer with TLS terminated at the load balancer. @@ -84,14 +83,14 @@ using an internal URL that is not accessible to the users will result in the OAuth authorization flow not working properly, as the users will get redirected to the internal URL instead of the external one. -## Multiple secondary nodes behind a load balancer +## Multiple secondary sites behind a load balancer -In GitLab 11.11, **secondary** nodes can use identical external URLs as long as -a unique `name` is set for each Geo node. The `gitlab.rb` setting +In GitLab 11.11, **secondary** sites can use identical external URLs as long as +a unique `name` is set for each Geo site. The `gitlab.rb` setting `gitlab_rails['geo_node_name']` must: - Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`. -- Match a Geo node name. +- Match a Geo site name. The load balancer must use sticky sessions in order to avoid authentication failures and cross site request errors. diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index 31fd1a3a0a1..35afb9f376b 100644 --- a/doc/user/admin_area/index.md +++ b/doc/user/admin_area/index.md @@ -121,8 +121,8 @@ To list users matching a specific criteria, click on one of the following tabs o - **2FA Enabled** - **2FA Disabled** - **External** -- **[Blocked](moderate_users.md#blocking-a-user)** -- **[Deactivated](moderate_users.md#deactivating-a-user)** +- **[Blocked](moderate_users.md#block-a-user)** +- **[Deactivated](moderate_users.md#deactivate-a-user)** - **Without projects** For each user, the following are listed: @@ -164,6 +164,8 @@ You can impersonate a user in the following ways: All impersonation activities are [captured with audit events](../../administration/audit_events.md#impersonation-data). +By default, impersonation is enabled. GitLab can be configured to [disable impersonation](../../api/index.md#disable-impersonation). +  #### User Permission Export **(PREMIUM SELF)** diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md index db2db4a0e68..0431b0d1628 100644 --- a/doc/user/admin_area/license.md +++ b/doc/user/admin_area/license.md @@ -17,7 +17,7 @@ is locked. ## Activate GitLab EE with an Activation Code **(PREMIUM SELF)** -As of GitLab Enterprise Edition 14.0, you need an activation code to activate your instance. You can obtain an activation code by [purchasing a license](https://about.gitlab.com/pricing/) or by signing up for a [free trial](https://about.gitlab.com/free-trial/). This activation code is a 24-character alphanumeric string you receive in a confirmation email. You can also sign in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) to copy the activation code to your clipboard. +As of GitLab Enterprise Edition 14.1, you need an activation code to activate your instance. You can obtain an activation code by [purchasing a license](https://about.gitlab.com/pricing/) or by signing up for a [free trial](https://about.gitlab.com/free-trial/). This activation code is a 24-character alphanumeric string you receive in a confirmation email. You can also sign in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) to copy the activation code to your clipboard. To begin the activation process with your activation code: @@ -30,7 +30,7 @@ To begin the activation process with your activation code: ## Activate GitLab EE with a License File **(PREMIUM SELF)** -If you receive a license file from GitLab (for example a new trial), you can upload it by signing into your GitLab instance as an admin or adding it during installation. The license is a base64-encoded ASCII text file with a `.gitlab-license` extension. +If you receive a license file from GitLab (for example a new trial), you can upload it by signing into your GitLab instance as an admin or adding it during installation. The license is a base64-encoded ASCII text file with a `.gitlab-license` extension. ## Uploading your license @@ -153,6 +153,20 @@ additional users. More information on how to determine the required number of us and how to add additional seats can be found in the [licensing FAQ](https://about.gitlab.com/pricing/licensing-faq/). +In GitLab 14.2 and later, for instances that use a license file, you can exceed the number of purchased users and still activate your license. + +- If the users over license are less than or equal to 10% of the users in the subscription, + the license is applied and the overage is paid in the next true-up. +- If the users over license are more than 10% of the users in the subscription, + you cannot apply the license without purchasing more users. + +For example, if you purchased a license for 100 users, you can have 110 users when you activate +your license. However, if you have 111, you must purchase more users before you can activate. + ### There is a connectivity issue -In GitLab 14.0 and later, to activate your subscription, your GitLab instance must be connected to the internet. If you have questions or need assistance activating your instance please [contact GitLab Support](https://about.gitlab.com/support/#contact-support). +In GitLab 14.1 and later, to activate your subscription, your GitLab instance must be connected to the internet. + +If you have an offline or airgapped environment, you can [upload a license file](license.md#activate-gitlab-ee-with-a-license-file) instead. + +If you have questions or need assistance activating your instance, please [contact GitLab Support](https://about.gitlab.com/support/#contact-support). diff --git a/doc/user/admin_area/merge_requests_approvals.md b/doc/user/admin_area/merge_requests_approvals.md index b221b1d51a7..4f6419cdeb7 100644 --- a/doc/user/admin_area/merge_requests_approvals.md +++ b/doc/user/admin_area/merge_requests_approvals.md @@ -24,12 +24,12 @@ To enable merge request approval rules for an instance: Merge request approval rules that can be set at an instance level are: -- **Prevent approval of merge requests by merge request author**. Prevents project +- **Prevent approval by author**. Prevents project maintainers from allowing request authors to merge their own merge requests. -- **Prevent approval of merge requests by merge request committers**. Prevents project +- **Prevent approvals by users who add commits**. Prevents project maintainers from allowing users to approve merge requests if they have submitted any commits to the source branch. -- **Prevent users from modifying merge request approvers list**. Prevents users from +- **Prevent editing approval rules in projects and merge requests**. Prevents users from modifying the approvers list in project settings or in individual merge requests. Also read the [project level merge request approval rules](../project/merge_requests/approvals/index.md), which are affected by instance level rules. diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md index 3889dd93d59..8211167895c 100644 --- a/doc/user/admin_area/moderate_users.md +++ b/doc/user/admin_area/moderate_users.md @@ -7,13 +7,66 @@ type: howto # Moderate users -GitLab administrators can moderate user access by blocking, banning, or deactivating users. +GitLab administrators can moderate user access by approving, blocking, banning, or deactivating +users. -## Blocking and unblocking users +## Users pending approval + +A user in _pending approval_ state requires action by an administrator. A user sign up can be in a +pending approval state because an administrator has enabled either, or both, of the following +options: + +- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting. +- [User cap](settings/sign_up_restrictions.md#user-cap). + +When a user registers for an account while this setting is enabled: + +- The user is placed in a **Pending approval** state. +- The user sees a message telling them their account is awaiting approval by an administrator. + +A user pending approval: + +- Is functionally identical to a [blocked](#block-a-user) user. +- Cannot sign in. +- Cannot access Git repositories or the GitLab API. +- Does not receive any notifications from GitLab. +- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). + +An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to +sign in. + +### View user sign ups pending approval + +To view user sign ups pending approval: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. +1. Select the **Pending approval** tab. + +### Approve or reject a user sign up + +A user sign up pending approval can be approved or rejected from the Admin Area. + +To approve or reject a user sign up: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. +1. Select the **Pending approval** tab. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Approve** or **Reject**. + +Approving a user: + +- Activates their account. +- Changes the user's state to active. +- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users). + +## Block and unblock users GitLab administrators can block and unblock users. -### Blocking a user +### Block a user In order to completely prevent access of a user to the GitLab instance, administrators can choose to block the user. @@ -33,15 +86,14 @@ A blocked user: - Cannot access Git repositories or the API. - Does not receive any notifications from GitLab. - Cannot use [slash commands](../../integration/slash_commands.md). +- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). Personal projects, and group and user history of the blocked user are left intact. -Users can also be blocked using the [GitLab API](../../api/users.md#block-user). - NOTE: -A blocked user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). +Users can also be blocked using the [GitLab API](../../api/users.md#block-user). -### Unblocking a user +### Unblock a user A blocked user can be unblocked from the Admin Area. To do this: @@ -52,24 +104,24 @@ A blocked user can be unblocked from the Admin Area. To do this: 1. Select the **{settings}** **User administration** dropdown. 1. Select **Unblock**. -Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user). +The user's state is set to active and they consume a +[seat](../../subscriptions/self_managed/index.md#billable-users). NOTE: -Unblocking a user changes the user's state to active and consumes a -[seat](../../subscriptions/self_managed/index.md#billable-users). +Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user). -## Activating and deactivating users +## Activate and deactivate users GitLab administrators can deactivate and activate users. -### Deactivating a user +### Deactivate a user > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. In order to temporarily prevent access by a GitLab user that has no recent activity, administrators can choose to deactivate the user. -Deactivating a user is functionally identical to [blocking a user](#blocking-and-unblocking-users), +Deactivating a user is functionally identical to [blocking a user](#block-and-unblock-users), with the following differences: - It does not prohibit the user from logging back in via the UI. @@ -80,6 +132,7 @@ A deactivated user: - Cannot access Git repositories or the API. - Does not receive any notifications from GitLab. - Does not be able to use [slash commands](../../integration/slash_commands.md). +- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). Personal projects, and group and user history of the deactivated user are left intact. @@ -91,15 +144,13 @@ A user can be deactivated from the Admin Area. To do this: 1. Select the **{settings}** **User administration** dropdown. 1. Select **Deactivate**. -Please note that for the deactivation option to be visible to an admin, the user: +For the deactivation option to be visible to an admin, the user: - Must be currently active. - Must not have signed in, or have any activity, in the last 90 days. -Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user). - NOTE: -A deactivated user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). +Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user). ### Automatically deactivate dormant users @@ -118,7 +169,7 @@ When this feature is enabled, GitLab runs a job once a day to deactivate the dor A maximum of 100,000 users can be deactivated per day. -### Activating a user +### Activate a user > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. @@ -133,29 +184,23 @@ To do this: 1. Select the **{settings}** **User administration** dropdown. 1. Select **Activate**. -Users can also be activated using the [GitLab API](../../api/users.md#activate-user). - -NOTE: -Activating a user changes the user's state to active and consumes a +The user's state is set to active and they consume a [seat](../../subscriptions/self_managed/index.md#billable-users). NOTE: A deactivated user can also activate their account themselves by logging back in via the UI. +Users can also be activated using the [GitLab API](../../api/users.md#activate-user). ## Ban and unban users -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327353) in GitLab 13.12. - -GitLab administrators can ban users. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327353) in GitLab 14.2. -NOTE: -This feature is behind a feature flag that is disabled by default. GitLab administrators -with access to the GitLab Rails console can [enable](../../administration/feature_flags.md) -this feature for your GitLab instance. +GitLab administrators can ban and unban users. Banned users are blocked, and their issues are hidden. +The banned user's comments are still displayed. Hiding a banned user's comments is [tracked in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/327356). ### Ban a user -To completely block a user, administrators can choose to ban the user. +To block a user and hide their contributions, administrators can ban the user. Users can be banned using the Admin Area. To do this: @@ -165,10 +210,7 @@ Users can be banned using the Admin Area. To do this: 1. Select the **{settings}** **User administration** dropdown. 1. Select **Ban user**. -NOTE: -This feature is a work in progress. Currently, banning a user -only blocks them and does not hide their comments or issues. -This functionality is planned to be implemented in follow up issues. +The banned user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). ### Unban a user @@ -181,6 +223,5 @@ A banned user can be unbanned using the Admin Area. To do this: 1. Select the **{settings}** **User administration** dropdown. 1. Select **Unban user**. -NOTE: -Unbanning a user changes the user's state to active and consumes a +The user's state is set to active and they consume a [seat](../../subscriptions/self_managed/index.md#billable-users). diff --git a/doc/user/admin_area/monitoring/background_migrations.md b/doc/user/admin_area/monitoring/background_migrations.md index cbaa4b30cb7..5765a530baf 100644 --- a/doc/user/admin_area/monitoring/background_migrations.md +++ b/doc/user/admin_area/monitoring/background_migrations.md @@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - Recommended for production use. > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations). **(FREE SELF)** -There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features). +There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features). Refer to this feature's version history for more details. To update database tables in batches, GitLab can use batched background migrations. These migrations @@ -23,13 +23,8 @@ prevent integer overflow for some tables. ## Check the status of background migrations **(FREE SELF)** -All migrations must have a `Finished` status before updating GitLab. To check the status of the existing -migrations: - -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. On the left sidebar, select **Monitoring > Background Migrations**. - -  +All migrations must have a `Finished` status before you [upgrade GitLab](../../../update/index.md). +You can [check the status of existing migrations](../../../update/index.md#checking-for-background-migrations-before-upgrading). ## Enable or disable batched background migrations **(FREE SELF)** @@ -59,7 +54,7 @@ Feature.disable(:execute_batched_migrations_on_schedule) > - Recommended for production use. > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization). **(FREE SELF)** -There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features). +There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features). Refer to this feature's version history for more details. To maximize throughput of batched background migrations (in terms of the number of tuples updated per time unit), batch sizes are automatically adjusted based on how long the previous batches took to complete. diff --git a/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png b/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png Binary files differdeleted file mode 100644 index 0b0792b5e7a..00000000000 --- a/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png +++ /dev/null diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md index 2b60ed5345b..71e05f44ef0 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -154,7 +154,12 @@ nginx['client_max_body_size'] = "200m" > - It's deployed behind a feature flag, disabled by default. > - It's disabled on GitLab.com. > - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../security/two_factor_authentication.md#enable-or-disable-two-factor-authentication-2fa-for-git-operations) +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../security/two_factor_authentication.md#enable-or-disable-two-factor-authentication-2fa-for-git-operations). + +NOTE: +This feature is under development and not ready for production use. It is deployed +behind a feature flag that is **disabled by default**. To use it in GitLab +self-managed instances, ask a GitLab administrator to [enable it](../../../security/two_factor_authentication.md#enable-or-disable-two-factor-authentication-2fa-for-git-operations). GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080. diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md index 69d86259409..3b56318e711 100644 --- a/doc/user/admin_area/settings/continuous_integration.md +++ b/doc/user/admin_area/settings/continuous_integration.md @@ -18,7 +18,7 @@ for all projects: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > CI/CD**. 1. Check (or uncheck to disable) the box that says **Default to Auto DevOps pipeline for all projects**. -1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/index.md#auto-devops-base-domain) +1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/requirements.md#auto-devops-base-domain) which is used for Auto Deploy and Auto Review Apps. 1. Hit **Save changes** for the changes to take effect. @@ -262,10 +262,20 @@ To disable it: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > CI/CD**. 1. Expand the **Package Registry** section. -1. Uncheck **Enable forwarding of npm package requests to npmjs.org**. -1. Click **Save changes**. +1. Clear the checkbox **Forward npm package requests to the npm Registry if the packages are not found in the GitLab Package Registry**. +1. Select **Save changes**. + +### PyPI Forwarding **(PREMIUM SELF)** + +GitLab administrators can disable the forwarding of PyPI requests to [pypi.org](https://pypi.org/). + +To disable it: - +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand the **Package Registry** section. +1. Clear the checkbox **Forward PyPI package requests to the PyPI Registry if the packages are not found in the GitLab Package Registry**. +1. Select **Save changes**. ### Package file size limits diff --git a/doc/user/admin_area/settings/email.md b/doc/user/admin_area/settings/email.md index e637408328d..236b75797a2 100644 --- a/doc/user/admin_area/settings/email.md +++ b/doc/user/admin_area/settings/email.md @@ -13,27 +13,40 @@ You can customize some of the content in emails sent from your GitLab instance. The logo in the header of some emails can be customized, see the [logo customization section](../appearance.md#navigation-bar). -## Custom additional text **(PREMIUM SELF)** +## Include author name in email notification email body **(PREMIUM SELF)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5031) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7. +By default, GitLab overrides the email address in notification emails with the email address +of the issue, merge request, or comment author. Enable this setting to include the author's email +address in the body of the email instead. -The additional text appears at the bottom of any email and can be used for -legal/auditing/compliance reasons. +To include the author's email address in the email body: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`). 1. Expand **Email**. -1. Enter your text in the **Additional text** field. -1. Click **Save**. +1. Select the **Include author name in email notification email body** checkbox. +1. Select **Save changes**. + +## Enable multipart email **(PREMIUM SELF)** + +GitLab can send email in multipart format (HTML and plain text) or plain text only. + +To enable multipart email: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`). +1. Expand **Email**. +1. Select **Enable multipart email**. +1. Select **Save changes**. -## Custom hostname for private commit emails +## Custom hostname for private commit emails **(PREMIUM SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22560) in GitLab 11.5. This configuration option sets the email hostname for [private commit emails](../../profile/index.md#use-an-automatically-generated-private-commit-email). By default it is set to `users.noreply.YOUR_CONFIGURED_HOSTNAME`. -In order to change this option: +To change the hostname used in private commit emails: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`). @@ -42,10 +55,23 @@ In order to change this option: 1. Select **Save changes**. NOTE: -After the hostname gets configured, every private commit email using the previous hostname is not +After the hostname is configured, every private commit email using the previous hostname is not recognized by GitLab. This can directly conflict with certain [Push rules](../../../push_rules/push_rules.md) such as `Check whether author is a GitLab user` and `Check whether committer is the current authenticated user`. +## Custom additional text **(PREMIUM SELF)** + +You can add additional text at the bottom of any email that GitLab sends. This additional text +can be used for legal, auditing, or compliance reasons, for example. + +To add additional text to emails: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > Preferences** (`/admin/application_settings/preferences`). +1. Expand **Email**. +1. Enter your text in the **Additional text** field. +1. Select **Save changes**. + <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues diff --git a/doc/user/admin_area/settings/floc.md b/doc/user/admin_area/settings/floc.md index 31a626478ed..0e9d4e5d0c1 100644 --- a/doc/user/admin_area/settings/floc.md +++ b/doc/user/admin_area/settings/floc.md @@ -8,8 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60933) in GitLab Free 13.12. -Federated Learning of Conhorts (FLoC) is a feature that the Chrome browser has -rolled out, where users are categorized into different cohorts, so that +Federated Learning of Cohorts (FLoC) is a new feature of the Chrome browser. +It works by categorizing users into different cohorts, so that advertisers can use this data to uniquely target and track users. For more information, visit the [FLoC repository](https://github.com/WICG/floc). diff --git a/doc/user/admin_area/settings/help_page.md b/doc/user/admin_area/settings/help_page.md index d2f99a51ec3..01516430f4f 100644 --- a/doc/user/admin_area/settings/help_page.md +++ b/doc/user/admin_area/settings/help_page.md @@ -5,10 +5,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: howto --- -# Customize the Help and sign-in page messages +# Customize the Help and sign-in page messages **(FREE SELF)** In large organizations, it is useful to have information about who to contact or where -to go for help. You can customize and display this information on the GitLab `/help` page and on +to go for help. You can customize and display this information on the GitLab `/help` page and on the GitLab sign-in page. ## Add a help message to the Help page @@ -17,32 +17,39 @@ You can add a help message, which is shown at the top of the GitLab `/help` page <https://gitlab.com/help>): 1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. -1. Under **Additional text to show on the Help page**, fill in the information you wish to display on `/help`. -1. Select **Save changes**. You can now see the message on `/help`. +1. On the left sidebar, select **Settings > Preferences**. +1. Expand **Sign-in and Help page**. +1. In **Additional text to show on the Help page**, enter the information you want to display on `/help`. +1. Select **Save changes**. + +You can now see the message on `/help`. NOTE: By default, `/help` is visible to unauthenticated users. However, if the -[**Public** visibility level](visibility_and_access_controls.md#restricted-visibility-levels) +[**Public** visibility level](visibility_and_access_controls.md#restrict-visibility-levels) is restricted, `/help` is visible only to signed-in users. -## Add a help message to the sign-in page **(STARTER)** +## Add a help message to the sign-in page You can add a help message, which is shown on the GitLab sign-in page. The message appears in a new section titled **Need Help?**, located below the sign-in page message: 1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. -1. Under **Additional text to show on the sign-in page**, fill in the information you wish to +1. On the left sidebar, select **Settings > Preferences**. +1. Expand **Sign-in and Help page**. +1. In **Additional text to show on the sign-in page**, enter the information you want to display on the sign-in page. -1. Select **Save changes**. You can now see the message on the sign-in page. +1. Select **Save changes**. + +You can now see the message on the sign-in page. ## Hide marketing-related entries from the Help page GitLab marketing-related entries are occasionally shown on the Help page. To hide these entries: 1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. +1. On the left sidebar, select **Settings > Preferences**. +1. Expand **Sign-in and Help page**. 1. Select the **Hide marketing-related entries from the Help page** checkbox. 1. Select **Save changes**. @@ -54,10 +61,48 @@ You can specify a custom URL to which users are directed when they: - Select **See our website for help** on the Help page. 1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. -1. Enter the URL in the **Support page URL** field. +1. On the left sidebar, select **Settings > Preferences**. +1. Expand **Sign-in and Help page**. +1. In the **Support page URL** field, enter the URL. 1. Select **Save changes**. +## Redirect `/help` pages + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43157) in GitLab 13.5. +> - Enabled on GitLab.com and is ready for production use. + +FLAG: +On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to +[enable the `:help_page_documentation_redirect` flag](../../../administration/feature_flags.md). +On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. + +The `/help` URL of a GitLab instance displays a basic version of the documentation sourced from the +[`doc` directory](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc) of GitLab. `/help` links +are often used for contextual help. + +You can redirect these `/help` links to either: + +- The more navigable and searchable version published at [`docs.gitlab.com`](https://docs.gitlab.com). +- A destination that meets [necessary requirements](#destination-requirements). + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**. +1. Expand **Sign-in and Help page**. +1. In the **Documentation pages URL** field, enter the URL. +1. Select **Save changes**. + +### Destination requirements + +When redirecting `/help`, GitLab: + +- Redirects requests to the specified URL. +- Appends `ee` and the documentation path to the URL. +- Appends `.html` to the URL, and removes `.md` if necessary. + +For example, if the URL is set to `https://docs.gitlab.com`, requests for +`/help/user/admin_area/settings/help_page.md` redirect to: +`https://docs.gitlab.com/ee/user/admin_area/settings/help_page.html`. + <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues diff --git a/doc/user/admin_area/settings/img/admin_package_registry_npm_package_requests_forward.png b/doc/user/admin_area/settings/img/admin_package_registry_npm_package_requests_forward.png Binary files differdeleted file mode 100644 index b6068f5d19b..00000000000 --- a/doc/user/admin_area/settings/img/admin_package_registry_npm_package_requests_forward.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/clone_panel_v12_4.png b/doc/user/admin_area/settings/img/clone_panel_v12_4.png Binary files differdeleted file mode 100644 index 427224f5b78..00000000000 --- a/doc/user/admin_area/settings/img/clone_panel_v12_4.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/domain_denylist.png b/doc/user/admin_area/settings/img/domain_denylist.png Binary files differdeleted file mode 100644 index a7e972b7c0a..00000000000 --- a/doc/user/admin_area/settings/img/domain_denylist.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/domain_denylist_v14_1.png b/doc/user/admin_area/settings/img/domain_denylist_v14_1.png Binary files differnew file mode 100644 index 00000000000..c988afd75f6 --- /dev/null +++ b/doc/user/admin_area/settings/img/domain_denylist_v14_1.png diff --git a/doc/user/admin_area/settings/img/enforce_terms.png b/doc/user/admin_area/settings/img/enforce_terms.png Binary files differdeleted file mode 100644 index de1a82275ab..00000000000 --- a/doc/user/admin_area/settings/img/enforce_terms.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v13_1.png b/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v13_1.png Binary files differdeleted file mode 100644 index 9edc916c7fb..00000000000 --- a/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v13_1.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v14_2.png b/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v14_2.png Binary files differnew file mode 100644 index 00000000000..63f4d5a4a1a --- /dev/null +++ b/doc/user/admin_area/settings/img/rate_limit_on_issues_creation_v14_2.png diff --git a/doc/user/admin_area/settings/img/respond_to_terms.png b/doc/user/admin_area/settings/img/respond_to_terms.png Binary files differdeleted file mode 100644 index f91480d1ce7..00000000000 --- a/doc/user/admin_area/settings/img/respond_to_terms.png +++ /dev/null diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index d21b6c36224..21ca1c573fe 100644 --- a/doc/user/admin_area/settings/index.md +++ b/doc/user/admin_area/settings/index.md @@ -51,10 +51,10 @@ To access the default page for Admin Area settings: | Option | Description | | ------ | ----------- | | [Repository's custom initial branch name](../../project/repository/branches/default.md#instance-level-custom-initial-branch-name) | Set a custom branch name for new repositories created in your instance. | -| [Repository mirror](visibility_and_access_controls.md#allow-mirrors-to-be-set-up-for-projects) | Configure repository mirroring. | +| [Repository mirror](visibility_and_access_controls.md#enable-project-mirroring) | Configure repository mirroring. | | [Repository storage](../../../administration/repository_storage_types.md) | Configure storage path settings. | | Repository maintenance | ([Repository checks](../../../administration/repository_checks.md) and [Housekeeping](../../../administration/housekeeping.md)). Configure automatic Git checks and housekeeping on repositories. | -| [Repository static objects](../../../administration/static_objects_external_storage.md) | Serve repository static objects (for example, archives, blobs, ...) from an external storage (for example, a CDN). | +| [Repository static objects](../../../administration/static_objects_external_storage.md) | Serve repository static objects (for example, archives and blobs) from an external storage (for example, a CDN). | ## Templates **(PREMIUM SELF)** @@ -84,8 +84,8 @@ To access the default page for Admin Area settings: | ------ | ----------- | | [Metrics - Prometheus](../../../administration/monitoring/prometheus/gitlab_metrics.md) | Enable and configure Prometheus metrics. | | [Metrics - Grafana](../../../administration/monitoring/performance/grafana_configuration.md#integration-with-gitlab-ui) | Enable and configure Grafana. | -| [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-via-the-admin-area) | Enable access to the Performance Bar for a given group. | -| [Self monitoring](../../../administration/monitoring/gitlab_self_monitoring_project/index.md#creating-the-self-monitoring-project) | Enable or disable instance self monitoring. | +| [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-for-non-administrators) | Enable access to the Performance Bar for non-administrator users in a given group. | +| [Self monitoring](../../../administration/monitoring/gitlab_self_monitoring_project/index.md#create-the-self-monitoring-project) | Enable or disable instance self monitoring. | | [Usage statistics](usage_statistics.md) | Enable or disable version check and Service Ping. | | [Pseudonymizer data collection](../../../administration/pseudonymizer.md) **(ULTIMATE)** | Enable or disable the Pseudonymizer data collection. | @@ -115,7 +115,7 @@ To access the default page for Admin Area settings: | [What's new](../../../administration/whats-new.md) | Configure What's new drawer and content. | | [Help page](help_page.md) | Help page text and support page URL. | | [Pages](../../../administration/pages/index.md#custom-domain-verification) | Size and domain settings for static websites | -| [Real-time features](../../../administration/polling.md) | Change this value to influence how frequently the GitLab UI polls for updates. | +| [Polling interval multiplier](../../../administration/polling.md) | Configure how frequently the GitLab UI polls for updates. | | [Gitaly timeouts](gitaly_timeouts.md) | Configure Gitaly timeouts. | | Localization | [Default first day of the week](../../profile/preferences.md) and [Time tracking](../../project/time_tracking.md#limit-displayed-units-to-hours). | diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md index 3140eecfa53..3b949b638d8 100644 --- a/doc/user/admin_area/settings/project_integration_management.md +++ b/doc/user/admin_area/settings/project_integration_management.md @@ -1,6 +1,6 @@ --- -stage: Create -group: Ecosystem +stage: Ecosystem +group: Integrations info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- @@ -61,6 +61,18 @@ integration on all non-configured groups and projects by default. Resetting an instance-level default setting removes the integration from all projects that have the integration set to use default settings. +### View projects that override the default settings + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218252) in GitLab 14.2. + +You can view which projects in your instance use custom settings that [override the instance-level default settings](#use-custom-settings-for-a-group-or-project-integration) +for an integration. + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Integrations**. +1. Select an integration. +1. Select the **Projects using custom settings** tab. + ## Manage group-level default settings for a project integration > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6. diff --git a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md index ef2b8ad80cd..bba61a7b913 100644 --- a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md +++ b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28129) in GitLab 12.10. -This setting allows you to rate limit the requests to the issue creation endpoint. +This setting allows you to rate limit the requests to the issue and epic creation endpoints. To can change its value: 1. On the top bar, select **Menu >** **{admin}** **Admin**. @@ -22,7 +22,9 @@ For example, if you set a limit of 300, requests using the [Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/raw/master/app/controllers/projects/issues_controller.rb) action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute. - +When using [epics](../../group/epics/index.md), epic creation will share this rate limit with issues. + + This limit is: diff --git a/doc/user/admin_area/settings/rate_limit_on_notes_creation.md b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md index 193f39542cf..7615ad6f81d 100644 --- a/doc/user/admin_area/settings/rate_limit_on_notes_creation.md +++ b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md @@ -17,7 +17,7 @@ To change the note creation rate limit: 1. On the left sidebar, select **Settings > Network**. 1. Expand **Notes Rate Limits**. 1. Under **Max requests per minute per user**, enter the new value. -1. Optional. Under **List of users to be excluded from the limit**, list users to be excluded fromt the limit. +1. Optional. Under **List of users to be excluded from the limit**, list users to be excluded from the limit. 1. Select **Save changes**. This limit is: diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 1098c7060f8..c774ae2eecc 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -31,7 +31,10 @@ To disable sign ups: > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6. -When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled. +When this setting is enabled, any user visiting your GitLab domain and signing up for a new account +must be explicitly [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an +administrator before they can start using their account. In GitLab 13.6 and later, this setting is +enabled by default for new GitLab instances. It is only applicable if sign ups are enabled. To require administrator approval for new sign ups: @@ -59,7 +62,7 @@ To enforce confirmation of the email address used for new sign ups: > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9. When the number of billable users reaches the user cap, any user who is added or requests access must be -[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using +[approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the @@ -145,7 +148,7 @@ To create an email domain allowlist or denylist: domains ending in `.io`. Domains must be separated by a whitespace, semicolon, comma, or a new line. -  +  ### Enable or disable soft email confirmation diff --git a/doc/user/admin_area/settings/terms.md b/doc/user/admin_area/settings/terms.md index 46e85ffc9c0..21805ef771f 100644 --- a/doc/user/admin_area/settings/terms.md +++ b/doc/user/admin_area/settings/terms.md @@ -5,59 +5,35 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# Enforce accepting Terms of Service **(FREE SELF)** +# Terms of Service and Privacy Policy **(FREE SELF)** -An administrator can enforce acceptance of a terms of service and privacy policy. When this option is enabled, new and existing users must accept the terms. +An administrator can enforce acceptance of a terms of service and privacy policy. +When this option is enabled, new and existing users must accept the terms. -If configured, the Terms of Service page can be viewed via `https://your-instance.com/-/users/terms` at anytime. +When enabled, you can view the Terms of Service at the `-/users/terms` page on the instance, +for example `https://gitlab.example.com/-/users/terms`. -## Configuration +## Enforce a Terms of Service and Privacy Policy To enforce acceptance of a Terms of Service and Privacy Policy: -1. Log in to the GitLab instance as an admin user. 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > General**. 1. Expand the **Terms of Service and Privacy Policy** section. -1. Check the **Require all users to accept Terms of Service and Privacy Policy when they access - GitLab.** checkbox. -1. Input the text of the **Terms of Service and Privacy Policy**. Markdown formatting can be used in this input box. +1. Check the **All users must accept the Terms of Service and Privacy Policy to access GitLab** checkbox. +1. Input the text of the **Terms of Service and Privacy Policy**. You can use [Markdown](../../markdown.md) + in this text box. 1. Click **Save changes**. -1. When you are presented with the **Terms of Service** statement, click **Accept terms**. - - For each update to the terms, a new version is stored. When a user accepts or declines the terms, GitLab records which version they accepted or declined. -## New users - -When this feature is enabled, a checkbox is added to the sign-up form. +When enabled, it adds a mandatory checkbox to the sign up page for new users:  -This checkbox is required during sign up. - -Users can review the terms entered in the admin panel before -accepting. The page is opened in a new window so they can -continue their registration afterwards. - -## Accepting terms - -When this feature is enabled, the users that have not accepted the -terms of service are presented with a screen where they can either -accept or decline the terms. - - - -If the user accepts the terms, they are directed to where they -were going. After a sign-in or sign-up this is most likely the -dashboard. - -If the user was already logged in when the feature was turned on, -they are asked to accept the terms on their next interaction. - -If a user declines the terms, they are signed out. +Existing users must accept the terms on their next GitLab interaction. +If a logged-in user declines the terms, they are signed out. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index c12b720edd2..89c6be9608b 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -10,25 +10,24 @@ type: reference GitLab Inc. periodically collects information about your instance in order to perform various actions. -All statistics are opt-out. To enable or disable them: +All usage statistics are [opt-out](#enable-or-disable-usage-statistics). -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**. -1. Enable or disable **Version check** and **Service ping**. -1. Select **Save changes**. +## Service Ping **(FREE SELF)** -## Network configuration +Service Ping is a process that collects and sends a weekly payload to GitLab Inc. +For more information, see the [Service Ping guide](../../../development/service_ping/index.md). -Allow network traffic from your GitLab instance to IP address `104.196.17.203:443`, to send -usage statistics to GitLab Inc. +### Instance-level analytics availability -If your GitLab instance is behind a proxy, set the appropriate [proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html). +When Service Ping is enabled, GitLab gathers data from other instances and +enables certain [instance-level analytics features](../analytics/index.md) +that are dependent on Service Ping. -## Version Check **(FREE SELF)** +## Version check **(FREE SELF)** If enabled, version check informs you if a new version is available and the -importance of it through a status. This is shown on the help page (i.e. `/help`) -for all signed in users, and on the admin pages. The statuses are: +importance of it through a status. The status displays on the help pages (`/help`) +for all signed-in users, and on the Admin Area pages. The statuses are: - Green: You are running the latest version of GitLab. - Orange: An updated version of GitLab is available. @@ -44,17 +43,12 @@ This information is used, among other things, to identify to which versions patches must be backported, making sure active GitLab instances remain secure. -If you disable version check, this information isn't collected. To enable or disable it: - -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**. -1. Enable or disable **Version check**. -1. Select **Save changes**. +If you [disable version check](#enable-or-disable-usage-statistics), this information isn't collected. ### Request flow example -The following example shows a basic request/response flow between the self-managed GitLab instance -and the GitLab Version Application: +The following example shows a basic request/response flow between a +self-managed GitLab instance and the GitLab Version Application: ```mermaid sequenceDiagram @@ -67,14 +61,22 @@ sequenceDiagram Version Application->>GitLab instance: Response (PNG/SVG) ``` -## Service Ping **(FREE SELF)** +## Configure your network + +To send usage statistics to GitLab Inc., you must allow network traffic from your +GitLab instance to the IP address `104.196.17.203:443`. + +If your GitLab instance is behind a proxy, set the appropriate +[proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html). -See [Service Ping guide](../../../development/service_ping/index.md). +## Enable or disable usage statistics -## Instance-level analytics availability +To enable or disable Service Ping and version check: -After Service Ping is enabled, GitLab gathers data from other instances and -enables certain [instance-level analytics features](../analytics/index.md) that are dependent on Service Ping. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**. +1. Select or clear the **Version check** and **Service ping** checkboxes. +1. Select **Save changes**. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md index 4af33c133a4..c46aec76e57 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -5,9 +5,10 @@ info: "To determine the technical writer assigned to the Stage/Group associated type: reference --- -# Visibility and access controls **(FREE SELF)** +# Control access and visibility **(FREE SELF)** -GitLab allows administrators to enforce specific controls. +GitLab enables users with the [Administrator role](../../permissions.md) to enforce +specific controls on branches, projects, snippets, groups, and more. To access the visibility and access control options: @@ -16,59 +17,95 @@ To access the visibility and access control options: 1. In the left sidebar, select **Settings > General**. 1. Expand the **Visibility and access controls** section. -## Default branch protection +## Protect default branches -This global option defines the branch protection that applies to every repository's -[default branch](../../project/repository/branches/default.md). -[Branch protection](../../project/protected_branches.md) specifies which roles can push -to branches and which roles can delete branches. In this case _Default_ refers to a -repository's [default branch](../../project/repository/branches/default.md). +With this option, you can define [branch protections](../../project/protected_branches.md) +to apply to every repository's [default branch](../../project/repository/branches/default.md). +These protections specify the user roles with permission to: -This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [protected branches](../../project/protected_branches.md). +- Push to branches. +- Delete branches. -To change the default branch protection: +This setting applies only to each repository's default branch. To protect other branches, +you must configure [branch protection in the repository](../../project/protected_branches.md), +or configure [branch protection for groups](../../group/index.md#change-the-default-branch-protection-of-a-group). -1. Select the desired option. -1. Click **Save changes**. - -For more details, see [Protected branches](../../project/protected_branches.md). +To change the default branch protection for the entire instance: -To change this setting for a specific group, see [Default branch protection for groups](../../group/index.md#change-the-default-branch-protection-of-a-group) +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select a **Default branch protection**: + - **Not protected** - Both developers and maintainers can push new commits, + force push, or delete the branch. + - **Protected against pushes** - Developers cannot push new commits, but are + allowed to accept merge requests to the branch. Maintainers can push to the branch. + - **Partially protected** - Both developers and maintainers can push new commits, + but cannot force push or delete the branch. + - **Fully protected** - Developers cannot push new commits, but maintainers can. + No one can force push or delete the branch. +1. To allow group owners to override the instance's default branch protection, select + [**Allow owners to manage default branch protection per group**](#prevent-overrides-of-default-branch-protection). +1. Select **Save changes**. -### Disable group owners from updating default branch protection **(PREMIUM SELF)** +### Prevent overrides of default branch protection **(PREMIUM SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211944) in GitLab 13.0. -By default, group owners are allowed to override the branch protection set at the global level. - -In [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can disable this privilege of group owners. - -To do this: +Instance-level protections for [default branch](../../project/repository/branches/default.md) +can be overridden on a per-group basis by the group's owner. In +[GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can +disable this privilege for group owners, enforcing the instance-level protection rule: -1. Uncheck the **Allow owners to manage default branch protection per group** checkbox. +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Deselect the **Allow owners to manage default branch protection per group** checkbox. +1. Select **Save changes**. NOTE: GitLab administrators can still update the default branch protection of a group. -## Default project creation protection +## Define which roles can create projects -Project creation protection specifies which roles can create projects. +Instance-level protections for project creation define which roles can +[add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group)] +on the instance. To alter which roles have permission to create projects: -To change the default project creation protection: +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. For **Default project creation protection**, select the desired roles: + - No one. + - Maintainers. + - Developers and Maintainers. +1. Select **Save changes**. -1. Select the desired option. -1. Click **Save changes**. +## Restrict project deletion to Administrators **(PREMIUM SELF)** + +Anyone with the **Owner** role, either at the project or group level, can +delete a project. To allow only users with the Administrator role to delete projects: -For more details, see [Specify who can add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group). +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Scroll to **Default project deletion protection**, and select **Only admins can delete project**. +1. Select **Save changes**. -## Default project deletion protection **(PREMIUM SELF)** +## Default delayed project deletion **(PREMIUM SELF)** -By default, a project can be deleted by anyone with the **Owner** role, either at the project or -group level. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/255449) in GitLab 14.2. -To ensure only Administrator users can delete projects: +Projects in a group (but not a personal namespace) can be deleted after a delayed period, by +[configuring in Group Settings](../../group/index.md#enable-delayed-project-removal). -1. Check the **Default project deletion protection** checkbox. +To enable delayed project deletion by default in new groups: + +1. Check the **Default delayed project deletion** checkbox. 1. Click **Save changes**. ## Default deletion delay **(PREMIUM SELF)** @@ -92,7 +129,7 @@ To change this period: 1. Select the desired option. 1. Click **Save changes**. -### Override default deletion delayed period +### Override defaults and delete immediately Alternatively, projects that are marked for removal can be deleted immediately. To do so: @@ -100,107 +137,132 @@ Alternatively, projects that are marked for removal can be deleted immediately. 1. Delete the project as described in the [Administering Projects page](../../admin_area/#administering-projects). -## Default project visibility - -To set the default visibility levels for new projects: +## Configure project visibility defaults -1. Select the desired default project visibility. -1. Click **Save changes**. +To set the default [visibility levels for new projects](../../../public_access/public_access.md): -For more details on project visibility, see -[Project visibility](../../../public_access/public_access.md). +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select the desired default project visibility: + - **Private** - Project access must be granted explicitly to each user. If this + project is part of a group, access will be granted to members of the group. + - **Internal** - The project can be accessed by any logged in user except external users. + - **Public** - The project can be accessed without any authentication. +1. Select **Save changes**. -## Default snippet visibility +## Configure snippet visibility defaults -To set the default visibility levels for new snippets: +To set the default visibility levels for new [snippets](../../snippets.md): +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. 1. Select the desired default snippet visibility. -1. Click **Save changes**. +1. Select **Save changes**. -For more details on snippet visibility, see +For more details on snippet visibility, read [Project visibility](../../../public_access/public_access.md). -## Default group visibility +## Configure group visibility defaults To set the default visibility levels for new groups: -1. Select the desired default group visibility. -1. Click **Save changes**. +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select the desired default group visibility: + - **Private** - The group and its projects can only be viewed by members. + - **Internal** - The group and any internal projects can be viewed by any logged in user except external users. + - **Public** - The group and any public projects can be viewed without any authentication. +1. Select **Save changes**. For more details on group visibility, see [Group visibility](../../group/index.md#group-visibility). -## Restricted visibility levels +## Restrict visibility levels -To set the restricted visibility levels for projects, snippets, and selected pages: +To restrict visibility levels for projects, snippets, and selected pages: -1. Select the desired visibility levels to restrict. +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. In the **Restricted visibility levels** section, select the desired visibility levels to restrict. 1. Select **Save changes**. For more details on project visibility, see [Project visibility](../../../public_access/public_access.md). -## Import sources - -To specify from which hosting sites users can [import their projects](../../project/import/index.md): - -1. Check the checkbox beside the name of each hosting site. -1. Click **Save changes**. +## Configure allowed import sources -## Project export +You can specify from which hosting sites users can [import their projects](../../project/import/index.md): -To enable project export: +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select each of **Import sources** to allow. +1. Select **Save changes**. -1. Check the **Project export enabled** checkbox. -1. Click **Save changes**. +## Enable project export -For more details, see [Exporting a project and its data](../../../user/project/settings/import_export.md#exporting-a-project-and-its-data). +To enable the export of +[projects and their data](../../../user/project/settings/import_export.md#export-a-project-and-its-data): -## Enabled Git access protocols +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select **Project export enabled**. +1. Select **Save changes**. -With GitLab access restrictions, you can select with which protocols users can communicate with -GitLab. +## Configure enabled Git access protocols -Disabling an access protocol does not block access to the server itself by using those ports. The ports -used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the -application level. +With GitLab access restrictions, you can select the protocols users can use to +communicate with GitLab. Disabling an access protocol does not block port access to the +server itself. The ports used for the protocol, SSH or HTTP(S), are still accessible. +The GitLab restrictions apply at the application level. To specify the enabled Git access protocols: -1. Select the desired Git access protocols from the dropdown: +1. Sign in to GitLab as a user with [Administrator role](../../permissions.md). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. +1. Expand the **Visibility and access controls** section. +1. Select the desired Git access protocols: - Both SSH and HTTP(S) - Only SSH - Only HTTP(S) -1. Click **Save changes**. +1. Select **Save changes**. When both SSH and HTTP(S) are enabled, users can choose either protocol. - -When only one protocol is enabled: +If only one protocol is enabled: - The project page shows only the allowed protocol's URL, with no option to change it. -- A tooltip is shown when you hover over the URL's protocol, if an action - on the user's part is required. For example, adding an SSH key or setting a password. +- GitLab shows a tooltip when you hover over the URL's protocol, if user action + (such as adding a SSH key or setting a password) is required: - +  -On top of these UI restrictions, GitLab denies all Git actions on the protocol -not selected. +GitLab only allows Git actions for the protocols you select. WARNING: GitLab versions [10.7 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021), allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner -from CI/CD jobs, even if **Only SSH** was selected. +from CI/CD jobs, even if you select **Only SSH**. -## Custom Git clone URL for HTTP(S) +## Customize Git clone URL for HTTP(S) > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18422) in GitLab 12.4. You can customize project Git clone URLs for HTTP(S), which affects the clone panel: - - For example, if: - Your GitLab instance is at `https://example.com`, then project clone URLs are like @@ -219,7 +281,7 @@ NOTE: SSH clone URLs can be customized in `gitlab.rb` by setting `gitlab_rails['gitlab_ssh_host']` and other related settings. -## RSA, DSA, ECDSA, ED25519 SSH keys +## Configure defaults for RSA, DSA, ECDSA, ED25519 SSH keys These options specify the permitted types and lengths for SSH keys. @@ -230,7 +292,7 @@ To specify a restriction for each key type: For more details, see [SSH key restrictions](../../../security/ssh_keys_restrictions.md). -## Allow mirrors to be set up for projects +## Enable project mirroring This option is enabled by default. By disabling it, both [pull and push mirroring](../../project/repository/repository_mirroring.md) no longer |
