Is there any risk to deleting users in JIRA Cloud?

[DJX]

In the past, I recall you could not delete a user if they were an assignee, watcher, reporter, voter, commenter, etc. on any issue.

Is this still the case in the cloud? I have split JIRA Instances and migrated a few projects to the cloud. I have a massive number of users (3,000+) and I only have 12 active users for these projects. It's possible that some of the 3,000 users were reporters to very old issues in these projects.

In the cloud, when I go to delete a person it briefly shows "verifying the user can be deleted", and then gives me a message saying:

You are about to delete aaa. This can't be undone.

Your products will keep all of aaa's contributions. If you create a new user with the same username, these contributions will be associated with them

This seems clear enough to me... All the tasks, comments, etc. from this user will remain in the system - and if I ever create a user with the same name in the cloud, they would then be mapped to all this previous work. This works great, and I've tested it, for creating my 12 users in the cloud and having them re-mapped to the previous issues.

Can anyone confirm my understanding of what happens if I delete these users?

At this point, I want to delete all but my 12 users and only re-create other users in the future as necessary.

[DJX]

Thanks to the support team, this has been done

[Robert Massaioli _Atlassian_]

As somebody that works at Atlassian and worked on the "User Management" team: just deactivate your users. There is pretty much no good reason to delete a user unless you have just created them and that creation was a mistake.

If you have a user that has done literally anything in the system then just deactivate them: it's a much better option and well supported by the products. That is why we made it the default action.

[DJX]

The system I extracted the project from is about 10 years old. It accumulated over 3,000 users. There is no reason for our current administrators to need to sort through 3,000 (deactivated) users when browsing in the user list for the 11 active users in the projects I split out. Yes, I know they can search; but this seems like ignoring the problem instead of fixing it.

I am not sure which of these 3,000 users have performed tasks (watched, commented, voted, etc.) on the projects that remain in the system. And because I don't have access to the back-end database, I don't have an easy way to find out.

This is why I'm curious if I can just delete the users and rest assured that all historical data will remain intact, even if the user that performed the action is no longer present.

[Robert Massaioli _Atlassian_]

Deactivated users should be hidden (by default) everywhere. Where were they visible to you?

[DJX]

They are visible in the admin page. It seems it's down to a difference of opinion in how to handle old users. I agree with leaving them in for the short term, but at some point ( a few years? ) I think there are valid (responsible) reasons to delete old users who are no longer with the company.

[Nic Brough -Adaptavist-]

The problem with deleting them is that it destroys the information on who did things.  JIRA looks for a user object when looking at the history, and deleted users cause it to fail, and just show their old login id (and often, errors in the log).  Whilst sometimes this isn't much of a problem, it certainly is for legal regulation (it's downright illegal to destroy user-tracking information in certain financial and defense sectors for example), and a lot of code that looks at the history can struggle when it can't find the users.

[DJX]

@Nic Brough [Adaptavist], it can also be illegal to divulge employment history. An admin simply seeing a user's name in the system gives them an indication that they used to work there. I think the requirements for things like SOX regulations go outside the scope of "what does JIRA store for history" and is more of a server/DB admin's job to make sure all the data is retained in a full snapshot.

Outside of legal considerations, some customers are IP sensitive, and they consider contact lists very sensitive. Handing an admin 3,000 people who once worked on a highly confidential customer's project is a pretty bad idea. This is a perfect way for someone to send a phishing e-mail to these employees, and I don't want to be the admin who is responsible for handing that over to any of my fellow admins as I decommission the existing system.

Your answer is perfect though - it will just show the user name. And if I really wanted to show the names at a later time, I could just re-create (and deactivate) the users and it will populate the names. Thank you very much for your comment -  turn it into an answer and I'll pick it! :)

As an aside, it comes down to what is the intended use of the system. If JIRA was staying "JIRA" and didn't just branch out into "JIRA Core" for Business-type projects, it would make sense to not worry about these things.

I just made the move from Server to Cloud and it is quite clear that there is a very specific market (which I appear to not be a part of) they're targeting for this platform, and there doesn't seem to be much interest to extend further at the moment.

[Nic Brough -Adaptavist-]

Divulging an employment history is a different thing to destroying information, but it is something admins often need to be fully aware of.  And it makes real life messy (JIRA wants the accounts simply to avoid having data holes.  It's not a lawyer or a regulator )

[Andrea Carl]

Why not just deactivate?