Commit 7176c651 authored by Russell Dickenson's avatar Russell Dickenson

Merge branch 'eread/refine-moderate-users-content' into 'master'

Refine moderate users content

See merge request gitlab-org/gitlab!66417
parents d68c8da0 ebd3f701
...@@ -687,6 +687,7 @@ unary ...@@ -687,6 +687,7 @@ unary
unassign unassign
unassigning unassigning
unassigns unassigns
unban
uncheck uncheck
unchecked unchecked
unchecking unchecking
......
...@@ -241,7 +241,7 @@ listed in the descriptions of the relevant settings. ...@@ -241,7 +241,7 @@ listed in the descriptions of the relevant settings.
| `check_namespace_plan` | boolean | no | **(PREMIUM)** Enabling this makes only licensed EE features available to projects if the project namespace's plan includes the feature or if the project is public. | | `check_namespace_plan` | boolean | no | **(PREMIUM)** Enabling this makes only licensed EE features available to projects if the project namespace's plan includes the feature or if the project is public. |
| `commit_email_hostname` | string | no | Custom hostname (for private commit emails). | | `commit_email_hostname` | string | no | Custom hostname (for private commit emails). |
| `container_registry_token_expire_delay` | integer | no | Container Registry token duration in minutes. | | `container_registry_token_expire_delay` | integer | no | Container Registry token duration in minutes. |
| `deactivate_dormant_users` | boolean | no | Enable [atomatic deactivation of dormant users](../user/admin_area/moderate_users.md#automatically-deactivate-dormant-users). | | `deactivate_dormant_users` | boolean | no | Enable [automatic deactivation of dormant users](../user/admin_area/moderate_users.md#automatically-deactivate-dormant-users). |
| `default_artifacts_expire_in` | string | no | Set the default expiration time for each job's artifacts. | | `default_artifacts_expire_in` | string | no | Set the default expiration time for each job's artifacts. |
| `default_branch_protection` | integer | no | Determine if developers can push to the default branch. Can take: `0` _(not protected, both developers and maintainers can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push, or delete, the branch)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. | | `default_branch_protection` | integer | no | Determine if developers can push to the default branch. Can take: `0` _(not protected, both developers and maintainers can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push, or delete, the branch)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
| `default_ci_config_path` | string | no | Default CI/CD configuration file and path for new projects (`.gitlab-ci.yml` if not set). | | `default_ci_config_path` | string | no | Default CI/CD configuration file and path for new projects (`.gitlab-ci.yml` if not set). |
...@@ -370,7 +370,7 @@ listed in the descriptions of the relevant settings. ...@@ -370,7 +370,7 @@ listed in the descriptions of the relevant settings.
| `repository_size_limit` | integer | no | **(PREMIUM)** Size limit per repository (MB) | | `repository_size_limit` | integer | no | **(PREMIUM)** Size limit per repository (MB) |
| `repository_storages_weighted` | hash of strings to integers | no | (GitLab 13.1 and later) Hash of names of taken from `gitlab.yml` to [weights](../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored). New projects are created in one of these stores, chosen by a weighted random selection. | | `repository_storages_weighted` | hash of strings to integers | no | (GitLab 13.1 and later) Hash of names of taken from `gitlab.yml` to [weights](../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored). New projects are created in one of these stores, chosen by a weighted random selection. |
| `repository_storages` | array of strings | no | (GitLab 13.0 and earlier) List of names of enabled storage paths, taken from `gitlab.yml`. New projects are created in one of these stores, chosen at random. | | `repository_storages` | array of strings | no | (GitLab 13.0 and earlier) List of names of enabled storage paths, taken from `gitlab.yml`. New projects are created in one of these stores, chosen at random. |
| `require_admin_approval_after_user_signup` | boolean | no | When enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state and has to be explicitly [approved](../user/admin_area/approving_users.md) by an administrator. | | `require_admin_approval_after_user_signup` | boolean | no | When enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state and has to be explicitly [approved](../user/admin_area/moderate_users.md) by an administrator. |
| `require_two_factor_authentication` | boolean | no | (**If enabled, requires:** `two_factor_grace_period`) Require all users to set up Two-factor authentication. | | `require_two_factor_authentication` | boolean | no | (**If enabled, requires:** `two_factor_grace_period`) Require all users to set up Two-factor authentication. |
| `restricted_visibility_levels` | array of strings | no | Selected levels cannot be used by non-Administrator users for groups, projects or snippets. Can take `private`, `internal` and `public` as a parameter. Default is `null` which means there is no restriction. | | `restricted_visibility_levels` | array of strings | no | Selected levels cannot be used by non-Administrator users for groups, projects or snippets. Can take `private`, `internal` and `public` as a parameter. Default is `null` which means there is no restriction. |
| `rsa_key_restriction` | integer | no | The minimum allowed bit length of an uploaded RSA key. Default is `0` (no restriction). `-1` disables RSA keys. | | `rsa_key_restriction` | integer | no | The minimum allowed bit length of an uploaded RSA key. Default is `0` (no restriction). `-1` disables RSA keys. |
......
...@@ -48,12 +48,15 @@ using [Seat Link](#seat-link). ...@@ -48,12 +48,15 @@ using [Seat Link](#seat-link).
A _billable user_ counts against the number of subscription seats. Every user is considered a A _billable user_ counts against the number of subscription seats. Every user is considered a
billable user, with the following exceptions: billable user, with the following exceptions:
- [Deactivated users](../../user/admin_area/moderate_users.md#deactivating-a-user) and - [Deactivated users](../../user/admin_area/moderate_users.md#deactivate-a-user) and
[blocked users](../../user/admin_area/moderate_users.md#blocking-a-user) don't count as billable users in the current subscription. When they are either deactivated or blocked they release a _billable user_ seat. However, they may [blocked users](../../user/admin_area/moderate_users.md#block-a-user) don't count as billable users in the current subscription. When they are either deactivated or blocked they release a _billable user_ seat. However, they may
count toward overages in the subscribed seat count. count toward overages in the subscribed seat count.
- Users who are [pending approval](../../user/admin_area/approving_users.md). - Users who are [pending approval](../../user/admin_area/moderate_users.md#users-pending-approval).
- Members with Guest permissions on an Ultimate subscription. - Members with Guest permissions on an Ultimate subscription.
- GitLab-created service accounts: `Ghost User` and bots [(`Support Bot`](../../user/project/service_desk.md#support-bot-user), [`Project bot users`](../../user/project/settings/project_access_tokens.md#project-bot-users), and so on). - GitLab-created service accounts: `Ghost User` and bots
([`Support Bot`](../../user/project/service_desk.md#support-bot-user),
[`Project bot users`](../../user/project/settings/project_access_tokens.md#project-bot-users), and
so on.)
### Tips for managing users and subscription seats ### Tips for managing users and subscription seats
...@@ -183,7 +186,7 @@ Starting 30 days before a subscription expires, GitLab notifies administrators o ...@@ -183,7 +186,7 @@ Starting 30 days before a subscription expires, GitLab notifies administrators o
We recommend following these steps during renewal: We recommend following these steps during renewal:
1. Prune any inactive or unwanted users by [blocking them](../../user/admin_area/moderate_users.md#blocking-a-user). 1. Prune any inactive or unwanted users by [blocking them](../../user/admin_area/moderate_users.md#block-a-user).
1. Determine if you have a need for user growth in the upcoming subscription. 1. Determine if you have a need for user growth in the upcoming subscription.
1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) and select the **Renew** button beneath your existing subscription. 1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) and select the **Renew** button beneath your existing subscription.
......
--- ---
stage: Manage redirect_to: 'moderate_users.md'
group: Access remove_date: '2021-10-20'
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type: howto
--- ---
# Users pending approval This document was moved to [another location](moderate_users.md).
A user in _pending approval_ state requires action by an administrator. A user sign up can be in a <!-- This redirect file can be deleted after <2021-10-20>. -->
pending approval state because an administrator has enabled either, or both, of the following <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
options:
- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
- [User cap](settings/sign_up_restrictions.md#user-cap).
When a user registers for an account while this setting is enabled:
- The user is placed in a **Pending approval** state.
- The user sees a message telling them their account is awaiting approval by an administrator.
A user pending approval:
- Is functionally identical to a [blocked](moderate_users.md#blocking-a-user) user.
- Cannot sign in.
- Cannot access Git repositories or the GitLab API.
- Does not receive any notifications from GitLab.
- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
sign in.
## View user sign ups pending approval
To view user sign ups pending approval:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
## Approve or reject a user sign up
A user sign up pending approval can be approved or rejected from the Admin Area.
To approve or reject a user sign up:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
1. (Optional) Select a user.
1. Select the **{settings}** **User administration** dropdown.
1. Select **Approve** or **Reject**.
Approving a user:
- Activates their account.
- Changes the user's state to active.
- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
...@@ -121,8 +121,8 @@ To list users matching a specific criteria, click on one of the following tabs o ...@@ -121,8 +121,8 @@ To list users matching a specific criteria, click on one of the following tabs o
- **2FA Enabled** - **2FA Enabled**
- **2FA Disabled** - **2FA Disabled**
- **External** - **External**
- **[Blocked](moderate_users.md#blocking-a-user)** - **[Blocked](moderate_users.md#block-a-user)**
- **[Deactivated](moderate_users.md#deactivating-a-user)** - **[Deactivated](moderate_users.md#deactivate-a-user)**
- **Without projects** - **Without projects**
For each user, the following are listed: For each user, the following are listed:
......
...@@ -7,13 +7,66 @@ type: howto ...@@ -7,13 +7,66 @@ type: howto
# Moderate users # Moderate users
GitLab administrators can moderate user access by blocking, banning, or deactivating users. GitLab administrators can moderate user access by approving, blocking, banning, or deactivating
users.
## Blocking and unblocking users ## Users pending approval
A user in _pending approval_ state requires action by an administrator. A user sign up can be in a
pending approval state because an administrator has enabled either, or both, of the following
options:
- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
- [User cap](settings/sign_up_restrictions.md#user-cap).
When a user registers for an account while this setting is enabled:
- The user is placed in a **Pending approval** state.
- The user sees a message telling them their account is awaiting approval by an administrator.
A user pending approval:
- Is functionally identical to a [blocked](#block-a-user) user.
- Cannot sign in.
- Cannot access Git repositories or the GitLab API.
- Does not receive any notifications from GitLab.
- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
sign in.
### View user sign ups pending approval
To view user sign ups pending approval:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
### Approve or reject a user sign up
A user sign up pending approval can be approved or rejected from the Admin Area.
To approve or reject a user sign up:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
1. (Optional) Select a user.
1. Select the **{settings}** **User administration** dropdown.
1. Select **Approve** or **Reject**.
Approving a user:
- Activates their account.
- Changes the user's state to active.
- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
## Block and unblock users
GitLab administrators can block and unblock users. GitLab administrators can block and unblock users.
### Blocking a user ### Block a user
In order to completely prevent access of a user to the GitLab instance, In order to completely prevent access of a user to the GitLab instance,
administrators can choose to block the user. administrators can choose to block the user.
...@@ -41,7 +94,7 @@ Users can also be blocked using the [GitLab API](../../api/users.md#block-user). ...@@ -41,7 +94,7 @@ Users can also be blocked using the [GitLab API](../../api/users.md#block-user).
NOTE: NOTE:
A blocked user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users). A blocked user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
### Unblocking a user ### Unblock a user
A blocked user can be unblocked from the Admin Area. To do this: A blocked user can be unblocked from the Admin Area. To do this:
...@@ -58,18 +111,18 @@ NOTE: ...@@ -58,18 +111,18 @@ NOTE:
Unblocking a user changes the user's state to active and consumes a Unblocking a user changes the user's state to active and consumes a
[seat](../../subscriptions/self_managed/index.md#billable-users). [seat](../../subscriptions/self_managed/index.md#billable-users).
## Activating and deactivating users ## Activate and deactivate users
GitLab administrators can deactivate and activate users. GitLab administrators can deactivate and activate users.
### Deactivating a user ### Deactivate a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
In order to temporarily prevent access by a GitLab user that has no recent activity, In order to temporarily prevent access by a GitLab user that has no recent activity,
administrators can choose to deactivate the user. administrators can choose to deactivate the user.
Deactivating a user is functionally identical to [blocking a user](#blocking-and-unblocking-users), Deactivating a user is functionally identical to [blocking a user](#block-and-unblock-users),
with the following differences: with the following differences:
- It does not prohibit the user from logging back in via the UI. - It does not prohibit the user from logging back in via the UI.
...@@ -118,7 +171,7 @@ When this feature is enabled, GitLab runs a job once a day to deactivate the dor ...@@ -118,7 +171,7 @@ When this feature is enabled, GitLab runs a job once a day to deactivate the dor
A maximum of 100,000 users can be deactivated per day. A maximum of 100,000 users can be deactivated per day.
### Activating a user ### Activate a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
......
...@@ -31,7 +31,10 @@ To disable sign ups: ...@@ -31,7 +31,10 @@ To disable sign ups:
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5. > - [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. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6.
When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled. When this setting is enabled, any user visiting your GitLab domain and signing up for a new account
must be explicitly [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an
administrator before they can start using their account. In GitLab 13.6 and later, this setting is
enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
To require administrator approval for new sign ups: To require administrator approval for new sign ups:
...@@ -59,7 +62,7 @@ To enforce confirmation of the email address used for new sign ups: ...@@ -59,7 +62,7 @@ To enforce confirmation of the email address used for new sign ups:
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9. > - [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 When the number of billable users reaches the user cap, any user who is added or requests access must be
[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
their account. their account.
If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
......
...@@ -70,7 +70,7 @@ username of the original user. ...@@ -70,7 +70,7 @@ username of the original user.
When using the **Delete user and contributions** option, **all** associated records When using the **Delete user and contributions** option, **all** associated records
are removed. This includes all of the items mentioned above including issues, are removed. This includes all of the items mentioned above including issues,
merge requests, notes/comments, and more. Consider merge requests, notes/comments, and more. Consider
[blocking a user](../../admin_area/moderate_users.md#blocking-a-user) [blocking a user](../../admin_area/moderate_users.md#block-a-user)
or using the **Delete user** option instead. or using the **Delete user** option instead.
When a user is deleted from an [abuse report](../../admin_area/review_abuse_reports.md) When a user is deleted from an [abuse report](../../admin_area/review_abuse_reports.md)
......
...@@ -73,7 +73,7 @@ Your account has been blocked. Fatal: Could not read from remote repository ...@@ -73,7 +73,7 @@ Your account has been blocked. Fatal: Could not read from remote repository
Your primary email address is not confirmed. Your primary email address is not confirmed.
``` ```
You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#blocking-and-unblocking-users) by an administrator. You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#block-and-unblock-users) by an administrator.
When affected users see this message, they must confirm their email address before they can commit code. When affected users see this message, they must confirm their email address before they can commit code.
## What do I need to know as an administrator of a GitLab self-managed Instance? ## What do I need to know as an administrator of a GitLab self-managed Instance?
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment