diff options
Diffstat (limited to 'doc/user/admin_area/settings/sign_up_restrictions.md')
| -rw-r--r-- | doc/user/admin_area/settings/sign_up_restrictions.md | 31 |
1 files changed, 5 insertions, 26 deletions
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index ddd3dbda9cc..0945471b11b 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# Sign-up restrictions **(CORE ONLY)** +# Sign-up restrictions **(FREE SELF)** You can enforce the following restrictions on sign ups: @@ -50,12 +50,10 @@ 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. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**. -## User cap **(CORE ONLY)** +## User cap **(FREE SELF)** > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7. -> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default. -> - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-user-cap). **(CORE ONLY)** +> - [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 @@ -64,29 +62,10 @@ their account. If an administrator increases or removes the user cap, the users in pending approval state are automatically approved in a background job. -### Enable or disable User cap **(CORE ONLY)** - -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) -``` - ## Soft email confirmation > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2. -> - It's [deployed behind a feature flag](../../..//user/feature_flags.md), disabled by default. +> - It's [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. > - It's enabled on GitLab.com. > - It's recommended for production use. > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-soft-email-confirmation). @@ -94,7 +73,7 @@ Feature.enable(:admin_new_user_signups_cap) WARNING: This feature might not be available to you. Check the **version history** note above for details. -The soft email confirmation improves the signup experience for new users by allowing +The soft email confirmation improves the sign-up experience for new users by allowing them to sign in without an immediate confirmation when an email confirmation is required. GitLab shows the user a reminder to confirm their email address, and the user can't create or update pipelines until their email address is confirmed. |