1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
---
type: howto
---
# Deleting a User account
Users can be deleted from a GitLab instance, either by:
- The user themselves.
- An administrator.
NOTE: **Note:**
Deleting a user will delete all projects in that user namespace.
## As a user
As a user, you can delete your own account by:
1. Clicking on your avatar.
1. Navigating to **Settings > Account**.
1. Selecting **Delete account**.
## As an administrator
As an administrator, you can delete a user account by:
1. Navigating to **Admin Area > Overview > Users**.
1. Selecting a user.
1. Under the **Account** tab, clicking:
- **Delete user** to delete only the user but maintaining their
[associated records](#associated-records).
- **Delete user and contributions** to delete the user and
their associated records.
### Blocking a user
In addition to blocking a user
[via an abuse report](../../admin_area/abuse_reports.md#blocking-users),
a user can be blocked directly from the Admin area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Selecting a user.
1. Under the **Account** tab, click **Block user**.
### Deactivating a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
A user can be deactivated from the Admin area. 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.
- Will not receive any notifications from GitLab.
- Will not be able to use [slash commands](../../../integration/slash_commands.md).
Personal projects, group and user history of the deactivated user will be left intact.
NOTE: **Note:**
A deactivated user does not consume a [seat](../../../subscriptions/index.md#managing-subscriptions).
To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Select a user.
1. Under the **Account** tab, click **Deactivate user**.
Please note that for the deactivation option to be visible to an admin, the user:
- Must be currently active.
- Should not have any activity in the last 14 days.
### Activating a user
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
A deactivated user can be activated from the Admin area. Activating a user sets their account to active state.
To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Click on the **Deactivated** tab.
1. Select a user.
1. Under the **Account** tab, click **Activate user**.
TIP: **Tip:**
A deactivated user can also activate their account by themselves by simply logging back via the UI.
## Associated Records
> - Introduced for issues in
> [GitLab 9.0](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/7393).
> - Introduced for merge requests, award emoji, notes, and abuse reports in
> [GitLab 9.1](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10467).
> - Hard deletion from abuse reports and spam logs was introduced in
> [GitLab 9.1](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10273),
> and from the API in
> [GitLab 9.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/11853).
When a user account is deleted, not all associated records are deleted with it.
Here's a list of things that will **not** be deleted:
- Issues that the user created.
- Merge requests that the user created.
- Notes that the user created.
- Abuse reports that the user reported.
- Award emoji that the user created.
Instead of being deleted, these records will be moved to a system-wide
user with the username "Ghost User", whose sole purpose is to act as a container
for such records. Any commits made by a deleted user will still display the
username of the original user.
When a user is deleted from an [abuse report](../../admin_area/abuse_reports.md)
or spam log, these associated
records are not ghosted and will be removed, along with any groups the user
is a sole owner of. Administrators can also request this behavior when
deleting users from the [API](../../../api/users.md#user-deletion) or the
Admin Area.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
|