how can i restore deleted jira tickets?

Hi,

Is it possible to restore deleted Jira tickets?

If yes, how?

Where can i find deleted Jira tickets in the database?

Is there a deleted flag or something like that?

BR

Markus

48 answers

1 accepted

This widget could not be displayed.

Unfotunately you can't. Deleted issues are gone.

The only option is to import a backup from previous days into a Test JIRA instance, find your issue and get its details. May be export it into Excel and import it - which will remove the change history.

Yup, deleted issues are completely deleted from the database. The only thing left behind is an empty number in the project sequencing.

That's a terrible software design flaw. Tickets are very important assets and accidents always happen. Every software developer knows what "logical delete" means... but apparently people at Atlassian are not familiar with this practice.

Not only you loose the ticket and its history but also every work log entries of time tracking.

It would be a great relief if this gets fixed in any future release.

It is not going to get "fixed" - there's no bug here.

By default, the permissions only allow the project administrators to delete, which I don't personally like, I think it should be completely disallows so that the request to allow delete has to go through a Jira Admin (who, if they're experienced enough, will be thoroughly aware that delete really does mean what it says, and hence say "no" a lot to the users who probably don't actually want it)

I understand that in some cases, it's too easy to delete things, so you have a wastebasket type function, but in this case, that's really not necessary, delete is hard to do and you really should mean it.

I agree that a "hard" delete might be a costly operation, but a "soft" delete is not.

Moreover, it's easy to implement as well, because it's just a flag on the tickets table to signal deleted/disabled tickets.

Anyway, thanks for letting me know that this is not going to happen.

This widget could not be displayed.
Joe Pitt Community Champion Jun 04, 2014

I think this topic has been beating to death. As far as Atlassian is concerned it is an enhancement, not a bug or design flaw. Put in an enhancement request and choose a work around from those suggested.

This widget could not be displayed.
Joe Pitt Community Champion Jun 03, 2014

Deleting issues from any tracking tool is an invitation from an auditor to call into question why and who approved it. It is the misssing minutes from the Nixon tape issue. A soft delete helps with the explanation, but it can still be raised as an issue. We have a resolution of Deleted. If you don't want them in the project, move them to a dead issue project with no update privilages for anyone except the person assigned to do that job.

This widget could not be displayed.

Jira takes backup daily in its home folder. You can use import utility to get issues back

This widget could not be displayed.

Nic, my intention was to go through each of your questions/coments one at a time to give them a fair chance. However, you argue for the sake of arguing and if you cannot win an argument with facts, you pile up more than one thing at a time and resort to verval diarrhea as to overwhelm. Well you win on that one. You may have J Caldwell, and Norman feeling sorry for you, I feel sorry too. Not for you but what J. Cadwell suggested, this argument is mostly a waste of time.

J. Cadwell, Nic has not just being explaning how the system works. He's being pretty much making false statements like soft deletes are a waste of time, they offer no benefit, they are hard or not easy to implement, and will cause bugs and/or undesirable behavior to users if implemented. All of this without proof or a background as a software developer to back him up. He only admitted that after I corner him. As I mention before you can restore pretty much anything on TRAC, ticktes reports, etc... So it is not just my opinion as you said. I know you all gaining on me, but I speak from the point of view of both a paying customer and also as a software developer.

This widget could not be displayed.

I think the work arounds are not acceptable. What meakes it worse is the attitude from you guys. Nic I think you need to take this less personally and admit the design flaw. We do not care to listen to excuses, we just want it fixed. This is the kind of problem which makes paying customers look elsewhere. You may be able to BS non developers, but implementing a soft delete is easy. There is absolutly no reason why deletes shouldn't be soft.

This widget could not be displayed.

And, what Joe said.

Hence my comment "remove delete permissions". You shouldn't have them in the first place if your users might misues them.

This widget could not be displayed.

I'm not involved in the design. I'm not taking it personally.

I just think soft deletes are a waste of time. Vast swathes of code because a human is not understanding the software well enough (in which case, those who do should remove the right for them to do it)

I don't think Jira warns the users or administrators enough that a delete is hard, and I'd actually fix it by removing delete from the permission schemes and moving it to an admin controlled option elsewhere.

As for "implementing a soft delete is easy" - I'm sorry, but you are wrong. You haven't thought it through at all.

How are you going to do it? Complete removal from the index or dropping it out of results? Rewriting the indexing processes so that deleted issues are not returned from searches? In the front end, re-use the security level stuff to hide the issue? How is REST going to handle it? How are you going to explain to your users that "your filter is slow because Jira is returning hundreds of soft-deleted issues and then hiding them"? There's a huge architectural design to be done here and I'm just flailing around with some ideas. And frankly, the best option is to, um, move them to another project the users can't see.

Finally, Jira "blue label" is going to include an element of archiving. It won't be soft-delete, it's aimed at larger installs with big blocks of data they don't really want in the main system, but want to keep for some reasons. That's likely to be the closest you'll get to it.

This widget could not be displayed.

First, if the name does not have the word "Atlassian" after it the person answering the question not from Atlassian.

Second when something is designed a certain way it is not a bug. It might be missing functionality, but it is not a bug because it was intentional decision. How do I know this, look at this Jira issue.

https://jira.atlassian.com/browse/JRA-21831?jql=project%20%3D%20JRA%20AND%20text%20~%20%22soft%20delete%22

Thirdly, there is no reason to insult anyone to make a point. Also, something that might be easy to implement is not a reason for implementing functionality.

Now, if you want to make your case add it to the above issue.

This widget could not be displayed.

Nic, implementing soft deletes would save you from so much aggravation and unhappy customers and from imposing weird pprocess to your customers to work-around this Jira limitation.

"Vast swathes of code because a human is not understanding the software well enough" Really, I don't think you should be allowed to write on behalf of Atlassian. If I was you boss, I would disipline you and if you didn't change I would fire you. Take this as a warning and learn because one day you may find yourself without a job becasue of comments liek this.

The problem is not that there isn't enough warning, or that users are stupid. Why should there be a warning? People do delete things by mistake, it happens. Don't fail to recognize that. The customer is not stupid for assuming deletes are soft because ticket data belongs to us not attlassian. Besides soft deletes are standard programming practice.

As for how to implement soft deletes, I belive Mariano already gave you the answer all you do is flag a ticket as deleted. You should not need to update any indexes. All other features that return tickets results such as seach simply filter these flagged tickets out from the results. The performance would not degrade because you would be returning exactly the same amount of records.

I do not think restoring deleted tickets from archives would solve the problem because what if, the user is not smart enough to archive before a delete? Besides, that would be an ugly work-around and process you would impose to your clients simply becasue you refuse to admit and fix this design flaw.

This widget could not be displayed.

Ok, so deleting tikets permanently is not a bug, it's just a non-documented feature.

If an Admin makes a mistake and deletes a ticket, Atlassian makes sure he/she will regret it and learn the lesson. That's 21st century software, good job.

This widget could not be displayed.

Norman, I can tell you are not a software designer. That is a design flaw and wheather or not they intended on making the mistake or not is irrelevant.

Thanks for the link by the way, but it does not prove anything other that, they made a mistake and now that it would require some effort on their part to fix it they don't want to do it.

I did not insult anyone... Also, I wasn't saying it's easy do it. I was however saying that it isn't as hard as Nic was suggesting it to be. It is actually easier to implemnent soft deletes than it is to implement hard one. They actually over engineer hard deletes. That may be why they don't want to throw away that useless code.

As for commenting on a close ticket, I think it would be pointless. I've rather voice my opinion here. I found this site on Google.

This widget could not be displayed.

<sigh> Please, before ranting, take the time to read the responses you've had. Especially Joe and Norman's replies, which are very useful.

I've worked with software for over 20 years. Soft deletes are a massive pain, despite what you'd like to think. To demonstrate just how you are failing to understand this, I'd like to pick up just one of your incorrect points.

"all you do is flag a ticket as deleted" (and the rest of that paragraph).

That is wrong. You're returning a swathe of unneeded results and then having to reprocess them more only to discard some. The index is designed to handle that, and it would be better to do it in the index, so "you wouldn't need to reindex" is now wrong.

Moving past the searches, you now need to start making the rest of the changes - how are you going to allow people to find issues if they can't see them in a search? What's the interface on to deleted issues? (There are several possible answers)

Now the core question - what USE are soft deletes for the humans? What advantage do they give you over simply disallowing deletes completely? "Oh, there's junk in my project". Fine - teach the users to think before putting junk in, or, allow them to delete if they're educated that it's a hard delete. There are no system advantages to soft delete, in fact, it's bad because you've then got "dark" data lying around taking up resources, and a load of complexity in handling them.

So, to go back to your suggest of a "deleted" flag. Remove "delete" rights from the projects as I've already said several times. Then add a custom field with a single check box in it, and tell your users to set it when they want to "delete" an issue, then tell them they can add "and deleted is empty" on every single search. Job done, and you don't need to make any code changes.

My point is that just repeating "oh it's simple" is not a useful thing to do. Stop ignoring the complexity, read the responses properly, and please, think it through.

This widget could not be displayed.

>I did not insult anyone...

Suggesting that I should be sacked for trying to gently point out that you are wrong is quite insulting. Screaming that something is broken and implying that people who are writing world-class software can't design software is

>Also, I wasn't saying it's easy do it.

Yes, you very clearly were saying it's easy, and you do it again with:

>I was however saying that it isn't as hard as Nic was suggesting it to be. It is actually easier to implemnent soft deletes than it is to implement hard one.

Hard delete - remove issue data from the assorted tables in the database it is in, and remove it from the index.

Soft delete - add data to say issue has been deleted and index that. Provide an interface to allow people to interact with the soft deletes. Work your way through the desired behaviour in the UI, REST and other interfaces, choosing to make the index more complex or the code more complex as desired. Scale for deleted data taking up resources. Document behaviour for users. Consider how to move from soft delete to hard delete.

It IS more complex to do soft delete than hard.

This widget could not be displayed.

Nic, filtering over a Boolena/Bit field is a trivial thing for any SQL engine. Even with millons of records, I've never experienced any index or performance issue. It's just an extra field and you can still assign the delete rights to a reduced number of users.

At this point I don't think you'll change your mind anyway, but other user should take this issue into account as other brands provide better user experience.

I'm starting to use Version One in other projects, a lot more mature software solution.

This widget could not be displayed.

Well, that's just showing that you don't understand that "it's just an extra field" really is not simple, but I think we've clearly established that you are not thinking it through properly.

It's not up to me to change my mind, I just use the software every day. Most of my users don't care about delete because I tend to remove it or educate them instead of demanding sweeping and unconsidered changes to software.

Good luck with version one - I wouldn't say "more mature" - you'll find it has a lot of limitations compared with Jira. But if it works well for your needs, go for it, always use the best tool for the job in hand.

This widget could not be displayed.

>There is no worse blind than that who refuses to see

Well, that sounds like a step forwards. You are admitting that you are refusing to see what I'm saying. Thank you.

This widget could not be displayed.

There is no worse blind than that who refuses to see

It just comes down to this, the data belongs to us the clients not Atlassian, and we should be able to undo a delete becasue mistakes happen.

If you cannot implement soft deletes you are not that "world class" are you? I have no insight into how this puppy is written so you may try to discredit me by critisizing my rough design, but what you can't tell me is that implementimg soft deletes is impossible. Are you saying that? It is standard software practice and many systems implement it even TRAC. Although they do not offecr a clean way to undo a delete, you can at least do it. I may go back to TRAC, you guys don't seem to get it.

This widget could not be displayed.

Well educate me Nic, how is implementing soft deletes through a flag difficult?

This widget could not be displayed.

Please, as I've said before, read the previous answers.

You've either got a lot of coding and design (and you keep ignoring all the questions I ask you about the details - it's no good saying "it's simple" when I keep pointing out that you aren't addressing why I'm telling you it's not), or you can do it in Jira with a custom field as I already pointed out.

This widget could not be displayed.

"all you do is flag a ticket as deleted" (and the rest of that paragraph).

