Delete a user with issue comments (once again)

[Karim Saaq]

Hi,

This question has been asked many times in other threads but nobody care to provide a real answer.

So, How can users with issue comments be deleted?

Alternatives, such as Revoking Application Access are not an acceptable for us as it leaves too many traces of the users names into the system.

If there is no answer and this is a limitation of JIRA please just let us know.

Many thanks,

KS

[Earl McCutcheon]

One point I have not seen addressed on this thread I thought needed to be noted is that Jira is an issue tracking system designed to preserve history, so deleting users with history would circumvent some of the base functionality or the system.

[Nic Brough -Adaptavist-]

Ah, ok, the other day I ran into this again, and I need to change my stock response.

In Jira 6.1, Atlassian have fixed a bug. Before 6.1, only reporter or assignee would block removal of a user. That has now been extended to include users who have commented on an issue.

So, now, I'm afraid you only have three options:

• Do nothing - Do not remove them, as that breaks too many things
• SQL hacking (not possible on OnDemand)
• Rename the users to something that doesn't expose the data you want to hide and remove them from all groups and roles.

[Karim Saaq]

Many thanks for the answer Nic.

Unfortunately JIRA will not let us delete the users. We get the following:

"Cannot delete user. XXX has associations in JIRA that cannot be removed automatically."

"Change the following and try again: Issue Comments: 13"

But it's not possible to unlink comments...

Thanks,

MT

[Dave]

Yes, best practice is generally to deactivate and not delete the user to preserve the history. https://confluence.atlassian.com/display/AOD/Deleting+or+Deactivating+JIRA+Users

[Karim Saaq]

Thanks for the answer Nic.

In JIRA the username cannot be changed. (https://confluence.atlassian.com/pages/viewpage.action?pageId=298979005)

Anyways, I renamed the Full Name and deassociated it from all groups but it still show-up in Confluence People Directory... in what appear to be its original alphabetical position, maybe it's the username position.

In any case, as the company grows, the People Directory would end-up filled with renamed departed employees here and there. That does'nt work either.

No need to answer. I give up.

MT

[Paul DeSousa]

So are deactivated users counted against our user total? We are rubbing up our 500 user license and JIRA tried to create a new ID though there was already an LDAP AD user with that same id. Now I have two users with the same email and so finding out which comment belongs to the duplicate is almost impossible, and for cleanlyness purposes I would really like to get rid of the duplicate user. Any recommendations of SQL commands or something I can use to find these duplicate bogus ids?

[Nic Brough -Adaptavist-]

Rename one of them with something obvious in the display name, then you'll be able to see the difference

[Paul DeSousa]

I tried. I think the problem is I am searching inside the comment and not who posted it with the "comment ~ userid" So for robertn I would change to robertnZZZZ and so a "comment ~ robertnZZZZ" and get no results. Yet when I try to remove robertnZZZZ I get cannot as there is 1 comment associated with that id. and thoughts, then I have to get back to why JIRA is creating a duplicate id when anyone sends in a message (right now all emails get the default ID for Reporter instead of creating a unique ID but that still is not good)

[Nic Brough -Adaptavist-]

Ah, right, yes, that could be "fun"

I think your best bet is exactly what you thought - SQL. As it's just a comment, it's not easy in the UI, but the comments are reasonably easy.

Select * from jiraaction where author = 'brokenuser' ;

That should give you an issueid to refer to in jiraissue, and hence you'll be able to edit the issue and delete the comment. Or, if you need it, stop Jira, change the author of the comment with SQL, restart Jira, go back to the issue and comment again or something to force it to re-index, then try the user delete again.

[Nic Brough -Adaptavist-]

Bother, I was afraid of that. Your database is ok, but I suspect your index is not.

Is it possible to schedule a full re-index? The one that locks the users out and rebuilds the whole lot from scratch? As there's no broken-robert in the database, it sounds like the "can I kill the user" check is running into a hanging index record...

[Paul DeSousa]

I was afraid of that. SQL is something I really want to learn more. I get zero rows return with the above. And here is another search statement (I tried yours as well with brokenuser replaced with everything close to robertnZZZZ@comsol.com:

SELECT AUTHOR

FROM `jira`.`jiraaction` where AUTHOR LIKE 'robertnZ%%%%%%%%%%%%%%%';

which gives 0 results as does 'robertnZZZZ@comsol.com'

Here is my error:

Cannot delete user. 'robertnZZZZ@comsol.com' has associations in JIRA that cannot be removed automatically.

Change the following and try again:

• Issue Comments: 1

[Paul DeSousa]

Yep, the first thing I did was a complete reindex, still no luck. I also noticed when doing a manual inspection of every row in the jiraaction table that there are several with an Author of "null" I wonder if it is dying on one of those, and non with the ZZZZ. Well I guess I can deactivate the user but I really do not like to leave bogus users in my instance.

[Nic Brough -Adaptavist-]

I think the nulls are when someone has allowed anonymous access and someone has commented without needing to log in. But I'm not sure.

I'm really not sure where it might be getting those comments from though.

Oops - a thought, do you use time tracking? I just had a sudden thought that maybe they've logged time with a comment, which goes on to the work log tables, not jiraaction (I think...)

[Paul DeSousa]

Yeah, no I tried to search the entire database for ZZZZ and only got the audit and cwd_user which means that just changing the user's ID does not go back through the database and change the comment to the new user name even with a re-index. That is too bad, and almost sounds like a bug to me...

[Portland Girl]

I manage JIRA for a small development team and use the 10-user license version. This is a big problem for us. We will need to go the SQL hack route.

[Nic Brough -Adaptavist-]

There are 18 different places you will need to check and possibly update with SQL. Remember that you'll need Jira offline and backed up before you toouch the database.

If you're potentially working in financial systems in the EU, you should to check with your financial regulator body to check that destroying tracking information is legal (generally, it's not).

It is far more simple to deactivate users

[Joe Pitt]

As stated, deleting the user breaks JIRA in that the comments are stored with a pointer to the userid that made them, not the user name. Now you have a comment with a broken pointer that causes an SQL error when viewing the comments. It may be possible to find all the deactivated users and change the email associated with them to all be name@deactivated.comso you won't get the problem.

[Nic Brough -Adaptavist-]

You don't even need to "deactivate" them. Remove them from all groups and roles, change their email address to a dummy one, and that will prevent all of the problems above (including the massive one that deleting users who have done stuff in your system destroys information and hence you really shouldn't be deleting them anyway). I'd also recommend changing the display name too, add (inactive user) to the end or something.

