Why can't I delete a user from Confluence?

[Thomas B]

Recently, we had an employee leave the business. When trying to disable and delete the Confluence account, we have ran into some issues. I am unable to delete the user because: (see screenshot)

We went into the Database and changed all content and last modified fields to my Confluence ID and we delete all drafts (and succesfully disabled the user). This user does not own any spaces within Confluence. However, it does say that the user is an Author of a page in Confluence but we can't find a way to erase or change who authored a page.

I've read a lot of discussion about this but it's kind of ridiculous that administrators can't delete users in a software that we pay for. Is there any database query I can run to completely erase everything a user owns? Any suggestions? Please help.

[Danny Zuccaro · Accepted solution]

Believe it is by design that you can only disable and not delete a user that has created content. If you want to go the manual path to changing all created content you could try the steps on this page - https://confluence.atlassian.com/confkb/how-to-change-the-creator-of-a-page-720830744.html?_ga=1.264445775.1711482267.1484079204 and then delete the user. 

[Thomas B]

Yes. We have modified the database with this SQL Query already and changed all pages create by this user "xyz" to a currently user "abc" however, the page still has an "Author" field which cannot be changed for some reason. 

[Vishnukumar Vasudevan · Accepted solution]

Deleting users from Confluence/JIRA is not recommended rather you can disable/de-activate the user.  This would help to keep the track of all spaces/records where the user worked on. 

[Thomas B]

I understand, I have already disabled the user so they cannot log onto the system, but it would be nice to have the ability to delete users. 

[Jen]

I have previously deleted a user and now need to delete all their content, any idea how I can do this?

They no longer appear in the Users Directory, active or inactive.

[RobertG]

We have a small subscription, as folks leave the company we want to add new users to confluence. But it appears to block us from doing so until other users are removed from the system. Is there some instructions on how to do this?

[Nic Brough -Adaptavist- · Accepted solution]

Vishnukumar and Danny have already said most of what I would normally say.

I just wanted to add "do not edit the database".  You've missed things, and it's a nightmare to unpick. You also now have a possibly corrupt and definitely unsupported database.

Just disable the user and move on, it's not worth trying to force a delete this way.

[Thomas B]

I did notice a few things is Confluence behaving different after the changes but we created a backup prior to any manipulation and reverted back. Everything is fine now but I just expected an easy way.

[Hans Hvidbjerg Hanasen]

It's rather stupid we can't just delete people, then it can just ask how to manage old content. reassign it to a generic retired user or someone else...

Why would we have to look at people for 10 years into the future, who are not here any longer !!

[HW]

Sorry to pull this up again. I ran into this and am unsure if I encountered a bug or if I'm only too blind to see it: the KB (https://confluence.atlassian.com/doc/delete-or-disable-users-138318.html) says that deleting a user account is available from Conf 6.13 onwards. I have 7.1.2 but don't see the option to delete a user. Neither from the list nor after opening the details for that user. I got (historical) internal accounts in Conf AND am connected to a jira, that hosts accounts normally.

I understand that disabling a user may be sufficent (or even better) in some cases. But it won't work in two cases:

1. I have accounts that have been created in Confluence (internal) years ago and now may produce problems with an import from a different software, where the username is the same but the password ist not (for me, there's an account-synch like this for username and password: our own software -> jira -> confluence). Now a certain user can't log in and I just want to make sure that an old account in Conf isn't the problem and want to delete it (since it is abandoned anyway). So getting rid of historical users from older account management times is something you can't do by disabling accounts.

2. An employee leaves and I have to delete any personal information from all of our systems after a period according to the (european) law. And I would be happy if a software like confluence would offer to delete all traces instead of forcing me to go through the database directly taking all the risk of inconsistent data Nic has already mentioned in his 2017 post above.

This is just a comment, but maybe someone has any thought to share on this...

[Guntis Šusts]

Facing the same issue here being unable to delete users. Though I was able to delete one user but unable to delete another one. Perhaps beause it has created some content in the past, but I am not even sure how to locate that, as profile page doesn't show up anything...

[Thomas Fleischer]

@Hendrik Weißenberg 

I run into the same issue. Reason for not showing the "delete" Button is that the user is also in at least one external directory. You have to delete the external directory to delete the user.

BUT ATTENTION: When you delete the user everything will be anonymized. After reconnecting the external directory where the user still exists the delete user will be created as a completely new user.

That´s the reason why you can´t delete the user!

[RobertG]

https://support.atlassian.com/user-management/docs/remove-or-suspend-a-user/

Covers the deletion of a user. 

[Shroomy]

Not being able to delete users is definitely a problem regarding GDPR. In fact it is against the law to maintain personal information on the principle that "it's just practical to do so"...

[RobertG]

This seems to make some sense, but generally NDAs and Employee handbooks and in general working for a company gives the company rights to employee work product - including created confluence pages. 

Did the page include personal information - like SSN, BirthDate, Names - The first two seem to be a violation. But your name associated with a company and your phone number at the company (non personal cell number unless companied issued) seem to be fair game.

Where Atlassian fails or succeeds depending on how you look at it is if the page is still useful to the company then the company keeps it and also gives credit to the employee.

However, some employees just create and create content - and unfortunately this does not always mean they are super productive either. Sort of like bloggers, video bloggers youtubers. Meh, that's up to managers to curtail, or push them to put it in their personal space - that can be flushed later.

[Shroomy]

I think you are missing the point. It is not whether about the user being an employee or not. Sure the user might be an employee and may have signed an NDA/handbook. But the user can also be a non-employee invited to the instance (for example through a knowledge base for a service desk).

Employee or not; if a user demands their personally identifiable information (PII) deleted we are required by law to comply with this. In fact, users should always be deleted or anonymized if there is no warranted legal reason to keep them. usernames (if they can be used to reveal a user), emails, IPs and so on are by definition considered PII.

The argument "Deleting users from Confluence/JIRA is not recommended bla bla bla" is not good enough. This creates a considerable problem for admins when we are supposed to delete thousands of users without the right tools to do so.

The fact is that Atlassian, being a non-EU company doesn't care about EU regulations.

On one hand it is recommended not to delete users but on the other hand having too many users can cause instability. Still Atlassian does not provide us with the tools to conveniently remove users. 

Just to be clear my frustration is mostly rooted in the Jira and JSM, but the same goes for Confluence.

[RobertG]

Ok, I was thinking about page authorship.

As far as PII is concerned, it is more than just a name:

Sensitive PII is PII which if lost, compromised, or disclosed without authorization, could result in harm, embarrassment, inconvenience, or unfairness to an individual. The following types of PII are considered sensitive when associated with an individual:  Social Security Number (including truncated form), place of birth, date of birth, mother’s maiden name, biometric information, medical information (excluding brief references to absences from work), personal financial information, credit card or purchase card account numbers, passport numbers, potentially sensitive employment information (e.g., performance ratings, disciplinary actions, and results of background investigations), criminal history, and any information that may stigmatize or adversely affect an individual.

https://www.osec.doc.gov/opog/privacy/pii_bii.html