That is wrong. You're returning a swathe of unneeded results and then having to reprocess them more only to discard some. The index is designed to handle that, and it would be better to do it in the index, so "you wouldn't need to reindex" is now wrong.

I guess this were serious questions. No you wouldn't, you should not get any more records than if you did a hard delete because you would update the search query WHERE CLAUSE to say something like "and deleted <> 1".

What are you doing to the index now with your hard deletes? and how would it change if you were to implement soft deletes?

This widget could not be displayed.

Ah, finally, you've bothered to read one of the complexitities you've been ignoring.

Now, where do you want to code for that clause you want to add? If you do it in the index, then you'll never be able to search for your soft-deletes. If you do it in the search code, you're adding work to the search at execution time, and you're still not able to search for the deleted issues flexibly. So you move it up again, and you'll have to rewrite a load of disparate searches in Jira to include the clause as required, and you now have to start thinking about all the places you don't want to do it and how to represent that to the users, and how to handle it when they want to search for them. Now move on to the UI - what do you actually want to DO with deleted issues?

On your specific questions, yet again, you haven't bothered to read my response. Look for my comment that says what you'd need to do with hard and soft deletes. You can spot it because "hard delete" is one sentence. "Soft delete" is a paragraph (and it's missing a lot)

You just keep saying "oh it's simple" and then not grasping that it really is NOT simple because you're ignoring the desigin, implementation and how it's going to work for users and admins.

This widget could not be displayed.

You have no prove it being difficult...

Are you serious? You should not have any execution time penalty mostly becasue you will be returning the same number of rows. If you think you will please prove it. Becasue I am getting bored of blank statements such as "you're adding work to the search...".

In regards to "you'll have to rewrite a load of disparate searches in Jira to include the clause as required" so? That is called refactoring also a standard practice. "you now have to start thinking about all the places you don't want to do it" Wait, you are getting ahead of yourself, that would not be concern now would it be? That could however become a new feature for Jira.

So this translate into you got nothing, you got 20 year of what writing hello world programs?

This widget could not be displayed.

No, I've got 20 years of watching people grasp complexity, design, interaction and how humans actually interact with computers.

I ask you again, to re-read all of the complexities, not just pick up on one that you think you've got an answer for. Yelling "it's simple" at me and then ignoring every point I make about the complexities that prove you wrong is just proving that you don't understand software engineering in the slightest.

Your suggested implementation falls apart as soon as you look at it in any detail. Please propose a "simple" way to fix that.

This widget could not be displayed.

No, I've got 20 years of watching people grasp complexity, design, interaction and how humans actually interact with computers. I don't think you're doing that at all.

I ask you again, to re-read all of the complexities, not just pick up on one that you think you've got an answer for (which you haven't thought through the implications of). Yelling "it's simple" at me and then ignoring every point I make about the complexities that prove you wrong is just showing that you don't really understand software or how to build it.

Your suggested implementation falls apart as soon as you look at it in any detail. I've repeatedly pointed out holes in "a simple flag" which you keep ignoring. Please re-read, and propose a "simple" way to fix them.

(Edited to hopefully make it a bit less grumpy and a bit more clearly laid out)

This widget could not be displayed.

> Norman, I can tell you are not a software designer. That is a design flaw and wheather or not they intended on making the mistake or not is irrelevant.

You have no idea of what my background is over my 36+ years in the sofware business. You have insulted Nic (whom I do not know other than his expertise provided on this forum) and you have insulted me. You cannot say you did not insult me because that IS how I feel. Making an argument by trying to shame a person does not bolster your case, it demeans it.


> Thanks for the link by the way, but it does not prove anything other that, they made a mistake and now that it would require some effort on their part to fix it they don't want to do it.
...
As for commenting on a close ticket, I think it would be pointless.

If you took the time look at the issue I pointed you to, the issue is NOT closed, it is resolved. Look at the workflow. I assume you know the difference. If you do not want to make your case, that issue still proves Atlassian did consider soft deletes and decided against it. Atlassian made their value judgement which disagrees with yours.

The place to make your case is in that issue or a new issue if you want. It is not this forum, since Atlassian does not track feature or bug requests from this forum.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted yesterday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

72 views 1 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you