ContextQMD
Back to Gitlabhq

Moderate users

doc/administration/moderate_users.md

18.11.218.9 KB
Original Source

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

If you are an instance administrator, you have several options to moderate and control user access.

[!note] This topic is specifically related to user moderation in GitLab Self-Managed. For information related to groups, see the group documentation.

View users

To view all the users in your instance:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.

Select a user to view their account information.

View users by type

{{< history >}}

{{< /history >}}

Established GitLab instances can often have large numbers of human and bot users. You can filter the list of users to display only human or bot users.

To view users by type:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, enter a filter.
    • To display human users, enter Type=Humans.
    • To display bot users, enter Type=Bots.
  4. Press <kbd>Enter</kbd>.

Billable users

You can view and update the billable users in your instance through the Rails console.

Check daily and historical billable users

To get a list of daily and historical billable users in your GitLab instance:

  1. Start a Rails console session.

  2. Count the number of users in the instance:

    ruby
    User.billable.count

  3. Get the historical maximum number of users on the instance from the past year:

    ruby
    ::HistoricalData.max_historical_user_count(from: 1.year.ago.beginning_of_day, to: Time.current.end_of_day)

Update daily and historical billable users

To trigger a manual update of the daily and historical billable users in your GitLab instance:

  1. Start a Rails console session.

  2. Force an update of the daily billable users:

    ruby
    identifier = Analytics::UsageTrends::Measurement.identifiers[:billable_users]
::Analytics::UsageTrends::CounterJobWorker.new.perform(identifier, User.minimum(:id), User.maximum(:id), Time.zone.now)

  3. Force an update of the historical max billable users:

    ruby
    ::HistoricalDataWorker.new.perform

Users pending approval

A user in a pending approval state requires action by an administrator. A user sign up can be in a pending approval state because an administrator has enabled any of the following options:

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 user.
  • Cannot sign in.
  • Cannot access Git repositories or the GitLab API.
  • Does not receive any notifications from GitLab.
  • Does not consume a seat.

An administrator must approve their sign up to allow them to sign in.

View user sign ups pending approval

{{< history >}}

  • Filter users by state introduced in GitLab 17.0.

{{< /history >}}

To view user sign ups pending approval:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Pending approval, and press <kbd>Enter</kbd>.

Approve or reject a new user account

{{< history >}}

  • Filter users by state introduced in GitLab 17.0.

{{< /history >}}

A user sign up pending approval can be approved or rejected from the Admin area.

To approve or reject a user sign up:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Pending approval and press <kbd>Enter</kbd>.
  4. For the user sign up you want to approve or reject, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), then Approve or Reject.

Approving a user:

  • Activates their account.
  • Changes the user's state to active.
  • Consumes a subscription seat.

Rejecting a user:

  • Prevents the user from signing in or accessing instance information.
  • Deletes the user.

View users pending role promotion

If administrator approval for role promotions is turned on, membership requests that promote existing users into a billable role require administrator approval.

To view users pending role promotion:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. Select Role Promotions.

A list of users with the highest role requested is displayed. You can Approve or Reject the requests.

Block and unblock users

GitLab administrators can block and unblock users. You should block a user when you don't want them to access the instance, but you want to retain their data.

A blocked user:

  • Cannot sign in or access any repositories.
    • Any associated data remains in these repositories.
  • Cannot use slash commands in Slack.
  • Does not occupy a seat.

Block a user

Prerequisites:

  • You must be an administrator for the instance.

You can block a user's access to the instance.

To block a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. For the user you want to block, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), then Block.

To report abuse from other users, see report abuse. For more information on abuse reports in the Admin area, see resolving abuse reports.

Unblock a user

{{< history >}}

  • Filter users by state introduced in GitLab 17.0.

{{< /history >}}

You can unblock a user so they regain access to the instance.

To unblock a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Blocked and press <kbd>Enter</kbd>.
  4. For the user you want to unblock, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), then Unblock.

The user's state is set to active and they consume a seat.

[!note] Users can also be unblocked using the GitLab API.

The unblock option may be unavailable for LDAP users. To enable the unblock option, the LDAP identity first needs to be deleted:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Blocked and press <kbd>Enter</kbd>.
  4. Select a user.
  5. Select the Identities tab.
  6. Find the LDAP provider and select Delete.

Deactivate and reactivate users

GitLab administrators can deactivate and reactivate users. You should deactivate a user if they have no recent activity, and you do not want them to occupy a seat on the instance.

A deactivated user:

  • Can sign in to GitLab.
    • If a deactivated user signs in, they are automatically reactivated.
  • Cannot access repositories or the API.
  • Cannot use slash commands in Slack.
  • Does not occupy a seat. For more information, see billable users.

When you deactivate a user, their projects, groups, and history remain.

Deactivate a user

Prerequisites:

  • The user has had no activity in the last 90 days.

To deactivate a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. For the user you want to deactivate, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}) and then Deactivate.
  4. On the dialog, select Deactivate.

The user receives an email notification that their account has been deactivated. After this email, they no longer receive notifications. For more information, see user deactivation emails.

To deactivate users with the GitLab API, see deactivate user. For information about permanent user restrictions, see block and unblock users.

To remove a user from a GitLab.com subscription, see Remove users from your subscription.

Automatically deactivate dormant users

{{< history >}}

  • Customizable time period introduced in GitLab 15.4
  • The lower limit for inactive period set to 90 days introduced in GitLab 15.5

{{< /history >}}

Administrators can enable automatic deactivation of users who either:

  • Were created more than a week ago and have not signed in.
  • Have no activity for a specified period of time (default and minimum is 90 days).

