Skip to content

G
gitlab-ce
Commit 7176c651 authored by Russell Dickenson's avatar Russell Dickenson
Browse files
Options

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

Refine moderate users content

See merge request gitlab-org/gitlab!66417
parents d68c8da0 ebd3f701
Hide whitespace changes
Inline Side-by-side
Showing with 86 additions and 75 deletions
doc/.vale/gitlab/spelling-exceptions.txt
View file @ 7176c651
......@@ -687,6 +687,7 @@ unary
unassign
unassigning
unassigns
unban
uncheck
unchecked
unchecking
......
doc/api/settings.md
View file @ 7176c651
......@@ -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. |
| `commit_email_hostname` | string | no | Custom hostname (for private commit emails). |
| `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_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). |
......@@ -370,7 +370,7 @@ listed in the descriptions of the relevant settings.
| `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` | 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. |
| `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. |
......
doc/subscriptions/self_managed/index.md
View file @ 7176c651
......@@ -48,12 +48,15 @@ using [Seat Link](#seat-link).
A _billable user_ counts against the number of subscription seats. Every user is considered a
billable user, with the following exceptions:
- [Deactivated users](../../user/admin_area/moderate_users.md#deactivating-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
- [Deactivated users](../../user/admin_area/moderate_users.md#deactivate-a-user) and
[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.
- 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.
- 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
......@@ -183,7 +186,7 @@ Starting 30 days before a subscription expires, GitLab notifies administrators o
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. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) and select the **Renew** button beneath your existing subscription.
......
doc/user/admin_area/approving_users.md
View file @ 7176c651
---
stage: Manage
group: Access
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type: howto
redirect_to: 'moderate_users.md'
remove_date: '2021-10-20'
---
# Users pending approval
This document was moved to [another location](moderate_users.md).
A user in _pending approval_ state requires action by an administrator. A user sign up can be in a
pending approval state because an administrator has enabled either, or both, of the following
options:
- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
- [User cap](settings/sign_up_restrictions.md#user-cap).
When a user registers for an account while this setting is enabled:
- The user is placed in a **Pending approval** state.
- The user sees a message telling them their account is awaiting approval by an administrator.
A user pending approval:
- Is functionally identical to a [blocked](moderate_users.md#blocking-a-user) user.
- Cannot sign in.
- Cannot access Git repositories or the GitLab API.
- Does not receive any notifications from GitLab.
- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
sign in.
## View user sign ups pending approval
To view user sign ups pending approval:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
## Approve or reject a user sign up
A user sign up pending approval can be approved or rejected from the Admin Area.
To approve or reject a user sign up:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
1. (Optional) Select a user.
1. Select the **{settings}** **User administration** dropdown.
1. Select **Approve** or **Reject**.
Approving a user:
- Activates their account.
- Changes the user's state to active.
- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
<!-- This redirect file can be deleted after <2021-10-20>. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
doc/user/admin_area/index.md
View file @ 7176c651
......@@ -121,8 +121,8 @@ To list users matching a specific criteria, click on one of the following tabs o
- **2FA Enabled**
- **2FA Disabled**
- **External**
- **[Blocked](moderate_users.md#blocking-a-user)**
- **[Deactivated](moderate_users.md#deactivating-a-user)**
- **[Blocked](moderate_users.md#block-a-user)**
- **[Deactivated](moderate_users.md#deactivate-a-user)**
- **Without projects**
For each user, the following are listed:
......
doc/user/admin_area/moderate_users.md
View file @ 7176c651
......@@ -7,13 +7,66 @@ type: howto
# Moderate users
GitLab administrators can moderate user access by blocking, banning, or deactivating users.
GitLab administrators can moderate user access by approving, blocking, banning, or deactivating
users.
## Blocking and unblocking users
## Users pending approval
A user in _pending approval_ state requires action by an administrator. A user sign up can be in a
pending approval state because an administrator has enabled either, or both, of the following
options:
- [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) setting.
- [User cap](settings/sign_up_restrictions.md#user-cap).
When a user registers for an account while this setting is enabled:
- The user is placed in a **Pending approval** state.
- The user sees a message telling them their account is awaiting approval by an administrator.
A user pending approval:
- Is functionally identical to a [blocked](#block-a-user) user.
- Cannot sign in.
- Cannot access Git repositories or the GitLab API.
- Does not receive any notifications from GitLab.
- Does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
An administrator must [approve their sign up](#approve-or-reject-a-user-sign-up) to allow them to
sign in.
### View user sign ups pending approval
To view user sign ups pending approval:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
### Approve or reject a user sign up
A user sign up pending approval can be approved or rejected from the Admin Area.
To approve or reject a user sign up:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
1. (Optional) Select a user.
1. Select the **{settings}** **User administration** dropdown.
1. Select **Approve** or **Reject**.
Approving a user:
- Activates their account.
- Changes the user's state to active.
- Consumes a subscription [seat](../../subscriptions/self_managed/index.md#billable-users).
## Block and unblock users
GitLab administrators can block and unblock users.
### Blocking a user
### Block a user
In order to completely prevent access of a user to the GitLab instance,
administrators can choose to block the user.
......@@ -41,7 +94,7 @@ Users can also be blocked using the [GitLab API](../../api/users.md#block-user).
NOTE:
A blocked user does not consume a [seat](../../subscriptions/self_managed/index.md#billable-users).
### Unblocking a user
### Unblock a user
A blocked user can be unblocked from the Admin Area. To do this:
......@@ -58,18 +111,18 @@ NOTE:
Unblocking a user changes the user's state to active and consumes a
[seat](../../subscriptions/self_managed/index.md#billable-users).
## Activating and deactivating users
## Activate and deactivate users
GitLab administrators can deactivate and activate users.
### Deactivating a user
### Deactivate a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
In order to temporarily prevent access by a GitLab user that has no recent activity,
administrators can choose to deactivate the user.
Deactivating a user is functionally identical to [blocking a user](#blocking-and-unblocking-users),
Deactivating a user is functionally identical to [blocking a user](#block-and-unblock-users),
with the following differences:
- It does not prohibit the user from logging back in via the UI.
......@@ -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.
### Activating a user
### Activate a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4.
......
doc/user/admin_area/settings/sign_up_restrictions.md
View file @ 7176c651
......@@ -31,7 +31,10 @@ To disable sign ups:
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6.
When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
When this setting is enabled, any user visiting your GitLab domain and signing up for a new account
must be explicitly [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an
administrator before they can start using their account. In GitLab 13.6 and later, this setting is
enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
To require administrator approval for new sign ups:
......@@ -59,7 +62,7 @@ To enforce confirmation of the email address used for new sign ups:
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
When the number of billable users reaches the user cap, any user who is added or requests access must be
[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
[approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
their account.
If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
......
doc/user/profile/account/delete_account.md
View file @ 7176c651
......@@ -70,7 +70,7 @@ username of the original user.
When using the **Delete user and contributions** option, **all** associated records
are removed. This includes all of the items mentioned above including issues,
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.
When a user is deleted from an [abuse report](../../admin_area/review_abuse_reports.md)
......
doc/user/upgrade_email_bypass.md
View file @ 7176c651
......@@ -73,7 +73,7 @@ Your account has been blocked. Fatal: Could not read from remote repository
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.
## 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7