[Joe Pitt]

just remove the id from the logon group(s) and it won't count against the license. Simple solution. no hacks

[Portland Girl]

Thanks for the tip Joe!

[Phil Musterman]

This so called "bug fix" has created a much larger one for our company. Now because of comments I cannot delete a user. I am left to only "deactivation" but deactivation also blocks all email processing from the email address associated with the account. This is a major issue in the case of users migrated from one directory to another.

Take our case for example:

Originally, we managed all of our Jira users internally to Jira. After more and more company entities joined our Jira Server the decision was made to migrate user control to Active Directory via LDAP. This was done and as a result every user currently in our Active Directory that also existed in the internal jira directory has two accounts within Jira: One in the Internal Directory and one in the LDAP A.D. Directory.

The recommended step of "deactivating" the old internal Jira user accounts was taken but because those accounts still exist with THE SAME EMAIL ADDRESS as their new LDAP Active Directory accounts, all emails sent in by such users are ignored by JIRA!

The only resolution to OUR MAJOR BUSINESS-BLOCKING ISSUE is to delete the users but that can't be done because of comments!!!

So, YES, you fixed a bug! Congratulations! But you also created a much larger one!

Now what will you do?

Either:

A) Fix the critical issue with a deactivated Jira account blocking all email processing on the associated email address even when an active Jira account exists with that same email address.

OR

B) Offer the ability to delete a user even if they have comments. Would it not have been just as easy to program in an extra promp to ask if they want to delete the user account anyway even if they have comments? That way an admin can actually make the decision on whther they're more concerned with "history" or user account integrity/management. I ask if this change would have been just as easy halfheartedly because I know for a fact it would be easy since I am a software developer by career.

Simply add in a prompt that states: "Such and such user has X comments. Deleting this user account will remove all user historical information tied to those comments and issues. Do you still wish to delete this user?"

Highly burdened and frustrated,

Phil Musterman

CG Power Systems USA

[Jeff Lew]

How about adding the ability to deactivate users so they do not appear in the menus? They could still be accessed through a View Deactived Users option. Deactivated users would also be automatically excluded from the user license count.

[vkharisma]

Hi Karim,

I do agree with you that its impossible to remove a user that has comments.

EDIT: this is by design. Here is a feature request to search comments by user so that you can delete the comments if you'd like, it's old but is more relevant now that we've fixed the bug that allowed you to delete users with comments

https://jira.atlassian.com/browse/JRA-1648

You may share your thought there and add yourself as a watcher to get notify for any update on that.

Cheers

[Nic Brough -Adaptavist-]

You delete them

It's only assignee, reporter and project lead that prevents deletion of a user. Reassign the issues, change the reporter and remove the users from project leads and you're good to delete them.

Of course, there's consequent damage to your issue history (comments etc) because you've only got a login string and no actual user information, but that's the point of revocation instead of deletion - you want to keep your information. It's not a "limitation", it's preventing loss of information you probably need.