diff options
Diffstat (limited to 'doc/user/admin_area')
49 files changed, 491 insertions, 302 deletions
diff --git a/doc/user/admin_area/abuse_reports.md b/doc/user/admin_area/abuse_reports.md index 5424d4d2cb4..4bfa277fc9f 100644 --- a/doc/user/admin_area/abuse_reports.md +++ b/doc/user/admin_area/abuse_reports.md @@ -1,5 +1,6 @@ --- redirect_to: 'review_abuse_reports.md' +remove_date: '2021-07-21' --- This file was moved to [another location](review_abuse_reports.md). diff --git a/doc/user/admin_area/activating_deactivating_users.md b/doc/user/admin_area/activating_deactivating_users.md index cafc7caf981..e89c42b34ba 100644 --- a/doc/user/admin_area/activating_deactivating_users.md +++ b/doc/user/admin_area/activating_deactivating_users.md @@ -1,5 +1,6 @@ --- redirect_to: 'moderate_users.md' +remove_date: '2021-08-12' --- This document was moved to [another location](moderate_users.md). diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md index b13faf2bb3e..6ca5e5034bf 100644 --- a/doc/user/admin_area/analytics/dev_ops_report.md +++ b/doc/user/admin_area/analytics/dev_ops_report.md @@ -1,21 +1,23 @@ --- -stage: none -group: unassigned +stage: Manage +group: Optimize 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 --- -# DevOps Report +# DevOps Report **(FREE SELF)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30469) in GitLab 9.3. -> - [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/-/issues/20976) in GitLab 12.6. +> [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/-/issues/20976) in GitLab 12.6. The DevOps Report gives you an overview of your entire instance's adoption of [Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/) from planning to monitoring. -To see DevOps Report, go to **Admin Area > Analytics > DevOps Report**. +To see DevOps Report: -## DevOps Score **(FREE)** +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Analytics > DevOps Report**. + +## DevOps Score NOTE: Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature. @@ -34,21 +36,30 @@ Usage ping data is aggregated on GitLab servers for analysis. Your usage information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be collected before this feature is available. -## DevOps Adoption **(ULTIMATE)** +## 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). +> - [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 DevOps Adoption tab shows you which groups within your organization are using the most essential features of GitLab: -- Issues -- Merge Requests -- Approvals -- Runners -- Pipelines -- Deploys -- Scanning - -Buttons to manage your groups appear in the DevOps Adoption section of the page. +- Dev + - Issues + - Merge Requests + - Approvals + - Code owners +- Sec + - Scans +- Ops + - Runners + - Pipelines + - Deployments + +When managing groups in the UI, you can add your groups with the **Add group to table** +button, in the top right hand section the page. DevOps Adoption allows you to: @@ -56,20 +67,22 @@ DevOps Adoption allows you to: - 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 **disabled by default**. +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 enable it. +can opt to disable it. -To enable it: +To disable it: ```ruby -Feature.enable(:devops_adoption_feature) +Feature.disable(:devops_adoption_feature) ``` -To disable it: +To reenable it: ```ruby -Feature.disable(:devops_adoption_feature) +Feature.enable(:devops_adoption_feature) ``` diff --git a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png Binary files differnew file mode 100644 index 00000000000..f4170b2938c --- /dev/null +++ b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png diff --git a/doc/user/admin_area/analytics/img/instance_activity_pipelines_chart_v13_6_a.png b/doc/user/admin_area/analytics/img/instance_activity_pipelines_chart_v13_6_a.png Binary files differindex 210c5c2609a..bd02065556c 100644 --- a/doc/user/admin_area/analytics/img/instance_activity_pipelines_chart_v13_6_a.png +++ b/doc/user/admin_area/analytics/img/instance_activity_pipelines_chart_v13_6_a.png diff --git a/doc/user/admin_area/analytics/index.md b/doc/user/admin_area/analytics/index.md index bea22745e7b..465b26d516c 100644 --- a/doc/user/admin_area/analytics/index.md +++ b/doc/user/admin_area/analytics/index.md @@ -1,16 +1,19 @@ --- -stage: none -group: unassigned +stage: Manage +group: Optimize 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 --- -# Instance-level analytics +# Instance-level analytics **(FREE SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41416) in GitLab 11.2. -Administrators have access to instance-wide analytics, as shown in **Admin Area > Analytics**. +Administrators have access to instance-wide analytics: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Analytics**. There are several kinds of statistics: -- [DevOps Report](dev_ops_report.md): Provides an overview of your entire instance's feature usage. **(FREE)** -- [Usage Trends](usage_trends.md): Shows how much data your instance contains, and how that is changing. **(FREE)** +- [DevOps Report](dev_ops_report.md): Provides an overview of your entire instance's feature usage. +- [Usage Trends](usage_trends.md): Shows how much data your instance contains, and how that is changing. diff --git a/doc/user/admin_area/analytics/usage_trends.md b/doc/user/admin_area/analytics/usage_trends.md index 7fb23f702a4..49c81b1a965 100644 --- a/doc/user/admin_area/analytics/usage_trends.md +++ b/doc/user/admin_area/analytics/usage_trends.md @@ -4,7 +4,7 @@ group: Optimize 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 --- -# Usage Trends **(FREE)** +# Usage Trends **(FREE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235754) in GitLab 13.5 behind a feature flag, disabled by default. > - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46962) in GitLab 13.6. diff --git a/doc/user/admin_area/analytics/user_cohorts.md b/doc/user/admin_area/analytics/user_cohorts.md index ca5dff85757..b906f9b8fa6 100644 --- a/doc/user/admin_area/analytics/user_cohorts.md +++ b/doc/user/admin_area/analytics/user_cohorts.md @@ -1,5 +1,6 @@ --- redirect_to: '../user_cohorts.md' +remove_date: '2021-06-01' --- This document was moved to [another location](../user_cohorts.md). diff --git a/doc/user/admin_area/appearance.md b/doc/user/admin_area/appearance.md index 0d72f09dfd9..d7f0b7e3854 100644 --- a/doc/user/admin_area/appearance.md +++ b/doc/user/admin_area/appearance.md @@ -9,8 +9,10 @@ disqus_identifier: 'https://docs.gitlab.com/ee/customization/branded_login_page. # GitLab Appearance **(FREE SELF)** There are several options for customizing the appearance of a self-managed instance -of GitLab. These settings are accessed from the **Admin Area** in the **Appearance** -section. +of GitLab. To access these settings: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Appearance**. ## Navigation bar diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md index 2b3b90cb1a4..3d9722035d5 100644 --- a/doc/user/admin_area/approving_users.md +++ b/doc/user/admin_area/approving_users.md @@ -34,7 +34,8 @@ sign in. To view user sign ups pending approval: -1. Go to **Admin Area > Overview > Users**. +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 @@ -43,9 +44,10 @@ A user sign up pending approval can be approved or rejected from the Admin Area. To approve or reject a user sign up: -1. Go to **Admin Area > Overview > Users**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. 1. Select the **Pending approval** tab. -1. In the user's row select settings (**{settings}**). +1. In the user's row, select settings (**{settings}**). 1. Select **Approve** or **Reject**. Approving a user: diff --git a/doc/user/admin_area/blocking_unblocking_users.md b/doc/user/admin_area/blocking_unblocking_users.md index cafc7caf981..e89c42b34ba 100644 --- a/doc/user/admin_area/blocking_unblocking_users.md +++ b/doc/user/admin_area/blocking_unblocking_users.md @@ -1,5 +1,6 @@ --- redirect_to: 'moderate_users.md' +remove_date: '2021-08-12' --- This document was moved to [another location](moderate_users.md). diff --git a/doc/user/admin_area/broadcast_messages.md b/doc/user/admin_area/broadcast_messages.md index 67a89f896ff..93e6aa9bb16 100644 --- a/doc/user/admin_area/broadcast_messages.md +++ b/doc/user/admin_area/broadcast_messages.md @@ -5,21 +5,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference, howto --- -# Broadcast Messages **(FREE SELF)** +# Broadcast messages **(FREE SELF)** GitLab can display broadcast messages to all users of a GitLab instance. There are two types of broadcast messages: -- banners -- notifications +- Banners +- Notifications -You can style a message's content using the `a` and `br` HTML tags. The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties: - -- `color` -- `border` -- `background` -- `padding` -- `margin` -- `text-decoration` +Broadcast messages can be managed using the [broadcast messages API](../../api/broadcast_messages.md). ## Banners @@ -36,6 +29,8 @@ remote: ... ``` +If more than one banner is active at one time, they are displayed in a stack in order of creation. + ## Notifications Notifications are shown on the bottom right of a page and can contain placeholders. A placeholder is replaced with an attribute of the active user. Placeholders must be surrounded by curly braces, for example `{{name}}`. @@ -51,65 +46,63 @@ If the user is not signed in, user related values are empty.  -Broadcast messages can be managed using the [broadcast messages API](../../api/broadcast_messages.md). - -NOTE: -If more than one banner message is active at one time, they are displayed in a stack in order of creation. -If more than one notification message is active at one time, only the newest is shown. +If more than one notification is active at one time, only the newest is shown. -## Adding a broadcast message +## Add a broadcast message -To display messages to users on your GitLab instance, add broadcast message. +To display messages to users on your GitLab instance, add a broadcast message. To add a broadcast message: -1. Navigate to the **Admin Area > Messages** page. -1. Add the text for the message to the **Message** field. Markdown and emoji are supported. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Messages**. +1. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags. + The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties: + - `color` + - `border` + - `background` + - `padding` + - `margin` + - `text-decoration` 1. Select one of the suggested background colors, or add the hex code of a different color. The default color is orange. +1. Select the **Dismissable** checkbox to enable users to dismiss the broadcast message. 1. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `mygroup/myproject*`. 1. Select a date for the message to start and end. -1. Click the **Add broadcast message** button. - -NOTE: -When scoping messages, you can't use preceding or trailing slashes. For example, -instead of `/mygroup/myproject/`, you must use `mygroup/myproject`. A fix is -[planned for GitLab 13.12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59482). +1. Select **Add broadcast message**. NOTE: The **Background color** field expects the value to be a hexadecimal code because the form uses the [color_field](https://api.rubyonrails.org/v6.0.3.4/classes/ActionView/Helpers/FormHelper.html#method-i-color_field) helper method, which generates the proper HTML to render. -NOTE: -Once a broadcast message has expired, it is no longer displayed in the UI but is still listed in the -list of broadcast messages. User can also dismiss a broadcast message if the option **Dismissable** is set. +When a broadcast message expires, it no longer displays in the user interface but is still listed in the +list of broadcast messages. -## Editing a broadcast message +## Edit a broadcast message -If changes are required to a broadcast message, they can be edited. +If you need to make changes to a broadcast message, you can edit it. To edit a broadcast message: -1. Navigate to the **Admin Area > Messages** page. -1. From the list of broadcast messages, click the appropriate button to edit the message. -1. After making the required changes, click the **Update broadcast message** button. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Messages**. +1. From the list of broadcast messages, select the edit button for the message. +1. After making the required changes, select **Update broadcast message**. -NOTE: Expired messages can be made active again by changing their end date. -## Deleting a broadcast message +## Delete a broadcast message -Broadcast messages that are no longer required can be deleted. +If you no longer require a broadcast message, you can delete it. +You can delete a broadcast message while it's active. To delete a broadcast message: -1. Navigate to the **Admin Area > Messages** page. -1. From the list of broadcast messages, click the appropriate button to delete the message. - -Once deleted, the broadcast message is removed from the list of broadcast messages. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Messages**. +1. From the list of broadcast messages, select the delete button for the message. -NOTE: -Broadcast messages can be deleted while active. +When a broadcast message is deleted, it's removed from the list of broadcast messages. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md index c47dc7d70f5..dfb37cb8646 100644 --- a/doc/user/admin_area/credentials_inventory.md +++ b/doc/user/admin_area/credentials_inventory.md @@ -9,7 +9,9 @@ type: howto > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20912) in GitLab 12.6. -GitLab administrators are responsible for the overall security of their instance. To assist, GitLab provides a Credentials inventory to keep track of all the credentials that can be used to access their self-managed instance. +GitLab administrators are responsible for the overall security of their instance. To assist, GitLab +provides a Credentials inventory to keep track of all the credentials that can be used to access +their self-managed instance. Using Credentials inventory, you can see all the personal access tokens (PAT), SSH keys, and GPG keys that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token) @@ -21,7 +23,10 @@ and [delete](#delete-a-users-ssh-key) and see: - When they expire. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2. - When they were revoked. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2. -To access the Credentials inventory, navigate to **Admin Area > Credentials**. +To access the Credentials inventory: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Credentials**. The following is an example of the Credentials inventory page: diff --git a/doc/user/admin_area/custom_project_templates.md b/doc/user/admin_area/custom_project_templates.md index b4b33df37bf..6cf3c5bbd7d 100644 --- a/doc/user/admin_area/custom_project_templates.md +++ b/doc/user/admin_area/custom_project_templates.md @@ -30,12 +30,12 @@ see [Custom group-level project templates](../group/custom_project_templates.md) ## Configuring GitLab administrators can configure a GitLab group that serves as template -source for an entire GitLab instance by: +source for an entire GitLab instance: -1. Navigating to **Admin Area > Settings > Templates**. -1. Expanding **Custom project templates**. -1. Selecting a group to use. -1. Pressing **Save changes**. +1. On the top bar, navigate to **Menu > Admin > Settings > Templates**. +1. Expand **Custom project templates**. +1. Select a group to use. +1. Select **Save changes**. NOTE: Projects below subgroups of the template group are **not** supported. diff --git a/doc/user/admin_area/diff_limits.md b/doc/user/admin_area/diff_limits.md index 32756ab4780..37fdb3ae195 100644 --- a/doc/user/admin_area/diff_limits.md +++ b/doc/user/admin_area/diff_limits.md @@ -10,28 +10,34 @@ type: reference You can set a maximum size for display of diff files (patches). For details about diff files, [view changes between files](../project/merge_requests/changes.md). +Read more about the [built-in limits for merge requests and diffs](../../administration/instance_limits.md#merge-requests). -## Maximum diff patch size +## Configure diff limits -Diff files which exceed this value are presented as 'too large' and cannot -be expandable. Instead of an expandable view, a link to the blob view is -shown. +WARNING: +These settings are experimental. An increased maximum increases resource +consumption of your instance. Keep this in mind when adjusting the maximum. + +To speed the loading time of merge request views and branch comparison views +on your instance, you can configure three instance-level maximum values for diffs: + +- **Maximum diff patch size**: The total size, in bytes, of the entire diff. +- **Maximum diff files**: The total number of files changed in a diff. +- **Maximum diff files**: The total number of files changed in a diff. The default value is 1000. +- **Maximum diff lines**: The total number of lines changed in a diff. The default value is 50,000. -Patches greater than 10% of this size are automatically collapsed, and a -link to expand the diff is presented. -This affects merge requests and branch comparison views. +When a diff reaches 10% of any of these values, the files are shown in a +collapsed view, with a link to expand the diff. Diffs that exceed any of the +set values are presented as **Too large** are cannot be expanded in the UI. -To set the maximum diff patch size: +To configure these values: -1. Go to the Admin Area (**{admin}**) and select **Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand **Diff limits**. 1. Enter a value for **Maximum diff patch size**, measured in bytes. 1. Select **Save changes**. -WARNING: -This setting is experimental. An increased maximum increases resource -consumption of your instance. Keep this in mind when adjusting the maximum. - <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md index e5132ef4e96..32b1555c33d 100644 --- a/doc/user/admin_area/geo_nodes.md +++ b/doc/user/admin_area/geo_nodes.md @@ -82,7 +82,7 @@ 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 `gitlab_rails['geo_node_name']` must: -- Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`. +- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`. - Match a Geo node name. The load balancer must use sticky sessions in order to avoid authentication diff --git a/doc/user/admin_area/img/cohorts_v13_9_a.png b/doc/user/admin_area/img/cohorts_v13_9_a.png Binary files differindex a891b5b12c2..1a4590290b9 100644 --- a/doc/user/admin_area/img/cohorts_v13_9_a.png +++ b/doc/user/admin_area/img/cohorts_v13_9_a.png diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index 5d1fde1c767..2e4a8261c63 100644 --- a/doc/user/admin_area/index.md +++ b/doc/user/admin_area/index.md @@ -7,12 +7,13 @@ type: reference # GitLab Admin Area **(FREE SELF)** -The Admin Area provides a web UI for administering some features of GitLab self-managed instances. +The Admin Area provides a web UI to manage and configure some features of GitLab +self-managed instances. If you are an Admin user, you can access the Admin Area +by visiting `/admin` on your self-managed instance. You can also access it through +the UI: -To access the Admin Area, either: - -- Click the Admin Area icon (**{admin}**). -- Visit `/admin` on your self-managed instance. +- GitLab versions 14.0 and later: on the top bar, select **Menu >** **{admin}** **Admin**. +- GitLab versions 13.12 and earlier: on the top bar, select the Admin Area icon (**{admin}**). NOTE: Only admin users can access the Admin Area. @@ -35,7 +36,7 @@ The Admin Area is made up of the following sections: | **{location-dot}** Geo | Configure and maintain [Geo nodes](geo_nodes.md). | | **{key}** Deploy keys | Create instance-wide [SSH deploy keys](../project/deploy_keys/index.md). | | **{lock}** Credentials | View [credentials](credentials_inventory.md) that can be used to access your instance. | -| **{template}** Service Templates | Create [service templates](../project/integrations/services_templates.md) for projects. | +| **{template}** Integrations | Manage [instance-level default settings](settings/project_integration_management.md) for a project integration. | | **{labels}** Labels | Create and maintain [labels](labels.md) for your GitLab instance. | | **{appearance}** Appearance | Customize [GitLab appearance](appearance.md). | | **{settings}** Settings | Modify the [settings](settings/index.md) for your GitLab instance. | @@ -46,7 +47,7 @@ The Dashboard provides statistics and system information about the GitLab instan To access the Dashboard, either: -- Click the Admin Area icon (**{admin}**). +- On the top bar, select **Menu >** **{admin}** **Admin**. - Visit `/admin` on your self-managed instance. The Dashboard is the default view of the Admin Area, and is made up of the following sections: @@ -68,10 +69,12 @@ The following topics document the **Overview** section of the Admin Area. You can administer all projects in the GitLab instance from the Admin Area's Projects page. -To access the Projects page, go to **Admin Area > Overview > Projects**. +To access the Projects page: -Click the **All**, **Private**, **Internal**, or **Public** tab to list only projects of that -criteria. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Projects**. +1. Select the **All**, **Private**, **Internal**, or **Public** tab to list only + projects of that criteria. By default, all projects are listed, in reverse order of when they were last updated. For each project, the following information is listed: @@ -106,9 +109,10 @@ You can combine the filter options. For example, to list only public projects wi ### Administering Users -You can administer all users in the GitLab instance from the Admin Area's Users page. +You can administer all users in the GitLab instance from the Admin Area's Users page: -To access the Users page, go to **Admin Area > Overview > Users**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Users**. To list users matching a specific criteria, click on one of the following tabs on the **Users** page: @@ -151,7 +155,11 @@ An administrator can "impersonate" any other user, including other administrator This allows the administrator to "see what the user sees," and take actions on behalf of the user. You can impersonate a user in the following ways: -- Through the UI, by selecting **Admin Area > Overview > Users > Select a user > Impersonate**. +- Through the UI: + 1. On the top bar, select **Menu >** **{admin}** **Admin**. + 1. In the left sidebar, select **Overview > Users**. + 1. From the list of users, select a user. + 1. Select **Impersonate**. - With the API, using [impersonation tokens](../../api/README.md#impersonation-tokens). All impersonation activities are [captured with audit events](../../administration/audit_events.md#impersonation-data). @@ -197,7 +205,10 @@ The [Cohorts](user_cohorts.md) tab displays the monthly cohorts of new users and You can administer all groups in the GitLab instance from the Admin Area's Groups page. -To access the Groups page, go to **Admin Area > Overview > Groups**. +To access the Groups page: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Groups**. For each group, the page displays their name, description, size, number of projects in the group, number of members, and whether the group is private, internal, or public. To edit a group, click @@ -216,11 +227,12 @@ To [Create a new group](../group/index.md#create-a-group) click **New group**. You can administer all jobs in the GitLab instance from the Admin Area's Jobs page. -To access the Jobs page, go to **Admin Area > Overview > Jobs**. +To access the Jobs page: -All jobs are listed, in descending order of job ID. - -Click the **All** tab to list all jobs. Click the **Pending**, **Running**, or **Finished** tab to list only jobs of that status. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Jobs**. All jobs are listed, in descending order of job ID. +1. Click the **All** tab to list all jobs. Click the **Pending**, **Running**, or **Finished** + tab to list only jobs of that status. For each job, the following details are listed: @@ -241,7 +253,10 @@ For each job, the following details are listed: You can administer all runners in the GitLab instance from the Admin Area's **Runners** page. See [GitLab Runner](https://docs.gitlab.com/runner/) for more information. -To access the **Runners** page, go to **Admin Area > Overview > Runners**. +To access the **Runners** page: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Runners**. The **Runners** page features: @@ -287,7 +302,10 @@ You can also edit, pause, or remove each runner. You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers** page. For more details, see [Gitaly](../../administration/gitaly/index.md). -To access the **Gitaly Servers** page, go to **Admin Area > Overview > Gitaly Servers**. +To access the **Gitaly Servers** page: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Gitaly Servers**. For each Gitaly server, the following details are listed: @@ -344,7 +362,7 @@ For multi-node systems we recommend ingesting the logs into services like Elasti |:------------------------|:---------| | `application.log` | GitLab user activity | | `git_json.log` | Failed GitLab interaction with Git repositories | -| `production.log` | Requests received from Unicorn, and the actions taken to serve those requests | +| `production.log` | Requests received from Puma, and the actions taken to serve those requests | | `sidekiq.log` | Background jobs | | `repocheck.log` | Repository activity | | `integrations_json.log` | Activity between GitLab and integrated systems | diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md index 73472fcf67a..58876b87576 100644 --- a/doc/user/admin_area/license.md +++ b/doc/user/admin_area/license.md @@ -34,13 +34,13 @@ is locked. The first time you visit your GitLab EE installation signed in as an administrator, you should see a note urging you to upload a license with a link that takes you -to **Admin Area > License**. +to the **License** area. -Otherwise, you can: +Otherwise, to manually go to the **License** area: -1. Navigate manually to the **Admin Area** by selecting the wrench (**{admin}**) icon in the top menu. +1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. Navigate to the **License** tab, and select **Upload New License**. +1. On the left sidebar, select **License**, and select **Upload New License**. - *If you've received a `.gitlab-license` file:* 1. Download the license file to your local machine. @@ -113,9 +113,9 @@ before this occurs. To remove a license from a self-managed instance: -1. In the top navigation bar, click the **{admin}** wrench icon to navigate to the [Admin Area](index.md). -1. Click **License** in the left sidebar. -1. Click **Remove License**. +1. On the top bar, select **Menu >** **{admin}** **Admin** to go to the [Admin Area](index.md). +1. On the left sidebar, select **License**. +1. Select **Remove license**. ## License history diff --git a/doc/user/admin_area/merge_requests_approvals.md b/doc/user/admin_area/merge_requests_approvals.md index fadccadaf2c..b221b1d51a7 100644 --- a/doc/user/admin_area/merge_requests_approvals.md +++ b/doc/user/admin_area/merge_requests_approvals.md @@ -15,8 +15,8 @@ project level. To enable merge request approval rules for an instance: -1. Navigate to **Admin Area >** **{push-rules}** **Push Rules** and expand **Merge -requests approvals**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **{push-rules}** **Push Rules**, and expand **Merge request (MR) approvals**. 1. Set the required rule. 1. Click **Save changes**. diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md index c04003dd75f..71e72cc630c 100644 --- a/doc/user/admin_area/moderate_users.md +++ b/doc/user/admin_area/moderate_users.md @@ -21,9 +21,10 @@ administrators can choose to block the user. Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users), or directly from the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. 1. Select a user. -1. Under the **Account** tab, click **Block user**. +1. Under the **Account** tab, select **Block user**. A blocked user: @@ -43,10 +44,11 @@ A blocked user does not consume a [seat](../../subscriptions/self_managed/index. A blocked user can be unblocked from the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. -1. Click on the **Blocked** tab. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. +1. Select on the **Blocked** tab. 1. Select a user. -1. Under the **Account** tab, click **Unblock user**. +1. Under the **Account** tab, select **Unblock user**. Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user). @@ -74,16 +76,17 @@ with the following differences: A deactivated user: - Cannot access Git repositories or the API. -- Will not receive any notifications from GitLab. -- Will not be able to use [slash commands](../../integration/slash_commands.md). +- Does not receive any notifications from GitLab. +- Does not be able to use [slash commands](../../integration/slash_commands.md). Personal projects, and group and user history of the deactivated user are left intact. A user can be deactivated from the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. 1. Select a user. -1. Under the **Account** tab, click **Deactivate user**. +1. Under the **Account** tab, select **Deactivate user**. Please note that for the deactivation option to be visible to an admin, the user: @@ -95,6 +98,23 @@ Users can also be deactivated using the [GitLab API](../../api/users.md#deactiva NOTE: A deactivated user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). +### Automatically deactivate dormant users + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320875) in GitLab 14.0. + +Administrators can enable automatic deactivation of users who have not signed in, or have no activity +in the last 90 days. To do this: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > General**. +1. Expand the **Account and limit** section. +1. Under **Dormant users**, check **Deactivate dormant users after 90 days of inactivity**. +1. Select **Save changes**. + +When this feature is enabled, GitLab runs a job once a day to deactivate the dormant users. + +A maximum of 100,000 users can be deactivated per day. + ### Activating a user > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. @@ -103,10 +123,11 @@ A deactivated user can be activated from the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. -1. Click on the **Deactivated** tab. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. +1. Select the **Deactivated** tab. 1. Select a user. -1. Under the **Account** tab, click **Activate user**. +1. Under the **Account** tab, select **Activate user**. Users can also be activated using the [GitLab API](../../api/users.md#activate-user). @@ -134,23 +155,25 @@ To completely block a user, administrators can choose to ban the user. Users can be banned using the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. 1. Select a user. -1. Under the **Account** tab, click **Ban user**. +1. Under the **Account** tab, 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 will be implemented in follow up issues. +This functionality is planned to be implemented in follow up issues. ### Unban a user A banned user can be unbanned using the Admin Area. To do this: -1. Navigate to **Admin Area > Overview > Users**. -1. Click on the **Banned** tab. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Overview > Users**. +1. Select the **Banned** tab. 1. Select a user. -1. Under the **Account** tab, click **Unban user**. +1. Under the **Account** tab, select **Unban user**. NOTE: Unbanning a user changes the user's state to active and consumes a diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md index 2d4683911fb..a3e46ea6225 100644 --- a/doc/user/admin_area/monitoring/health_check.md +++ b/doc/user/admin_area/monitoring/health_check.md @@ -143,9 +143,11 @@ This check is being exempt from Rack Attack. NOTE: Access token has been deprecated in GitLab 9.4 in favor of [IP whitelist](#ip-whitelist). -An access token needs to be provided while accessing the probe endpoints. The current -accepted token can be found under the **Admin Area > Monitoring > Health check** -(`admin/health_check`) page of your GitLab instance. +An access token needs to be provided while accessing the probe endpoints. You can +find the current accepted token in the user interface: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Monitoring > Health Check**. (`admin/health_check`)  diff --git a/doc/user/admin_area/review_abuse_reports.md b/doc/user/admin_area/review_abuse_reports.md index 12a3111c6f3..a179eb70453 100644 --- a/doc/user/admin_area/review_abuse_reports.md +++ b/doc/user/admin_area/review_abuse_reports.md @@ -16,7 +16,8 @@ reports in the Admin Area. To receive notifications of new abuse reports by e-mail, follow these steps: -1. Select **Admin Area > Settings > Reporting**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > Reporting**. 1. Expand the **Abuse reports** section. 1. Provide an email address. @@ -30,7 +31,10 @@ documentation](../report_abuse.md). ## Resolving abuse reports -To access abuse reports, go to **Admin Area > Abuse Reports**. +To access abuse reports: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Abuse Reports**. There are 3 ways to resolve an abuse report, with a button for each method: 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 8bc5a035e2a..f2a849e1894 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -9,18 +9,22 @@ type: reference ## Default projects limit -You can change the default maximum number of projects that users can create in their personal namespace. -Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. -You can increase or decrease that `Default projects limit` value. +You can change the default maximum number of projects that users can create in their personal namespace: -- If you set `Default projects limit` to 0, users are not allowed to create projects - in their users personal namespace. However, projects can still be created in a group. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, then expand **Account and limit**. +1. Increase or decrease that **Default projects limit** value. + +If you set **Default projects limit** to 0, users are not allowed to create projects +in their users personal namespace. However, projects can still be created in a group. ## Max attachment size -You can change the maximum file size for attachments in comments and replies in GitLab. -Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. -From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`. +You can change the maximum file size for attachments in comments and replies in GitLab: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, then expand **Account and limit**. +1. Increase or decrease by changing the value in **Maximum attachment size (MB)**. NOTE: If you choose a size larger than the configured value for the web server, @@ -29,15 +33,26 @@ details. ## Max push size -You can change the maximum push size for your repository. -Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. -From here, you can increase or decrease by changing the value in `Maximum push size (MB)`. +You can change the maximum push size for your repository: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, then expand **Account and limit**. +1. Increase or decrease by changing the value in **Maximum push size (MB)**. + +NOTE: +When you [add files to a repository](../../project/repository/web_editor.md#create-a-file) +through the web UI, the maximum **attachment** size is the limiting factor, +because the [web server](../../../development/architecture.md#components) +must receive the file before GitLab can generate the commit. +Use [Git LFS](../../../topics/git/lfs/index.md) to add large files to a repository. ## Max import size -You can change the maximum file size for imports in GitLab. -Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. -From here, you can increase or decrease by changing the value in `Maximum import size (MB)`. +You can change the maximum file size for imports in GitLab: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, then expand **Account and limit**. +1. Increase or decrease by changing the value in **Maximum import size (MB)**. NOTE: If you choose a size larger than the configured value for the web server, @@ -55,7 +70,8 @@ A prefix can help you identify PATs visually, as well as with automation tools. Only a GitLab administrator can set the prefix, which is a global setting applied to any PAT generated in the system by any user: -1. Navigate to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. 1. Fill in the **Personal Access Token prefix** field. 1. Click **Save changes**. @@ -97,7 +113,8 @@ These settings can be found in: 1. Fill in the **Repository size limit (MB)** field in the **Naming, visibility** section. 1. Click **Save changes**. - GitLab global settings: - 1. From the Dashboard, navigate to **Admin Area > Settings > General**. + 1. On the top bar, select **Menu >** **{admin}** **Admin**. + 1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. 1. Fill in the **Size limit per repository (MB)** field. 1. Click **Save changes**. @@ -143,7 +160,8 @@ GitLab administrators can choose to customize the session duration (in minutes) To set a limit on how long these sessions are valid: -1. Navigate to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. 1. Fill in the **Session duration for Git operations when 2FA is enabled (minutes)** field. 1. Click **Save changes**. @@ -167,7 +185,8 @@ there are no restrictions. To set a lifetime on how long personal access tokens are valid: -1. Navigate to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. 1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field. 1. Click **Save changes**. @@ -182,22 +201,19 @@ Once a lifetime for personal access tokens is set, GitLab: ## Enforce SSH key expiration **(ULTIMATE SELF)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250480) in GitLab 13.9. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250480) in GitLab 13.9. +> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/320970) in GitLab 14.0. -By default, expired SSH keys **can still be used**. +By default, expired SSH keys **are not usable**. -WARNING: -Allowing use of expired SSH keys by default is deprecated and scheduled to change in GitLab 14.0. +To allow the use of expired SSH keys: -To prevent the use of expired SSH keys: - -1. Navigate to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. -1. Select the **Enforce SSH key expiration** checkbox. - -Enforcing SSH key expiration immediately disables all expired SSH keys. +1. Uncheck the **Enforce SSH key expiration** checkbox. -For more information, see the following issue on [SSH key expiration](https://gitlab.com/gitlab-org/gitlab/-/issues/320970). +Disabling SSH key expiration immediately enables all expired SSH keys. ## Do not enforce Personal Access Token expiration **(ULTIMATE SELF)** @@ -209,7 +225,8 @@ You can allow the use of expired PATs with the following steps: To do this: -1. Navigate to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Account and limit** section. 1. Uncheck the **Enforce personal access token expiration** checkbox. @@ -221,8 +238,9 @@ To maintain integrity of user details in [Audit Events](../../../administration/ To do this: -1. Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. -1. Check the **Prevent users from changing their profile name** checkbox. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, then expand **Account and limit**. +1. Select the **Prevent users from changing their profile name** checkbox. NOTE: When this ability is disabled, GitLab administrators can still use the diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md index decd204dbe5..ffe969a6799 100644 --- a/doc/user/admin_area/settings/continuous_integration.md +++ b/doc/user/admin_area/settings/continuous_integration.md @@ -1,22 +1,22 @@ --- stage: Verify -group: Continuous Integration +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments type: reference --- -# Continuous Integration and Deployment Admin settings **(FREE SELF)** +# Continuous Integration and Deployment Admin Area settings **(FREE SELF)** -In this area, you will find settings for Auto DevOps, runners, and job artifacts. -You can find it in the [Admin Area](index.md) by navigating to -**Admin Area > Settings > CI/CD**. +The [Admin Area](index.md) has the instance settings for Auto DevOps, runners, and +job artifacts. -## Auto DevOps **(FREE SELF)** +## Auto DevOps To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md) for all projects: -1. Go to **Admin Area > Settings > CI/CD**. +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) which is used for Auto Deploy and Auto Review Apps. @@ -28,6 +28,25 @@ From now on, every existing project and newly created ones that don't have a If you want to disable it for a specific project, you can do so in [its settings](../../../topics/autodevops/index.md#enable-or-disable-auto-devops). +## Shared runner details + +To display details about the instance's shared runners in all projects' +runner settings: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Continuous Integration and Deployment**. +1. Enter your shared runner details in the **Shared runner details** field. + +You can use [Markdown](../../markdown.md) for improved formatting. To see the rendered +details: + +1. On the top bar, select **Menu > Project** and select any group or project. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Runners**. + + + ## Maximum artifacts size **(FREE SELF)** The maximum size of the [job artifacts](../../../administration/job_artifacts.md) @@ -45,9 +64,10 @@ To change it at the: - Instance level: - 1. Go to **Admin Area > Settings > CI/CD**. - 1. Change the value of maximum artifacts size (in MB). - 1. Click **Save changes** for the changes to take effect. + 1. On the top bar, select **Menu >** **{admin}** **Admin**. + 1. On the left sidebar, select **Settings > CI/CD**. + 1. Change the value of maximum artifacts size (in MB). + 1. Click **Save changes** for the changes to take effect. - Group level (this overrides the instance setting): @@ -64,14 +84,15 @@ To change it at the: NOTE: The setting at all levels is only available to GitLab administrators. -## Default artifacts expiration **(FREE SELF)** +## Default artifacts expiration The default expiration time of the [job artifacts](../../../administration/job_artifacts.md) can be set in the Admin Area of your GitLab instance. The syntax of duration is described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) and the default value is `30 days`. -1. Go to **Admin Area > Settings > CI/CD**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. 1. Change the value of default expiration time. 1. Click **Save changes** for the changes to take effect. @@ -85,12 +106,13 @@ be updated for artifacts created before this setting was changed. The administrator may need to manually search for and expire previously-created artifacts, as described in the [troubleshooting documentation](../../../administration/troubleshooting/gitlab_rails_cheat_sheet.md#remove-artifacts-more-than-a-week-old). -## Keep the latest artifacts for all jobs in the latest successful pipelines **(CORE ONLY)** +## Keep the latest artifacts for all jobs in the latest successful pipelines -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50889) in GitLab Core 13.9. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50889) in GitLab 13.9. -When enabled (default), the artifacts for the most recent pipeline for a ref are -locked against deletion and kept regardless of the expiry time. +When enabled (default), the artifacts of the most recent pipeline for each Git ref +([branches and tags](https://git-scm.com/book/en/v2/Git-Internals-Git-References)) +are locked against deletion and kept regardless of the expiry time. When disabled, the latest artifacts for any **new** successful or fixed pipelines are allowed to expire. @@ -100,7 +122,8 @@ If disabled at the instance level, you cannot enable this per-project. To disable the setting: -1. Go to **Admin Area > Settings > CI/CD**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. 1. Expand **Continuous Integration and Deployment**. 1. Clear the **Keep the latest artifacts for all jobs in the latest successful pipelines** checkbox. 1. Click **Save changes** @@ -121,18 +144,17 @@ shared runners per month. Setting this to `0` (default value) grants unlimited pipeline minutes. While build limits are stored as minutes, the counting is done in seconds. Usage resets on the first day of each month. On GitLab.com, the quota is calculated based on your -[subscription plan](https://about.gitlab.com/pricing/#gitlab-com). +[subscription plan](../../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes). To change the pipelines minutes quota: -1. Go to **Admin Area > Settings > CI/CD**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. 1. Expand **Continuous Integration and Deployment**. 1. In the **Pipeline minutes quota** box, enter the maximum number of minutes. 1. Click **Save changes** for the changes to take effect. ---- - -While the setting in the Admin Area has a global effect, as an admin you can +While the setting in the Admin Area has a global effect, as an administrator you can also change each group's pipeline minutes quota to override the global value. 1. Navigate to the **Admin Area > Overview > Groups** and hit the **Edit** @@ -140,8 +162,8 @@ also change each group's pipeline minutes quota to override the global value. 1. In the **Pipeline Minutes Quota** box, enter the maximum number of minutes. 1. Click **Save changes** for the changes to take effect. -Once saved, you can see the build quota in the group admin view. -The quota can also be viewed in the project admin view if shared runners +Once saved, you can see the build quota in the group settings. +The quota can also be viewed in the project settings if shared runners are enabled.  @@ -151,7 +173,7 @@ a group in the **Usage Quotas** page available to the group page settings list.  -## Archive jobs **(FREE SELF)** +## Archive jobs Archiving jobs is useful for reducing the CI/CD footprint on the system by removing some of the capabilities of the jobs (metadata needed to run the job), @@ -159,29 +181,40 @@ but persisting the traces and artifacts for auditing purposes. To set the duration for which the jobs are considered as old and expired: -1. Go to **Admin Area > Settings > CI/CD**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. 1. Expand the **Continuous Integration and Deployment** section. 1. Set the value of **Archive jobs**. 1. Hit **Save changes** for the changes to take effect. -Once that time passes, the jobs are archived and no longer able to be +After that time passes, the jobs are archived and no longer able to be retried. Make it empty to never expire jobs. It has to be no less than 1 day, for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>. As of June 22, 2020 the [value is set](../../gitlab_com/index.md#gitlab-cicd) to 3 months on GitLab.com. Jobs created before that date were archived after September 22, 2020. -## Default CI configuration path +## Protect CI/CD variables by default + +To set all new [CI/CD variables](../../../ci/variables/README.md) as +[protected](../../../ci/variables/README.md#protect-a-cicd-variable) by default: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. +1. Select **Protect CI/CD variables by default**. + +## Default CI/CD configuration file > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18073) in GitLab 12.5. -The default CI configuration file path for new projects can be set in the Admin -Area of your GitLab instance (`.gitlab-ci.yml` if not set): +The default CI/CD configuration file and path for new projects can be set in the Admin Area +of your GitLab instance (`.gitlab-ci.yml` if not set): -1. Go to **Admin Area > Settings > CI/CD**. -1. Input the new path in the **Default CI configuration path** field. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. +1. Input the new file and path in the **Default CI/CD configuration file** field. 1. Hit **Save changes** for the changes to take effect. -It is also possible to specify a [custom CI/CD configuration path for a specific project](../../../ci/pipelines/settings.md#custom-cicd-configuration-path). +It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#custom-cicd-configuration-file). ## Required pipeline configuration **(PREMIUM SELF)** @@ -191,30 +224,33 @@ This feature is being re-evaluated in favor of a different We recommend that users who haven't yet implemented this feature wait for the new solution. -GitLab administrators can force a pipeline configuration to run on every -pipeline. +You can set a [CI/CD template](../../../ci/examples/README.md#cicd-templates) +as a required pipeline configuration for all projects on a GitLab instance. You can +use a template from: -The configuration applies to all pipelines for a GitLab instance and is -sourced from: +- The default CI/CD templates. +- A custom template stored in an [instance template repository](instance_template_repository.md). -- The [instance template repository](instance_template_repository.md). -- GitLab-supplied configuration. + NOTE: + When you use a configuration defined in an instance template repository, + nested [`include:`](../../../ci/yaml/README.md#include) keywords + (including `include:file`, `include:local`, `include:remote`, and `include:template`) + [do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345). -NOTE: -When you use a configuration defined in an instance template repository, -nested [`include:`](../../../ci/yaml/README.md#include) keywords -(including `include:file`, `include:local`, `include:remote`, and `include:template`) -[do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345). +The project CI/CD configuration merges into the required pipeline configuration when +a pipeline runs. The merged configuration is the same as if the required pipeline configuration +added the project configuration with the [`include` keyword](../../../ci/yaml/README.md#include). +To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration) +in the pipeline editor. -To set required pipeline configuration: +To select a CI/CD template for the required pipeline configuration: -1. Go to **Admin Area > Settings > CI/CD**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > CI/CD**. 1. Expand the **Required pipeline configuration** section. -1. Select the required configuration from the provided dropdown. +1. Select a CI/CD template from the dropdown. 1. Click **Save changes**. - - ## Package Registry configuration ### npm Forwarding **(PREMIUM SELF)** @@ -223,7 +259,8 @@ GitLab administrators can disable the forwarding of npm requests to [npmjs.com]( To disable it: -1. Go to **Admin Area > Settings > CI/CD**. +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**. @@ -236,7 +273,8 @@ GitLab administrators can adjust the maximum allowed file size for each package To set the maximum file size: -1. Go to **Admin Area > Settings > CI/CD**. +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. Find the package type you would like to adjust. 1. Enter the maximum file size, in bytes. diff --git a/doc/user/admin_area/settings/external_authorization.md b/doc/user/admin_area/settings/external_authorization.md index 0975b93f98f..205dd77c1bf 100644 --- a/doc/user/admin_area/settings/external_authorization.md +++ b/doc/user/admin_area/settings/external_authorization.md @@ -39,10 +39,11 @@ the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/logs ## Configuration -The external authorization service can be enabled by an administrator on the GitLab -**Admin Area > Settings > General** page: +The external authorization service can be enabled by an administrator: - +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**: +  The available required properties are: diff --git a/doc/user/admin_area/settings/floc.md b/doc/user/admin_area/settings/floc.md index e1d10727341..31a626478ed 100644 --- a/doc/user/admin_area/settings/floc.md +++ b/doc/user/admin_area/settings/floc.md @@ -22,7 +22,8 @@ Permissions-Policy: interest-cohort=() To enable it: -1. Go to the Admin Area (**{admin}**) and select **Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand **Federated Learning of Cohorts**. 1. Check the box. 1. Click **Save changes**. diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md index 3570634b9ba..6f488efee11 100644 --- a/doc/user/admin_area/settings/gitaly_timeouts.md +++ b/doc/user/admin_area/settings/gitaly_timeouts.md @@ -12,7 +12,8 @@ configured to make sure that long running Gitaly calls don't needlessly take up To access Gitaly timeout settings: -1. Go to **Admin Area > Settings > Preferences**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > Preferences**. 1. Expand the **Gitaly** section. ## Available timeouts @@ -20,9 +21,8 @@ To access Gitaly timeout settings: The following timeouts can be modified: - **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the - worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings) - or [Unicorn](https://docs.gitlab.com/omnibus/settings/unicorn.html). Used to make sure that Gitaly - calls made within a web request cannot exceed the entire request timeout. + worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). + Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout. Defaults to 55 seconds. - **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds. diff --git a/doc/user/admin_area/settings/help_page.md b/doc/user/admin_area/settings/help_page.md index 5739c3e4f10..d7c96c295f6 100644 --- a/doc/user/admin_area/settings/help_page.md +++ b/doc/user/admin_area/settings/help_page.md @@ -16,7 +16,8 @@ to go for help. You can customize and display this information on the GitLab ser You can add a help message, which is shown on the GitLab `/help` page (e.g., <https://gitlab.com/help>) in a new section at the top of the `/help` page: -1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. 1. Under **Help page text**, fill in the information you wish to display on `/help`. 1. Save your changes. You can now see the message on `/help`. @@ -25,7 +26,8 @@ You can add a help message, which is shown on the GitLab `/help` page (e.g., You can add a help message, which is shown on the GitLab login page in a new section titled `Need Help?`, located below the login page message: -1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. 1. Under **Help text**, fill in the information you wish to display on the login page.  diff --git a/doc/user/admin_area/settings/img/admin_required_pipeline.png b/doc/user/admin_area/settings/img/admin_required_pipeline.png Binary files differdeleted file mode 100644 index 501b1e3ba0a..00000000000 --- a/doc/user/admin_area/settings/img/admin_required_pipeline.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/continuous_integration_shared_runner_details_v14_0.png b/doc/user/admin_area/settings/img/continuous_integration_shared_runner_details_v14_0.png Binary files differnew file mode 100644 index 00000000000..d8bc3deccd4 --- /dev/null +++ b/doc/user/admin_area/settings/img/continuous_integration_shared_runner_details_v14_0.png diff --git a/doc/user/admin_area/settings/img/custom_sign_in_page_v13_6.png b/doc/user/admin_area/settings/img/custom_sign_in_page_v13_6.png Binary files differdeleted file mode 100644 index 5eb2134187a..00000000000 --- a/doc/user/admin_area/settings/img/custom_sign_in_page_v13_6.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/enforce_terms.png b/doc/user/admin_area/settings/img/enforce_terms.png Binary files differindex 3d93e1cc891..699e0e63ceb 100644 --- a/doc/user/admin_area/settings/img/enforce_terms.png +++ b/doc/user/admin_area/settings/img/enforce_terms.png diff --git a/doc/user/admin_area/settings/import_export_rate_limits.md b/doc/user/admin_area/settings/import_export_rate_limits.md index c6b965c18d3..12235bdb5ef 100644 --- a/doc/user/admin_area/settings/import_export_rate_limits.md +++ b/doc/user/admin_area/settings/import_export_rate_limits.md @@ -5,7 +5,7 @@ group: Import 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 --- -# Project/Group Import/Export rate limits +# Project/group import/export rate limits **(FREE SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35728) in GitLab 13.2. @@ -23,7 +23,7 @@ per minute per user basis: All rate limits are: -- Configurable at **(admin)** **Admin Area > Settings > Network > Import/Export Rate Limits** +- Configurable through the top bar at **Menu > Admin > Settings > Network > Import/Export Rate Limits** - Applied per minute per user - Not applied per IP address - Active by default. To disable, set the option to `0` diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index a66502d9466..6a5af09358d 100644 --- a/doc/user/admin_area/settings/index.md +++ b/doc/user/admin_area/settings/index.md @@ -9,25 +9,28 @@ type: index As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **Admin Area > Settings**. -The admin area is not accessible on GitLab.com, and settings can only be changed by the +The Admin Area is not accessible on GitLab.com, and settings can only be changed by the GitLab.com administrators. See the [GitLab.com settings](../../gitlab_com/index.md) documentation for all current settings and limits on the GitLab.com instance. ## General -Access the default page for admin area settings by navigating to **Admin Area > Settings > General**: +To access the default page for Admin Area settings: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. | Option | Description | | ------ | ----------- | | [Visibility and access controls](visibility_and_access_controls.md) | Set default and restrict visibility levels. Configure import sources and Git access protocol. | -| [Account and limit](account_and_limit_settings.md) **(STARTER)** | Set projects and maximum size limits, session duration, user options, and check feature availability for namespace plan. | +| [Account and limit](account_and_limit_settings.md) | Set projects and maximum size limits, session duration, user options, and check feature availability for namespace plan. | | [Diff limits](../diff_limits.md) | Diff content limits. | | [Sign-up restrictions](sign_up_restrictions.md) | Configure the way a user creates a new account. | | [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign in. Enable mandatory two-factor authentication. | | [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. | | [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization | | [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. | -| [Web IDE](../../project/web_ide/index.md#enabling-live-preview) | Manage Web IDE Features. | +| [Web IDE](../../project/web_ide/index.md#enable-live-preview) | Manage Web IDE features. | | [FLoC](floc.md) | Enable or disable [Federated Learning of Cohorts (FLoC)](https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts) tracking. | ## Integrations @@ -116,6 +119,11 @@ Access the default page for admin area settings by navigating to **Admin Area > | [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). | -NOTE: -You can change the [Default first day of the week](../../profile/preferences.md) for the entire GitLab instance -in the **Localization** section of **Admin Area > Settings > Preferences**. +### Default first day of the week + +You can change the [Default first day of the week](../../profile/preferences.md) +for the entire GitLab instance: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**. +1. Scroll to the **Localization** section, and select your desired first day of the week. diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md index 600d99934aa..c8a4c2866ca 100644 --- a/doc/user/admin_area/settings/instance_template_repository.md +++ b/doc/user/admin_area/settings/instance_template_repository.md @@ -17,12 +17,17 @@ while the project remains secure. ## Configuration -As an administrator, navigate to **Admin Area > Settings > Templates** and -select the project to serve as the custom template repository. +To select a project to serve as the custom template repository: - +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Templates**. +1. Select the project: -After that, you can add custom templates to the selected repository and use them for the entire instance. +  + +1. Add custom templates to the selected repository. + +After you add templates, you can use them for the entire instance. They are available in the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns) and through the [API settings](../../../api/settings.md). diff --git a/doc/user/admin_area/settings/package_registry_rate_limits.md b/doc/user/admin_area/settings/package_registry_rate_limits.md index 578b7cd1236..6e7b9b0da30 100644 --- a/doc/user/admin_area/settings/package_registry_rate_limits.md +++ b/doc/user/admin_area/settings/package_registry_rate_limits.md @@ -9,7 +9,8 @@ type: reference Rate limiting is a common technique used to improve the security and durability of a web application. For more details, see [Rate limits](../../../security/rate_limits.md). General user and -IP rate limits can be enforced in **Admin Area > Settings > Network > User and IP rate limits**. +IP rate limits can be enforced from the top bar at +**Menu > Admin > Settings > Network > User and IP rate limits**. For more details, see [User and IP rate limits](user_and_ip_rate_limits.md). With the [GitLab Package Registry](../../packages/package_registry/index.md), @@ -20,7 +21,7 @@ the [Packages API](../../../api/packages.md). When downloading such dependencies in downstream projects, many requests are made through the Packages API. You may therefore reach enforced user and IP rate limits. To address this issue, you can define specific rate limits for the Packages API in -**Admin Area > Settings > Network > Package Registry Rate Limits**: +**Menu > Admin > Settings > Network > Package Registry Rate Limits**: - Unauthenticated Packages API requests - Authenticated Packages API requests diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md index b152787b23f..3140eecfa53 100644 --- a/doc/user/admin_area/settings/project_integration_management.md +++ b/doc/user/admin_area/settings/project_integration_management.md @@ -22,7 +22,8 @@ Only the complete settings for an integration can be inherited. Per-field inheri > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2137) in GitLab 13.3 for project-level integrations. > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level integrations. -1. Navigate to **Admin Area > Settings > Integrations**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Integrations**. 1. Select an integration. 1. Enter configuration details and click **Save changes**. @@ -53,7 +54,8 @@ integration on all non-configured groups and projects by default. ### Remove an instance-level default setting -1. Navigate to **Admin Area > Settings > Integrations**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Integrations**. 1. Select an integration. 1. Click **Reset** and confirm. diff --git a/doc/user/admin_area/settings/push_event_activities_limit.md b/doc/user/admin_area/settings/push_event_activities_limit.md index 7032c1031a9..21e4f32ff8d 100644 --- a/doc/user/admin_area/settings/push_event_activities_limit.md +++ b/doc/user/admin_area/settings/push_event_activities_limit.md @@ -23,9 +23,14 @@ branches), only 1 bulk push event is created instead of 1,000 push events. This helps in maintaining good system performance and preventing spam on the activity feed. -This setting can be modified in **Admin Area > Settings > Network > Performance Optimization**. -This can also be configured via the [Application settings API](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls) -as `push_event_activities_limit`. The default value is 3, but it can be greater -than or equal 0. +To modify this setting: + +- In the Admin Area: + 1. On the top bar, select **Menu >** **{admin}** **Admin**. + 1. In the left sidebar, select **Settings > Network**, then expand **Performance optimization**. +- Through the [Application settings API](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls) + as `push_event_activities_limit`. + +The default value is 3, but it can be greater than or equal 0.  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 1997e6b5149..67a97d26b34 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 @@ -28,5 +28,5 @@ The default value is `300`. Requests over the rate limit are logged into the `auth.log` file. For example, if you set a limit of 300, requests using the -[Projects::NotesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/notes_controller.rb) +[Projects::NotesController#create](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/projects/notes_controller.rb) action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute. diff --git a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md index a9b23b3dc50..24b69ba74c7 100644 --- a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md +++ b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md @@ -9,8 +9,11 @@ type: reference > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30829) in GitLab 12.2. -This setting allows you to rate limit the requests to raw endpoints, defaults to `300` requests per minute. -It can be modified in **Admin Area > Settings > Network > Performance Optimization**. +This setting defaults to `300` requests per minute, and allows you to rate limit the requests to raw endpoints: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Network**. +1. Expand **Performance optimization**. 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. diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md index 647f9332119..ecd259a345c 100644 --- a/doc/user/admin_area/settings/sign_in_restrictions.md +++ b/doc/user/admin_area/settings/sign_in_restrictions.md @@ -13,7 +13,8 @@ You can use **Sign-in restrictions** to customize authentication restrictions fo To access sign-in restriction settings: -1. Navigate to the **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand the **Sign-in restrictions** section. ## Password authentication enabled @@ -76,9 +77,9 @@ If necessary, you can disable **Admin Mode** as an administrator by using one of - [**Rails console**](../../../administration/operations/rails_console.md#starting-a-rails-console-session): ```ruby - ::Gitlab::CurrentSettings.update_attributes!(admin_mode: false) + ::Gitlab::CurrentSettings.update!(admin_mode: false) ``` - + ## Two-factor authentication When this feature is enabled, all users must use the [two-factor authentication](../../profile/account/two_factor_authentication.md). @@ -114,13 +115,14 @@ For example, if you include the following information in the noted text box: ```markdown # Custom sign-in text -To access this text box, navigate to Admin Area > Settings > General, and expand the "Sign-in restrictions" section. +To access this text box: + +1. On the top bar, select **Menu > Admin**. +1. In the left sidebar, select **Settings > General**, and expand the **Sign-in restrictions** section. ``` Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your -GitLab instance: - - +GitLab instance. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 0078db286a8..1098c7060f8 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -22,7 +22,8 @@ you do not expect public users to sign up for an account. To disable sign ups: -1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**. 1. Clear the **Sign-up enabled** checkbox, then select **Save changes**. ## Require administrator approval for new sign ups @@ -34,7 +35,8 @@ When this setting is enabled, any user visiting your GitLab domain and signing u To require administrator approval for new sign ups: -1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**. 1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**. In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are @@ -47,7 +49,8 @@ their email address before they are allowed to sign in. To enforce confirmation of the email address used for new sign ups: -1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**. 1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**. ## User cap **(FREE SELF)** @@ -64,7 +67,8 @@ user cap, the users in pending approval state are automatically approved in a ba ### Set the user cap number -1. Go to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand **Sign-up restrictions**. 1. Enter a number in **User cap**. 1. Select **Save changes**. @@ -73,7 +77,8 @@ New user sign ups are subject to the user cap restriction. ## Remove the user cap -1. Go to **Admin Area > Settings > General**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**. 1. Expand **Sign-up restrictions**. 1. Remove the number from **User cap**. 1. Select **Save changes**. @@ -130,7 +135,8 @@ reduce the risk of malicious users creating spam accounts with disposable email To create an email domain allowlist or denylist: -1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**. 1. For the allowlist, you must enter the list manually. For the denylist, you can enter the list manually or upload a `.txt` file that contains list entries. diff --git a/doc/user/admin_area/settings/terms.md b/doc/user/admin_area/settings/terms.md index 3e0636ef7ac..46e85ffc9c0 100644 --- a/doc/user/admin_area/settings/terms.md +++ b/doc/user/admin_area/settings/terms.md @@ -7,7 +7,7 @@ type: reference # Enforce accepting Terms of Service **(FREE SELF)** -An admin 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. @@ -16,7 +16,8 @@ If configured, the Terms of Service page can be viewed via `https://your-instanc To enforce acceptance of a Terms of Service and Privacy Policy: 1. Log in to the GitLab instance as an admin user. -1. Go to **Admin Area > Settings > General**. +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. diff --git a/doc/user/admin_area/settings/third_party_offers.md b/doc/user/admin_area/settings/third_party_offers.md index 59845a8d0d8..e7fa8b1dc40 100644 --- a/doc/user/admin_area/settings/third_party_offers.md +++ b/doc/user/admin_area/settings/third_party_offers.md @@ -13,7 +13,11 @@ Within GitLab, we inform users of available third-party offers they might find v to enhance the development of their projects. An example is the Google Cloud Platform free credit for using [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/). -The display of third-party offers can be toggled in the **Admin Area > Settings** page. +To toggle the display of third-party offers: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings**, and expand **Third party offers**. +1. Select **Do not display offers from third parties within GitLab**. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index ada44115cec..b5a7ce318ff 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -10,8 +10,12 @@ type: reference GitLab Inc. periodically collects information about your instance in order to perform various actions. -All statistics are opt-out. You can enable/disable them in the -**Admin Area > Settings > Metrics and profiling** section **Usage statistics**. +All statistics are opt-out. To enable or disable them: + +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 **Usage ping**. +1. Select **Save changes**. ## Network configuration @@ -40,8 +44,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. Enable or -disable the version check in **Admin Area > Settings > Metrics and profiling > Usage statistics**. +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**. ### Request flow example diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md index 9e64dd59a74..fdeda0cf451 100644 --- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md +++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md @@ -11,20 +11,21 @@ Rate limiting is a common technique used to improve the security and durability of a web application. For more details, see [Rate limits](../../../security/rate_limits.md). -The following limits can be enforced in **Admin Area > Settings > Network > User and -IP rate limits**: +The following limits are disabled by default: - Unauthenticated requests - Authenticated API requests - Authenticated web requests -These limits are disabled by default. +To enforce any or all of them: -NOTE: -By default, all Git operations are first tried unauthenticated. Because of this, HTTP Git operations -may trigger the rate limits configured for unauthenticated requests. +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**: +  - + NOTE: + By default, all Git operations are first tried unauthenticated. Because of this, HTTP Git operations + may trigger the rate limits configured for unauthenticated requests. ## Response text 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 e335a9031d5..752856371bf 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -11,14 +11,18 @@ GitLab allows administrators to enforce specific controls. To access the visibility and access control options: -1. Sign in to GitLab as a user with Administrator [permissions](../../permissions.md). -1. Go to **Admin Area > Settings > General**. +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. ## Default branch protection -This global option defines the branch protection that applies to every repository's default branch. [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, which in most cases is `master`. +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). 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). diff --git a/doc/user/admin_area/user_cohorts.md b/doc/user/admin_area/user_cohorts.md index b01a299178d..e96ce969b3a 100644 --- a/doc/user/admin_area/user_cohorts.md +++ b/doc/user/admin_area/user_cohorts.md @@ -8,7 +8,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w You can analyze your users' GitLab activities over time. -To see user cohorts, go to **Admin Area > Overview > Users**. +To view user cohorts: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Overview > Users**. +1. Select the **Cohorts** tab. ## Overview |
