@Atlassian Support - PLEASE READ AND UNDERSTAND!!!

Just want to give you a chance to fix it BEFORE I will inform the European Data Security Court.

After Mai 2018 the new EU General Data Protection Regulation (DSGVO) aims to harmonize data protection law in order to give consumers more control over their data. 

With your (sadly - as always) attitude to ignore your customers, you're preventing deleting the data that MUST BE deleted due to that law.

Our employee has left our company and he insist on deletion on any content he wrote. So we must delete the content and his account.

And I dont want to follow an unsupported path. If anything goes wrong you'll put the blame on us.

Please give a quick reply how to delete (or replace) this users information in the Jira directory - as a supported solution!!!

If I dont see any feedback until the 18th of December 2020 I'll inform the European Data Security Court that your software don't support the deletion of users/content in an approiate way and your support doesn't even provide a workaround for that.

Thank you in advance.

We have a lot of people joining and leaving the projects / company so after a couple of years out of the 1500 users about 950 had been given the status "inactive".  I also struggled not being able to delete user because some comments still were associated. I did the following to resolve this (  please do this only at your own risk and make sure your environment is properly backupped etc ).

Running on postgresql i connected as admin to jiradb and just changed table entries of user 'person x' to my name 'cmadmin':

jiradb=> update jiraaction set author = 'cmadmin' where author = 'person x';

Strangely it only worked using no capitals in user name but when running jiradb=> select * from  jiraaction; thats logical.

Now you can use "user manager -> delete" to delete this user.

If this is still not working due to user being assign to a ticket or being reporter of a ticket, i have used sql search: assignee = 'person x' or reporter = 'person x' to bulkchange these issues ( change assignee -> cmadin , reporter -> cmadmin ).

Agree with Erik - it's annoying to have such as long list of legacy user accounts. An example - I've imported projects from various sources and it created multiple local user accounts that are not needed. There was no option to remap them to other users during import (would be very useful). I recon super admins should have the right to manipulate comments and reassign them or as Erik mentioned make them flat text thus allow cluttering user accounts to be removed from the system permanently.

Hi all,

While there is no 'business critical' reason to be able to completely delete users, it is indeed annoying that we now have a huge user list without the possibility of completely deleting the inactive users (e.g. that have left the company). While I understand that from a historical and data reference integrity perspective this is good practice, I do think there are some alternatives that can achieve both goals, for example:

• Instead of deleting the user from the database, create a flag that makes the user invisible in the GUI
• Update all references to that user to a flat text representation of the username, so the user can be deleted, but is still findable in a search query

I remember Mantis achieved a similar solution by updating a username to 'user215' which was far from ideal, for obvious reasons, but the mechanism was similar to my second suggestion.

Kind regards,
Erik

Hi michael.melgares,

I would like to reassign all comments & issues for the duplicate user to the real user and delete the old user, but this doesn't look to be possible at the moment?

That's right. However, it might be possible to workaround this to get your migration to JIRA to succeed.

Consequently, could you please create a support ticket at https://support.atlassian.com? That way we can provide you with support specific to your circumstances and with higher security.

The credentials should be the same as for this site (https://jira.atlassian.com).

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

I've found this to be an annoyance since (as far as I can tell) there is no way to reassign comments.

We've been using Trello and the Trello-Jira importer does a great job of moving all of the cards with comments, attachments etc... but now we have duplicate users (one in the internal directory that was created by the importer, and one in AD that we actually want to use). I would like to reassign all comments & issues for the duplicate user to the real user and delete the old user, but this doesn't look to be possible at the moment?

Ah my bad, I hadn't tried that, will check again today. Thank you!

If inactivate users did not count towards pricing then obviously that would be the best option since it would retain the proper history.

Hi sam26,
I just want to point out that this is actually the case.

When hosting you own JIRA instance (aka JIRA BTF), you can simply untick the "active" flag on a user to deactivate them, and they will no longer count towards your license limit.

When using On Demand, you instead have separate "Application Access" flags per product (JIRA, Confluence, Bamboo) and when you remove a user from the JIRA product, they no longer count toward the JIRA license limit.
https://yourinstance.jira.com/secure/admin/user/ApplicationAccessConfig!default.jspa

Just to add a user perspective (not sure if this is the correct place) but one of the key drivers is the ability to manage user accounts to keep the total number within the price bands. If inactivate users did not count towards pricing then obviously that would be the best option since it would retain the proper history.

The workaround for this issue (deactivate user) is not available to our OnDemand customers, so this fix has made deleting users next to impossible in that environment.

I am reopening this bug as the current behaviour is not acceptable and needs to be addressed somehow. Here are some options that are available to us:

• automatically delete the user's comments, or
• deactivate the user behind the scenes instead of deleting, or
• redirect the admin to the "Application Access" page, where she will be able to remove JIRA access (not as good).