Deactivate a user
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.
- 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).
- Consider an error message for 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