Moderate users (administration) (FREE SELF)

This is the administration documentation. For information about moderating users at the group level, see the group-level documentation.

GitLab administrators can moderate user access by approving, blocking, banning, or deactivating 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 any of the following options:

• Require administrator approval for new sign-ups setting.
• User cap.
• Block auto-created users (OmniAuth)
• Block auto-created users (LDAP)

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

To view user sign ups pending approval:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. 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 left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Pending approval tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select Approve or Reject.

Approving a user:

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

Block and unblock users

GitLab administrators can block and unblock users.

Block a user

To completely prevent access of a user to the GitLab instance, administrators can choose to block the user.

Users can be blocked via an abuse report, by removing them in LDAP, or directly from the Admin Area. To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Optional. Select a user.
5. Select the {settings} User administration dropdown list.
6. Select Block.

A blocked user:

• Cannot sign in.
• Cannot access Git repositories or the API.
• Does not receive any notifications from GitLab.
• Cannot use slash commands.
• Does not consume a seat.

Personal projects, and group and user history of the blocked user are left intact.

NOTE: Users can also be blocked using the GitLab API.

Unblock a user

A blocked user can be unblocked from the Admin Area. To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Blocked tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select 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. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Blocked tab.
5. Select a user.
6. Select the Identities tab.
7. Find the LDAP provider and select Delete.

Activate and deactivate users

GitLab administrators can deactivate and activate users.

Deactivate a user

Introduced in GitLab 12.4.

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, with the following differences:

• It does not prohibit the user from logging back in via the UI.
• Once a deactivated user logs back into the GitLab UI, their account is set to active.

A deactivated user:

• Cannot access Git repositories or the API.
• Does not receive any notifications from GitLab.
• Cannot use slash commands.
• Does not consume a seat.

Personal projects, and group and user history of the deactivated user are left intact.

NOTE: Users are notified about account deactivation if user deactivation emails are enabled.

A user can be deactivated from the Admin Area. To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Optional. Select a user.
5. Select the {settings} User administration dropdown list.
6. Select Deactivate.

For the deactivation option to be visible to an administrator, the user:

• Must have a state of active.
• Must be dormant.

NOTE: Users can also be deactivated using the GitLab API.

Automatically deactivate dormant users

• Introduced in GitLab 14.0.
• Exclusion of GitLab generate bots introduced in GitLab 14.5
• Customizable time period introduced in GitLab 15.4
• The lower limit for inactive period set to 90 days introduced in GitLab 15.5

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 do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Settings > General.
4. Expand the Account and limit section.
5. Under Dormant users, check Deactivate dormant users after a period of inactivity.
6. Under Days of inactivity before deactivation, enter the number of days before deactivation. Minimum value is 90 days.
7. Select Save changes.

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

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

NOTE: GitLab generated bots are excluded from the automatic deactivation of dormant users.

Automatically delete unconfirmed users (PREMIUM SELF)

• Introduced in GitLab 16.1 with a flag named delete_unconfirmed_users_setting. Disabled by default.
• Enabled by default in GitLab 16.2.

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:

 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.

Activate a user

Introduced in GitLab 12.4.

A deactivated user can be activated from the Admin Area.

To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Deactivated tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select Activate.

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

NOTE: A deactivated user can also activate their account themselves by logging back in via the UI. Users can also be activated using the GitLab API.

Ban and unban users

• Introduced in GitLab 14.2 with a flag named ban_user_feature_flag. Disabled by default.
• Ban and unban users generally available in GitLab 14.8. Feature flag ban_user_feature_flag removed.
• 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.

GitLab administrators can ban and unban users. Banned users are blocked, and their projects, issues, merge requests, and comments are hidden.

Ban a user

To block a user and hide their contributions, administrators can ban the user.

Users can be banned using the Admin Area. To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Optional. Select a user.
5. Select the {settings} User administration dropdown list.
6. Select Ban user.

The banned user does not consume a seat.

Unban a user

A banned user can be unbanned using the Admin Area. To do this:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Banned tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select Unban user.

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

Delete a user

Use the Admin Area to delete users.

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Banned tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select Delete user.
8. Type the username.
9. Select Delete user.

NOTE: You can only delete a user if there are inherited or direct owners of a group. You cannot delete a user if they are the only group owner.

You can also delete a user and their contributions, such as merge requests, issues, and groups of which they are the only group owner.

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. Select Overview > Users.
4. Select the Banned tab.
5. Optional. Select a user.
6. Select the {settings} User administration dropdown list.
7. Select Delete user and contributions.
8. Type the username.
9. Select Delete user and contributions.

NOTE: Before 15.1, additionally groups of which deleted user were the only owner among direct members were deleted.

Troubleshooting

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.

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.

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.

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