diff options
Diffstat (limited to 'doc/user/admin_area')
| -rw-r--r-- | doc/user/admin_area/analytics/usage_trends.md | 19 | ||||
| -rw-r--r-- | doc/user/admin_area/approving_users.md | 49 | ||||
| -rw-r--r-- | doc/user/admin_area/credentials_inventory.md | 2 | ||||
| -rw-r--r-- | doc/user/admin_area/index.md | 20 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/account_and_limit_settings.md | 16 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/index.md | 2 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/project_integration_management.md | 2 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/sign_up_restrictions.md | 44 |
8 files changed, 105 insertions, 49 deletions
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/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..3d8a3a7c8c7 100644 --- a/doc/user/admin_area/credentials_inventory.md +++ b/doc/user/admin_area/credentials_inventory.md @@ -31,7 +31,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 | diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index b5e51e8d4c0..14a193322a5 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 @@ -187,7 +203,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/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md index 70416c224c7..25ab4ec173c 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -180,24 +180,26 @@ 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)** +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/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/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/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 0945471b11b..aacea397aaa 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,48 @@ 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. + +### Enable or disable User cap **(FREE SELF)** + +User cap is under development but ready for production use. +It is deployed behind a feature flag that is **enabled by default**. +[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) +can opt to disable it. + +To disable it: + +```ruby +Feature.disable(:admin_new_user_signups_cap) +``` + +To enable it: + +```ruby +Feature.enable(:admin_new_user_signups_cap) +``` + +### 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 |