diff options
Diffstat (limited to 'doc/user/admin_area')
22 files changed, 201 insertions, 114 deletions
diff --git a/doc/user/admin_area/analytics/index.md b/doc/user/admin_area/analytics/index.md index 5cf5e33f2d2..bea22745e7b 100644 --- a/doc/user/admin_area/analytics/index.md +++ b/doc/user/admin_area/analytics/index.md @@ -14,4 +14,3 @@ 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)** -- [User Cohorts](user_cohorts.md): Display the monthly cohorts of new users and their activities over time. **(FREE)** diff --git a/doc/user/admin_area/analytics/instance_statistics.md b/doc/user/admin_area/analytics/instance_statistics.md deleted file mode 100644 index e44dd891029..00000000000 --- a/doc/user/admin_area/analytics/instance_statistics.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -redirect_to: 'usage_trends.md' ---- - -This document was moved to [another location](usage_trends.md). - -<!-- This redirect file can be deleted after <2022-03-20>. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/analytics/usage_trends.md b/doc/user/admin_area/analytics/usage_trends.md index 0c0cae09c16..38cd2dee4e9 100644 --- a/doc/user/admin_area/analytics/usage_trends.md +++ b/doc/user/admin_area/analytics/usage_trends.md @@ -40,22 +40,3 @@ in the categories shown in [Total counts](#total-counts). These charts help you visualize how rapidly these records are being created on your instance.  - -### Enable or disable Usage Trends - -In GitLab version 13.5 only, Usage Trends was under development and not ready for production use. -It was deployed behind a feature flag that was **disabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can opt to enable it. - -To enable it: - -```ruby -Feature.enable(:instance_statistics) -``` - -To disable it: - -```ruby -Feature.disable(:instance_statistics) -``` diff --git a/doc/user/admin_area/analytics/user_cohorts.md b/doc/user/admin_area/analytics/user_cohorts.md index a7c93160b69..ca5dff85757 100644 --- a/doc/user/admin_area/analytics/user_cohorts.md +++ b/doc/user/admin_area/analytics/user_cohorts.md @@ -1,36 +1,8 @@ --- -stage: none -group: unassigned -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 +redirect_to: '../user_cohorts.md' --- -# Cohorts **(FREE)** +This document was moved to [another location](../user_cohorts.md). -As a benefit of having the [usage ping active](../settings/usage_statistics.md), -you can analyze your users' GitLab activities over time. - -To see user cohorts, go to **Admin Area > Overview > Users**. - -## Overview - -How do you interpret the user cohorts table? Let's review an example with the -following user cohorts: - - - -For the cohort of March 2020, three users were added to this server and have -been active since this month. One month later (April 2020), two users are still -active. Five months later (August 2020), one user from this cohort is still -active, or 33% of the original cohort of three that joined in March. - -The **Inactive users** column shows the number of users who were added during -the month, but who never had any activity in the instance. - -How do we measure the activity of users? GitLab considers a user active if: - -- The user signs in. -- The user has Git activity (whether push or pull). -- The user visits pages related to dashboards, projects, issues, or merge - requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8). -- The user uses the API. -- The user uses the GraphQL API. +<!-- This redirect file can be deleted after <2021-06-01>. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md index af4d4e86e69..9141d7f488d 100644 --- a/doc/user/admin_area/approving_users.md +++ b/doc/user/admin_area/approving_users.md @@ -7,30 +7,49 @@ type: howto # Users pending approval -> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5. +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: -When [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) is enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state. +- [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). -A user pending approval is functionally identical to a [blocked](blocking_unblocking_users.md) user. +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: -- Will not be able to sign in. -- Cannot access Git repositories or the API. -- Will not receive any notifications from GitLab. +- Is functionally identical to a [blocked](blocking_unblocking_users.md) 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). -## Approving a user +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. Go to **Admin Area > 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. -A user that is pending approval can be approved from the Admin Area. To do this: +To approve or reject a user sign up: -1. Navigate to **Admin Area > Overview > Users**. -1. Click on the **Pending approval** tab. -1. Select a user. -1. Under the **Account** tab, click **Approve user**. +1. Go to **Admin Area > Overview > Users**. +1. Select the **Pending approval** tab. +1. In the user's row select settings (**{settings}**). +1. Select **Approve** or **Reject**. Approving a user: -1. Activates their account. -1. Changes the user's state to active and it consumes a -[seat](../../subscriptions/self_managed/index.md#billable-users). +- Activates their account. +- Changes the user's state to active. +- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users). diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md index 02659276b53..053cee82634 100644 --- a/doc/user/admin_area/credentials_inventory.md +++ b/doc/user/admin_area/credentials_inventory.md @@ -11,7 +11,9 @@ type: howto 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) and SSH keys that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token) and [delete](#delete-a-users-ssh-key) and see: +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) +and [delete](#delete-a-users-ssh-key) and see: - Who they belong to. - Their access scope. @@ -23,7 +25,7 @@ To access the Credentials inventory, navigate to **Admin Area > Credentials**. The following is an example of the Credentials inventory page: - + ## Revoke a user's personal access token @@ -31,7 +33,7 @@ The following is an example of the Credentials inventory page: If you see a **Revoke** button, you can revoke that user's PAT. Whether you see a **Revoke** button depends on the token state, and if an expiration date has been set. For more information, see the following table: -| Token state | [Token expiry enforced?](settings/account_and_limit_settings.md#optional-enforcement-of-personal-access-token-expiry) | Show Revoke button? | Comments | +| Token state | [Token expiration enforced?](settings/account_and_limit_settings.md#optional-non-enforcement-of-personal-access-token-expiration) | Show Revoke button? | Comments | |-------------|------------------------|--------------------|----------------------------------------------------------------------------| | Active | Yes | Yes | Allows administrators to revoke the PAT, such as for a compromised account | | Active | No | Yes | Allows administrators to revoke the PAT, such as for a compromised account | @@ -50,3 +52,39 @@ You can **Delete** a user's SSH key by navigating to the credentials inventory's The instance then notifies the user.  + +## Review existing GPG keys + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/282429) in GitLab 13.10. +> - It's [deployed behind a feature flag](../feature_flags.md), 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](#enable-or-disable-the-gpg-keys-view). + +You can view all existing GPG in your GitLab instance by navigating to the +credentials inventory GPG Keys tab, as well as the following properties: + +- Who the GPG key belongs to. +- The ID of the GPG key. +- Whether the GPG key is [verified or unverified](../project/repository/gpg_signed_commits/index.md) + + + +### Enable or disable the GPG keys view + +Enabling or disabling the GPG keys view is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) +can enable it. + +To enable it: + +```ruby +Feature.enable(:credential_inventory_gpg_keys) +``` + +To disable it: + +```ruby +Feature.disable(:credential_inventory_gpg_keys) +``` diff --git a/doc/user/admin_area/analytics/img/cohorts_v13_9.png b/doc/user/admin_area/img/cohorts_v13_9.png Binary files differindex 6a616b201c9..6a616b201c9 100644 --- a/doc/user/admin_area/analytics/img/cohorts_v13_9.png +++ b/doc/user/admin_area/img/cohorts_v13_9.png diff --git a/doc/user/admin_area/img/credentials_inventory_gpg_keys_v13_10.png b/doc/user/admin_area/img/credentials_inventory_gpg_keys_v13_10.png Binary files differnew file mode 100644 index 00000000000..2486332c477 --- /dev/null +++ b/doc/user/admin_area/img/credentials_inventory_gpg_keys_v13_10.png diff --git a/doc/user/admin_area/img/credentials_inventory_v13_10.png b/doc/user/admin_area/img/credentials_inventory_v13_10.png Binary files differnew file mode 100644 index 00000000000..e41bbf35a8e --- /dev/null +++ b/doc/user/admin_area/img/credentials_inventory_v13_10.png diff --git a/doc/user/admin_area/img/credentials_inventory_v13_4.png b/doc/user/admin_area/img/credentials_inventory_v13_4.png Binary files differdeleted file mode 100644 index 06925ea2f6f..00000000000 --- a/doc/user/admin_area/img/credentials_inventory_v13_4.png +++ /dev/null diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index b5e51e8d4c0..40e0e2856bd 100644 --- a/doc/user/admin_area/index.md +++ b/doc/user/admin_area/index.md @@ -33,7 +33,7 @@ The Admin Area is made up of the following sections: | **{cloud-gear}** Kubernetes | Create and manage instance-level [Kubernetes clusters](../instance/clusters/index.md). | | **{push-rules}** Push rules **(STARTER ONLY)** | Configure pre-defined Git [push rules](../../push_rules/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). **(PREMIUM SELF)** | | **{location-dot}** Geo **(PREMIUM SELF)** | Configure and maintain [Geo nodes](geo_nodes.md). | -| **{key}** Deploy keys | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys). | +| **{key}** Deploy keys | Create instance-wide [SSH deploy keys](../project/deploy_keys/index.md). | | **{lock}** Credentials **(ULTIMATE SELF)** | 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. | | **{labels}** Labels | Create and maintain [labels](labels.md) for your GitLab instance. | @@ -157,6 +157,22 @@ All impersonation activities are [captured with audit events](../../administrati  +#### User Permission Export **(PREMIUM SELF)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1772) in GitLab 13.8. +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292436) in GitLab 13.9. + +An administrator can export user permissions for all users in the GitLab instance from the Admin Area's Users page. +The export lists direct membership the users have in groups and projects. + +The following data is included in the export: + +- Username +- Email +- Type +- Path +- Access level ([Project](../permissions.md#project-members-permissions) and [Group](../permissions.md#group-members-permissions)) + #### Users statistics The **Users statistics** page provides an overview of user accounts by role. These statistics are @@ -170,6 +186,10 @@ The following totals are also included: GitLab billing is based on the number of [**Billable users**](../../subscriptions/self_managed/index.md#billable-users). +### User cohorts + +The [Cohorts](user_cohorts.md) tab displays the monthly cohorts of new users and their activities over time. + ### Administering Groups You can administer all groups in the GitLab instance from the Admin Area's Groups page. @@ -187,7 +207,7 @@ sort order is by **Last created**. To search for groups by name, enter your criteria in the search field. The group search is case insensitive, and applies partial matching. -To [Create a new group](../group/index.md#create-a-new-group) click **New group**. +To [Create a new group](../group/index.md#create-a-group) click **New group**. ### Administering Jobs diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md index 505f54e9ae9..89417de4bab 100644 --- a/doc/user/admin_area/license.md +++ b/doc/user/admin_area/license.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: howto --- -# Activate GitLab EE with a license **(STARTER ONLY)** +# Activate GitLab EE with a license **(PREMIUM SELF)** To activate all GitLab Enterprise Edition (EE) functionality, you need to upload a license. It's only possible to activate GitLab Enterprise Edition, so first verify which edition 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 70416c224c7..0f391118215 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -152,20 +152,20 @@ To set a limit on how long these sessions are valid: > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab Ultimate 12.6. -Users can optionally specify an expiration date for +Users can optionally specify a lifetime for [personal access tokens](../../profile/personal_access_tokens.md). -This expiration date is not a requirement, and can be set to any arbitrary date. +This lifetime is not a requirement, and can be set to any arbitrary number of days. Personal access tokens are the only tokens needed for programmatic access to GitLab. However, organizations with security requirements may want to enforce more protection by requiring the regular rotation of these tokens. -### Setting a limit +### Setting a lifetime -Only a GitLab administrator can set a limit. Leaving it empty means +Only a GitLab administrator can set a lifetime. Leaving it empty means there are no restrictions. -To set a limit on how long personal access tokens are valid: +To set a lifetime on how long personal access tokens are valid: 1. Navigate to **Admin Area > Settings > General**. 1. Expand the **Account and limit** section. @@ -180,24 +180,28 @@ Once a lifetime for personal access tokens is set, GitLab: allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime, or remove it, before revocation takes place. -## Enforcement of SSH key expiration **(ULTIMATE SELF)** +## Optional enforcement of SSH key expiration **(ULTIMATE SELF)** -GitLab administrators can choose to enforce the expiration of SSH keys after their expiration dates. -If you enable this feature, this disables all _expired_ SSH keys. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250480) in GitLab 13.9. -To do this: +By default, expired SSH keys **can still be used**. +You can prevent the use of expired SSH keys with the following steps: 1. Navigate to **Admin Area > Settings > General**. 1. Expand the **Account and limit** section. 1. Select the **Enforce SSH key expiration** checkbox. -## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)** +Enforcing SSH key expiration immediately disables all expired SSH keys. + +For more information, see the following issue on [SSH key expiration](https://gitlab.com/gitlab-org/gitlab/-/issues/320970). + +## Optional non-enforcement of Personal Access Token expiration **(ULTIMATE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/296881) in GitLab 13.9. -GitLab administrators can choose to prevent personal access tokens from expiring -automatically. The tokens are usable after the expiry date, unless they are revoked explicitly. +By default, expired personal access tokens (PATs) cannot be used. +You can allow the use of expired PATs with the following steps: To do this: diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md index 761fc6477d6..3d19bde9a26 100644 --- a/doc/user/admin_area/settings/continuous_integration.md +++ b/doc/user/admin_area/settings/continuous_integration.md @@ -27,7 +27,7 @@ From now on, every existing project and newly created ones that don't have a `.gitlab-ci.yml`, will use the Auto DevOps pipelines. If you want to disable it for a specific project, you can do so in -[its settings](../../../topics/autodevops/index.md#enablingdisabling-auto-devops). +[its settings](../../../topics/autodevops/index.md#enable-or-disable-auto-devops). ## Maximum artifacts size **(FREE SELF)** @@ -50,15 +50,15 @@ To change it at the: 1. Change the value of maximum artifacts size (in MB). 1. Click **Save changes** for the changes to take effect. -- [Group level](../../group/index.md#group-settings) (this will override the instance setting): +- Group level (this will override the instance setting): - 1. Go to the group's **Settings > CI / CD > General Pipelines**. + 1. Go to the group's **Settings > CI/CD > General Pipelines**. 1. Change the value of **maximum artifacts size (in MB)**. 1. Click **Save changes** for the changes to take effect. -- [Project level](../../../ci/pipelines/settings.md) (this will override the instance and group settings): +- Project level (this will override the instance and group settings): - 1. Go to the project's **Settings > CI / CD > General Pipelines**. + 1. Go to the project's **Settings > CI/CD > General Pipelines**. 1. Change the value of **maximum artifacts size (in MB)**. 1. Click **Save changes** for the changes to take effect. @@ -99,6 +99,13 @@ are allowed to expire. This setting takes precedence over the [project level setting](../../../ci/pipelines/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs). 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. 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** + When you disable the feature, the latest artifacts do not immediately expire. A new pipeline must run before the latest artifacts can expire and be deleted. diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index 3377b1674db..cbdc617d7d9 100644 --- a/doc/user/admin_area/settings/index.md +++ b/doc/user/admin_area/settings/index.md @@ -35,7 +35,7 @@ Access the default page for admin area settings by navigating to **Admin Area > | ------ | ----------- | | [Elasticsearch](../../../integration/elasticsearch.md#enabling-advanced-search) | Elasticsearch integration. Elasticsearch AWS IAM. | | [Kroki](../../../administration/integration/kroki.md#enable-kroki-in-gitlab) | Allow rendering of diagrams in AsciiDoc and Markdown documents using [kroki.io](https://kroki.io). | -| [PlantUML](../../../administration/integration/plantuml.md#gitlab) | Allow rendering of PlantUML diagrams in AsciiDoc and Markdown documents. | +| [PlantUML](../../../administration/integration/plantuml.md) | Allow rendering of PlantUML diagrams in documents. | | [Slack application](../../../user/project/integrations/gitlab_slack_application.md#configuration) **(FREE SAAS)** | Slack integration allows you to interact with GitLab via slash commands in a chat window. This option is only available on GitLab.com, though it may be [available for self-managed instances in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/28164). | | [Third party offers](third_party_offers.md) | Control the display of third party offers. | | [Snowplow](../../../development/snowplow.md) | Configure the Snowplow integration. | diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md index 7630f0c2fbd..600d99934aa 100644 --- a/doc/user/admin_area/settings/instance_template_repository.md +++ b/doc/user/admin_area/settings/instance_template_repository.md @@ -5,9 +5,9 @@ info: "To determine the technical writer assigned to the Stage/Group associated type: reference --- -# Instance template repository **(PREMIUM SELF)** **(FREE)** +# Instance template repository **(PREMIUM SELF)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in GitLab Premium 11.3. In hosted systems, enterprises often have a need to share their own templates across teams. This feature allows an administrator to pick a project to be the @@ -23,7 +23,7 @@ select the project to serve as the custom template repository.  After that, you can add custom templates to the selected repository and use them for the entire instance. -They will be available on the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns) +They are available in the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns) and through the [API settings](../../../api/settings.md). Templates must be added to a specific subdirectory in the repository, @@ -60,12 +60,12 @@ extension and not be empty. So, the hierarchy should look like this: |-- another_metrics-dashboard.yml ``` -Your custom templates will be displayed on the dropdown menu when a new file is added through the GitLab UI: +Your custom templates are displayed on the dropdown menu when a new file is added through the GitLab UI:  -If this feature is disabled or no templates are present, there will be -no "Custom" section in the selection dropdown. +If this feature is disabled or no templates are present, +no **Custom** section displays in the selection dropdown. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md index 18491f92650..0b9f039880a 100644 --- a/doc/user/admin_area/settings/project_integration_management.md +++ b/doc/user/admin_area/settings/project_integration_management.md @@ -4,7 +4,7 @@ group: Ecosystem 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 integration management +# Project integration management **(FREE)** Project integrations can be configured and enabled by project administrators. As a GitLab instance administrator, you can set default configuration parameters for a given integration that all projects 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 1d6424face0..7032c1031a9 100644 --- a/doc/user/admin_area/settings/push_event_activities_limit.md +++ b/doc/user/admin_area/settings/push_event_activities_limit.md @@ -14,7 +14,7 @@ allowed at once. If the number of events is greater than this, GitLab creates bulk push event instead. For example, if 4 branches are pushed and the limit is currently set to 3, -you'll see the following in the activity feed: +the activity feed displays:  diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 0945471b11b..0078db286a8 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -30,7 +30,7 @@ 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#approving-a-user) by an administrator before they can start using their account. This setting is enabled by default for newly created instances. This setting 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](../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. To require administrator approval for new sign ups: @@ -56,10 +56,29 @@ 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#approving-a-user) by an administrator before they can start using +[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. -If an administrator increases or removes the user cap, the users in pending approval state are +If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the +user cap, the users in pending approval state are automatically approved in a background job. + +### Set the user cap number + +1. Go to **Admin Area > Settings > General**. +1. Expand **Sign-up restrictions**. +1. Enter a number in **User cap**. +1. Select **Save changes**. + +New user sign ups are subject to the user cap restriction. + +## Remove the user cap + +1. Go to **Admin Area > Settings > General**. +1. Expand **Sign-up restrictions**. +1. Remove the number from **User cap**. +1. Select **Save changes**. + +New users sign ups are not subject to the user cap restriction. Users in pending approval state are automatically approved in a background job. ## Soft email confirmation diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index 2bb6adbc32b..ada44115cec 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -61,7 +61,7 @@ sequenceDiagram ## Usage Ping **(FREE SELF)** -See [Usage Ping guide](../../../development/usage_ping.md). +See [Usage Ping guide](../../../development/usage_ping/index.md). ## Instance-level analytics availability 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 0fcdbf3ca90..e335a9031d5 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -29,7 +29,7 @@ To change the default branch protection: For more details, see [Protected branches](../../project/protected_branches.md). -To change this setting for a specific group, see [Default branch protection for groups](../../group/index.md#changing-the-default-branch-protection-of-a-group) +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) ### Disable group owners from updating default branch protection **(PREMIUM SELF)** @@ -55,7 +55,7 @@ To change the default project creation protection: 1. Select the desired option. 1. Click **Save changes**. -For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level). +For more details, see [Specify who can add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group). ## Default project deletion protection **(PREMIUM SELF)** @@ -79,7 +79,7 @@ The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2. Projects in a group (but not a personal namespace) can be deleted after a delayed period, by -[configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal). +[configuring in Group Settings](../../group/index.md#enable-delayed-project-removal). The default period is seven days, and can be changed. Setting this period to `0` enables immediate removal of projects or groups. diff --git a/doc/user/admin_area/user_cohorts.md b/doc/user/admin_area/user_cohorts.md new file mode 100644 index 00000000000..f3c913b409a --- /dev/null +++ b/doc/user/admin_area/user_cohorts.md @@ -0,0 +1,36 @@ +--- +stage: none +group: unassigned +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 +--- + +# Cohorts **(FREE)** + +As a benefit of having the [usage ping active](settings/usage_statistics.md), +you can analyze your users' GitLab activities over time. + +To see user cohorts, go to **Admin Area > Overview > Users**. + +## Overview + +How do you interpret the user cohorts table? Let's review an example with the +following user cohorts: + + + +For the cohort of March 2020, three users were added to this server and have +been active since this month. One month later (April 2020), two users are still +active. Five months later (August 2020), one user from this cohort is still +active, or 33% of the original cohort of three that joined in March. + +The **Inactive users** column shows the number of users who were added during +the month, but who never had any activity in the instance. + +How do we measure the activity of users? GitLab considers a user active if: + +- The user signs in. +- The user has Git activity (whether push or pull). +- The user visits pages related to dashboards, projects, issues, or merge + requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8). +- The user uses the API. +- The user uses the GraphQL API. |