To automatically deactivate dormant members:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand the Account and limit section.
  4. Under Dormant users, check Deactivate dormant users after a period of inactivity.
  5. Under Days of inactivity before deactivation, enter the number of days before deactivation. Minimum value is 90 days.
  6. Select Save changes.

When this feature is enabled, GitLab runs a daily job to deactivate the dormant users.

A maximum of 100,000 users can be deactivated per day.

By default, users receive an email notification when their account is deactivated. You can disable user deactivation emails.

[!note] GitLab generated bots are excluded from the automatic deactivation of dormant users.

Automatically delete unconfirmed users

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab Self-Managed

{{< /details >}}

{{< history >}}

{{< /history >}}

Prerequisites:

  • You must be an administrator.

You can enable automatic deletion of users who both:

  • Never confirmed their email address.
  • Signed up for GitLab more than a specified number of days in the past.

You can configure these settings using either the Settings API or in a Rails console:

ruby
 Gitlab::CurrentSettings.update(delete_unconfirmed_users: true)
 Gitlab::CurrentSettings.update(unconfirmed_users_delete_after_days: 365)

When the delete_unconfirmed_users setting is enabled, GitLab runs a job once an hour to delete the unconfirmed users. The job only deletes users who signed up more than unconfirmed_users_delete_after_days days in the past.

This job only runs when the email_confirmation_setting is set to soft or hard.

A maximum of 240,000 users can be deleted per day.

Reactivate a user

{{< history >}}

  • Filter users by state introduced in GitLab 17.0.

{{< /history >}}

To reactivate a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Deactivated and press <kbd>Enter</kbd>.
  4. For the user you want to reactivate, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), then Activate.

The user's state is set to active and they consume a seat.

[!note] A deactivated user can also reactivate their account themselves by logging back in through the UI. Users can also be reactivated using the GitLab API.

Ban and unban users

{{< history >}}

  • Hiding merge requests of banned users introduced in GitLab 15.8 with a flag named hide_merge_requests_from_banned_users. Disabled by default.
  • Hiding comments of banned users introduced in GitLab 15.11 with a flag named hidden_notes. Disabled by default.
  • Hiding projects of banned users introduced in GitLab 16.2 with a flag named hide_projects_of_banned_users. Disabled by default.
  • Hiding merge requests of banned users generally available in GitLab 18.0. Feature flag hide_merge_requests_from_banned_users removed.

{{< /history >}}

GitLab administrators can ban and unban users. You should ban a user when you want to block them and hide their activity from the instance.

A banned user:

  • Cannot sign in or access any repositories.
    • Any associated projects, issues, merge requests, or comments are hidden.
  • Cannot use slash commands in Slack.
  • Does not occupy a seat.

Ban a user

You can ban a user to block them and hide their contributions.

To ban a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. Next to the member you want to ban, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}).
  4. From the dropdown list, select Ban member.

Unban a user

{{< history >}}

  • Filter users by state introduced in GitLab 17.0.

{{< /history >}}

To unban a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Banned and press <kbd>Enter</kbd>.
  4. Next to the member you want to ban, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}).
  5. From the dropdown list, select Unban member.

The user's state is set to active and they consume a seat.

Delete a user

To delete a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. For the user you want to delete, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), then Delete user.
  4. Type the username.
  5. Select either:
    • Delete user, to delete only the user.
    • Delete user and contributions, to delete the user and their contributions, such as merge requests, issues, and groups of which they are the only group owner.

[!note] You can only delete a user if they are an inherited or direct owner of a group. You cannot delete a user if they are the only group owner.

Trust and untrust users

{{< history >}}

{{< /history >}}

By default, users are not trusted and are blocked from creating issues, notes, and snippets considered to be spam. When you trust a user, they can create issues, notes, and snippets without being blocked.

Trust a user

To trust a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. Select a user.
  4. From the User administration dropdown list, select Trust user.
  5. On the confirmation dialog, select Trust user.

Untrust a user

To untrust a user:

  1. In the upper-right corner, select Admin.
  2. Select Overview > Users.
  3. In the search box, filter by State=Trusted and press <kbd>Enter</kbd>.
  4. Select a user.
  5. From the User administration dropdown list, select Untrust user.
  6. On the confirmation dialog, select Untrust user.

Troubleshooting

{{< details >}}

  • Offering: GitLab Self-Managed

{{< /details >}}

When moderating users, you may need to perform bulk actions on them based on certain conditions. The following rails console scripts show some examples of this. You may start a rails console session and use scripts similar to the following:

Deactivate users that have no recent activity

Administrators can deactivate users that have no recent activity.

[!warning] Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

ruby
days_inactive = 90
inactive_users = User.active.where("last_activity_on <= ?", days_inactive.days.ago)

inactive_users.each do |user|
    puts "user '#{user.username}': #{user.last_activity_on}"
    user.deactivate!
end

Block users that have no recent activity

Administrators can block users that have no recent activity.

[!warning] Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

ruby
days_inactive = 90
inactive_users = User.active.where("last_activity_on <= ?", days_inactive.days.ago)

inactive_users.each do |user|
    puts "user '#{user.username}': #{user.last_activity_on}"
    user.block!
end

Block or delete users that have no projects or groups

Administrators can block or delete users that have no projects or groups.

[!warning] Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

ruby
users = User.where('id NOT IN (select distinct(user_id) from project_authorizations)')

# How many users are removed?
users.count

# If that count looks sane:

# You can either block the users:
users.each { |user|  user.blocked? ? nil  : user.block! }

# Or you can delete them:
  # need 'current user' (your user) for auditing purposes
current_user = User.find_by(username: '<your username>')

users.each do |user|
  DeleteUserWorker.perform_async(current_user.id, user.id)
end