Deactivate a user (with self-service reactivation)
Description
One of the most common use cases for blocking a user is to render an account inactive so that it does not count as a licensed seat. Frequently, admins will groom their userbase (either manually or programmatically) for users with no activity and block them - blocking is useful, since it retains the user's history and allows the user to be reactivated later on with an unblock.
When a blocked user returns to GitLab and attempts to login, however, they're presented with a relatively generic "Your account has been blocked. Please contact your GitLab administrator if you think this is an error." message, which doesn't give them much guidance on how to proceed. This results in an internal support request and a manual action that needs to be taken by an admin to get them unblocked.
Considering that this user wasn't blocked for any adverse behavior, there's no reason that we shouldn't allow the user to simply log back in.
Proposal
- Allow admins to "deactivate" users via the admin panel and via the API.
- Deactivating a user is functionally identical to blocking a user, but 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.
- Inactive users do not take up a seat.
- Only allow deactivation for users who haven't had any activity in the last 14 days (don't present this option in the UI).
Additional:
- Present an error message to an inactive member attempting to pull or push code (they should log back in and reactivate first).
- Error message for attempting to deactivate a user who has had activity (
last_activity_on) in the past 14 days via the API. - Present a "your account has been reactivated" banner to a deactivated member who has logged in and reactivated their account.
Solution
MVC
- Let's add a 'Deactivate' option to the options menu in the Admin > Users overview table.
- Let's change the confirmations for deactivating and blocking users so that they're not native browser alerts but our own modals with explanations of what blocking and deactivating means.
- Let's add a 'Sort by' label to the sort by dropdown
- Let's add the option to deactivate a user to the user page (Admin > Users > User name)
| Menu update | Modal - block | Modal - deactivate | User page | Welcome back message |
|---|---|---|---|---|
 |
 |
 |
 |
 |
Future iterations
Let's minimize the amount of work that users need to do to complete this. We can:
- offer an option to deactivate multiple users that have been inactive to eliminate annoying repetitive work
- have a setting to enable automatic user deactivation after x days of inactivity
Option 1
| Show an alert on main dashboard | Show an alert on the Admin > Users overview | Confirm modal |
|---|---|---|
 |
 |
 |
Option 2
| New settings section collapsed | New settings section expanded |
|---|---|
 |
 |
Links / references
https://gitlab.com/gitlab-org/gitlab-ce/issues/45012 https://gitlab.com/gitlab-org/gitlab-ce/issues/41632