how can i restore deleted jira tickets?

[Markus Weberberger]

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

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

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.

[Nic Brough -Adaptavist-]

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

[Mariano Mazzieri]

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.

[Nic Brough -Adaptavist-]

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.

[Mariano Mazzieri]

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.

[Joe Pitt]

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.

[Joe Pitt]

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.

[Nic Brough -Adaptavist-]

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.

[Miguel Ulloa]

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.

[Ahmed_Bilal]

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

[Victor Vucicevich]

The administrator of my board deleted a very important ticket while I was away on vacation. He did so because in my absence he ran our backlog grooming and assumed the ticket was a duplicate of another in a different board due to a similar title. 

I return only to see that the descriptive and in depth ticket for an important feature I created, including discussions, designs, and other important information has been deleted. 

It was an honest mistake. 

Then, I learn that Jira does not have an _archive_ or _restore_ functionality. It is simply completely gone off the face of the planet. A rather infuriating situation to be sure. So I come to the boards to make the complaint and lo and behold, once again Nic is there to vehemently defend and infurating piece of jira. Truly the Kellyanne Conway of the Atlassian community. 

Now that I've gone through the boards enough, I realized that the defenseman Nic Brough may actually be the reason  Jira product improvement moves at such a snails pace. He exists solely to prevent genuine complaints and feature requests from ever reaching the Jira product/engineering team. Anything that would be difficult to build or fix gets swept under the rug as a "mistake in your process" or "not a bug".

The ability to restore a deleted ticket should be a basic one. Sure, storage costs money, so how about this: 

1. When deleted, mark as deleted. 
2. If marked as deleted, remove from the Jira interface but don't delete fully.
3. After a set amount of time, maybe 2-3 weeks, _then_ actually delete the issue. 

Quick notes:

* When deleting an issue, on the acknowledge step inform the user that it will still be accessible for X amount of time before it is gone forever

* Users can navigate to the issue by direct URL still

* Don't even need to implement a "read only" version of the issue when its  because its 

* Add a new default field that isn't really configurable called DELETED

* When an issue is "deleted", it wont show up in _any_ board unless the JQL of `DELETED = true` is in the filter

* Add a "Restore" button in place of the "Delete" button when on the actual issue view if you've navigated to it. 

There you go. Don't need to create an "archive" feature. Don't need to change the interface. Don't need to change _much_ really.

You'll save thousands of users from headaches every year without implementing anything majorly cost-inducing on your end for the cloud environments 

[Nic Brough -Adaptavist-]

Please read the previous comments before.

You have made most of the same incorrect assumptions and mistakes as the others before.

[Victor Vucicevich]

Nic, your responses have not actually covered any real explanation, as the other comments have pointed out.

The notion that soft deletes are complicated is entirely incorrect. Maybe 20 years ago when you began in this industry this may have been true, but as of right now it is an industry standard. 

I'm sorry to hop on this chain four years after it last got brought up, but as this ticket ages, so too does the current paradigm in place within Jira.

I feel as though after eight years it might be worth re-looking into this. 

https://jira.atlassian.com/browse/JRASERVER-21831

Maybe once, just once, you could help the community out Nic. It would seem as though you get paid more for letting less feature requests make it through to the actual team that builds Jira (if they do really exist). 

[Joe Pitt]

Nic isn't an Atlassian employee. This has been an issue all along and I doubt it will change. Nic, like me, are only telling it like it is and the issues that come up when you delete issues. It doesn't mean anyone likes the issue. However, deleting data from what should be a system of record isn't smart in my book. But I understand not everyone agrees. 

[Victor Vucicevich]

There is absolutely no way Nic is not on the Atlassian payroll. He is on every single community discussion kicking the ball down the line, telling us "its a feature, not a bug", simply ignoring real discussion. 

He either has one extremely strange hobby, or he's getting paid behind the scenes to keep the community from submitting real tickets. Nobody has ever been this passionate about anything since kids on community forums during the first console flame wars. 

I'm going to keep pushing, because as far as an industry standard goes, Jira is way off base on this one. 

[Nic Brough -Adaptavist-]

Well, I'm afraid that's vastly wrong. 

• I do not work for Atlassian.  if I did, you'd see less opinionated stuff, a lot less criticism, and longer more detailed answers as I reigned in my "<sigh> RTFM / LMGTFY" instincts more.   And I'd be booted off the community for lying about my employer.
• I rarely "kick the ball down the line".  I try to explain why it is like it is, and why a lot of the assumptions people make are incorrect, and why things are unlikely to change or get done, especially when they are minor points with work-arounds that only affect a few people. 
• I do nothing (and indeed, can't do anything, as I'm not an employee) to stop you raising whatever you want.  I try to help in some cases, even when it's stuff I've got no interest in.
• I'm not passionate about a lot of the subjects.  I do get annoyed that people do not read the previous discussions.

You are right on:

• The strange hobby.
• The desire to keep pushing - please do.  A soft delete would be good.  There's a couple of thousand other requests that are vastly more important and need fixing (unlike this one, which I always fix with @Joe Pitt 's methods), but my priorities are different.

[ajbdev]

If it isn't obvious enough by the many, many threads that appear on the google search results page for this exact topic, people delete things accidentally. It happens. That doesn't mean you should treat employees like children and take away permissions and by the time most people read this thread the 20/20 hindsight recommendations that are given here no longer matter. Soft delete is a well established design and implemented quite successfully in tons of other software (gmail comes to mind, or any other software that may track things that require auditing). How the merit of soft delete is being debated here is completely beyond me and hopefully someone from Atlassian comes to their senses when they see the frustration this is creating for customers.

[Steve Sweales]

Just like to add my 2 cents. =) 1. Irrespective of whether soft deletes are easy or hard to implement, they are effectively an industry standard - fact. 2. Atlassian do believe in soft deletes. Look at Confluence - when you delete a page, it goes to the trash bin, where you can recover it if required. I love Atlasssian products and use many of them (am a massive advocate), however there are elements in each of the tools that drive me nuts as there is what I would call 'basic' functionality that I would expect to be there, that is not implemented. Additionally there is often inconsistency across Atlassian's products i.e. soft delete and gravatar implementation to name but two.

[Nic Brough -Adaptavist-]

Once you strip the insults out of that comment, there's nothing there to demonstrate that you have thought through your design, which is where you have always been wrong. Please get back to me when you have

[Miguel Ulloa]

The questions you asked shows that you are not even a programmer which is fine, but stop talking authoritatively about software design and development, you aren't one. You whole insistance in soft deletes being difficult and/or problematic also proves it. BTW, I use soft deletes, but I didn't invented them so stop talking about them as if they were my crazy idea. Mariano Mazzieri suggested them way before I did. They are an industry standard wheather you admit it or not. Lastly, if you finally stop engaging me is becasue you realize, you are not going to get anywhere with me becasue despite your hurt feelings you know I am right. Lastly, I won't comply to your request, I think you should learn on your own there are plenty of resources on the Web.

[Nic Brough -Adaptavist-]

Again, you prove that you are not reading what has been said. "A few trivial code tweaks" as you've suggested before simply breaks it because you have not thought through the impact of what you are doing.

You've been told why they won't cut it, and you ignore it.

I'm not going to engage with you further until you can demonstrate that you have thought through your design in terms of how the user will see it and what use it is if implemented they way you have suggested/ Address the points raised or you're just wasting your time. Be nice if you could explain what is wrong with the two standard non-coding workarounds you've been given as well.

[Miguel Ulloa]

Nic, seriously, closing points? Do you promise? I don't think you can, and don't be silly, you can't cover the sun with your finger. The best damage control you can do is NOT to make questions/remarks such as these.

"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."

You making me look mean Nic, but these are your own words Mr. "I've worked with software for over 20 years."

[Miguel Ulloa]

J. Cadwell, he said "although the cynical side of my mind suggests that he did read it, and realised that it proved that making a few code tweaks are not going to cut it", I was saying that he was right about me reading them, but wrong about me changing my mind about soft deletes, I know they are easy to implement. He even agrees with me here, it is a few trivial code tweaks.

[Miguel Ulloa]

Nic, how did I know, you had to have the last word? You are right, I did read yours and many other suggestions. In fact, this was the third site I came across with the same topic so I wasn't so much igoning the suggestions, I just think they are ugly hacks. In fact my first sentence was "I think the work arounds are not acceptable". I think that clearly expressed my feeling regarding these work-arounds perhaps you missed it. I feel this is a DESIGN FLAW and it should be corrected becasue this kind of issue makes customers very angry. Those of us who create and use systems with soft deletes know that Atlassian can have a differece of opinion, but they don't get to make their own TRUTH and call this an enhacement so you are WRONG about that

[Miguel Ulloa]

Nic, how did I know, you had to have the last word? You are right, I did read yours and many other suggestions. In fact, this was the third site I came across with the same topic so I wasn't so much igoning the suggestions, I just think they are ugly hacks. In fact my first sentence was "I think the work arounds are not acceptable". I think that clearly expressed my feeling regarding these work-arounds perhaps you missed it. I feel this is a DESIGN FLAW and it should be corrected becasue this kind of issue makes customers very angry. Those of us who create and use systems with soft deletes know that Atlassian can have a differece of opinion, but they don't get to make their own TRUTH and call this an enhacement so you are WRONG about that

[Miguel Ulloa]

Nic, how did I know, you had to have the last word? You are right, I did read yours and many other suggestions. In fact, this was the third site I came across with the same topic so I wasn't so much igoning the suggestions, I just think they are ugly hacks. In fact my first sentence was "I think the work arounds are not acceptable". I think that clearly expressed my feeling regarding these work-arounds perhaps you missed it. I feel this is a DESIGN FLAW and it should be corrected becasue this kind of issue makes customers very angry. Those of us who create and use systems with soft deletes know that Atlassian can have a differece of opinion, but they don't get to make their own TRUTH and call this an enhacement so you are WRONG about that

[Nic Brough -Adaptavist-]

It's not about the last word for me, it's about your misconceptions. I just don't want someone else to think "it's simple" when it is not.

I'll keep my closing points simple:

1. You've been offered two workarounds - you've ignored both of them.

2. Your statement that soft deletes are simple is still wrong. I've pointed at many issues with the concept (as you'd have to implement it in Jira) and you have not countered a single one of them with anything other than ignoring them or just insulting me.

3. We differ in our opinion that soft deletes are a good idea. That's ok. You've offered nothing to support yours, and I've only said a little to support mine, we've not actually explored it very much.

4. J Caldwell, yet again, is a voice of reason. I've no more voice at Atlassian than you do, and it's entirely their decision. ( I agree with their stance on this one, for reasons I'm not going to repeat as they're documented above for you to ignore again, and on the linked issue mentioned)

I'd suggest we agree to differ on point 3, you take up point 4 with Atlassian, and you give up on 1 and 2 unless you come up with a simple design that gets around the complexities I keep asking about (and, for the last time, just saying "It's easy" is not enough)

[J. Caldwell]

Actually...if you want Atlassian to take your suggestion, you are going to have to submit an enhancment request. He isn't wrong about that...it's how their process works.

[Miguel Ulloa]

Nic, how did I know, you had to have the last word? You are right, I did read yours and many other suggestions. In fact, this was the third site I came across with the same topic so I wasn't so much igoning the suggestions, I just think they are ugly hacks. In fact my first sentence was "I think the work arounds are not acceptable". I think that clearly expressed my feeling regarding these work-arounds perhaps you missed it. I feel this is a DESIGN FLAW and it should be corrected becasue this kind of issue makes customers very angry. Those of us who create and use systems with soft deletes know that Atlassian can have a differece of opinion, but they don't get to make their own TRUTH and call this an enhacement so you are WRONG about that.

[Nic Brough -Adaptavist-]

I think you are running into the same problem. Just because you think it should be trivial does not mean it is. Soft deletes are always more complex than hard, and jira is no exception. Yes, my opinion is that they are usually a waste of time, I have yet to have heard a coherent argument that would favour soft deletes over "don't let the user delete at all, just restrict it". If you have one, I'd be interested. I also gave a method to implement a flag in jira with zero code change, but as Miguel chooses to ignore what he's being told, he missed it (although the cynical side of my mind suggests that he did read it, and realised that it proved that making a few code tweaks are not going to cut it)

[Mariano Mazzieri]

Dude, of course there are implications: it's a design flaw. Those are always harder to fix than bugs. However, in this case the implications should be a series of trivial changes in code (unless Jira's architecture is a terrible mess) not the end of the world as you described it.

Whether you like it or not, as Miguel said, soft deletes are a broadly known industry standard. But in your opiniopn it's a waste of time -perhaps you don't get it or you are simply not willing to give in.

By the way, I can't unsubscribe from this question -that's a bug.

[Nic Brough -Adaptavist-]

No. I'm not arguing for the sake of arguing. I am pointing out that you can't just say "it's simple" when it is not.

You repeatedly refuse to read the responses and answer the questions, because you don't want to admit that you have not thought through the implications of your specification.

"soft deletes are a waste of time" is, indeed, an opinion, based on experience with Jira and other pieces of software. When I've asked you to explain why my opinion is wrong, you haven't bothered, you've simply insulted me.

I have not admitted I am wrong at any point or backtracked. I'm still waiting for a valid argument as to why I'm wrong. On any of the points I've raised.

[Miguel Ulloa]

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.

[J. Caldwell]

So I've watch this...and I've got to say this...I would trust Nic with any of my Atlassian instances any day of the week and twice on Sunday. He has been infinately useful to many folks here as have Jobin, Norman and others.

I also think folks need to calm down a bit. This is largely a religious debate now and clearly Miguel thinks he's right and others do not agree with his statements. The question has been answered.

On another note...Miguel...I do think your responses have been out of line. You've been treating other folks who have replied as if they are doing things wrong and are incompetant because of it. They have been explaining how the system works. The problem is the application doesn't work in the way you think it should and if you think it should work in a different way, by all means, raise an enhancement request.

If you don't want things deleted, don't let people delete things. It is that simple.

[Nic Brough -Adaptavist-]

No, I'm not trying to intimidate you, I'm trying to point out that you are not thinking things through, and you are not bothering to read or understand what youare being told.

You did not answer any of my questions or come up with anything to show I any understanding of the points. You refuse to explain whay you're not talking about the huge holes in your assumption that "it's simple"

I'm not asking for insults, I'm asking for you to read and think. Resorting to insults when asked to do so just tells me that you've simply realised that you are wrong but don't want to admit it.

I'm still trying not to rise to the insults. I would therefore humbly ask you to READ what you've been told, demonstrate that you understand it, and then explain why you think it's wrong?