how can i restore deleted jira tickets?

[Miguel Ulloa]

Norman, Nic, you guys think that becasue you got all those years of experience people should just be intimidated and take your bull shit, you are wrong. I will not, becasue that insults my intelligence. Norman, I do realize you are right about this though "shame a person does not bolster your case, it demeans it". I only did it becasue he ask for it. All i did is answer his question.

Nic, you have proven that you do not know what are you talking about. I know you have a big ego but you really need to be more humble.

[Nic Brough -Adaptavist-]

>It is easy Nic :D

>All you do is add a flag, refactor the delete operation to set it to 1, and refactor all queries which return Jira issues, that's it.

And hence, completely fail to provide a usable system. You have not thought through the implications of doing this to the end user, the internals or even why it's of any benefit. This flag on it's own, a) breaks things and b) does nothing of any use whatsoever.

Where's the rest of your analysis?

>I do refactoring like this all the time.

Could I ask what software you work on please? I really do need to avoid it.

>What would have been easier if this design flaw was identified early on then you wouldn't be saying non sence and me proving you wong.

It's not a design flaw. It's a choice to keep deletion functions simple and intuitive and not have to do all the extra coding required to handle all the extra facilities around soft-deletes that 99% of the users of the software won't care about or use.

[Miguel Ulloa]

It is easy Nic :D

All you do is add a flag, refactor the delete operation to set it to 1, and refactor all queries which return Jira issues, that's it. I do refactoring like this all the time. What would have been easier if this design flaw was identified early on then you wouldn't be saying non sence and me proving you wong.

[Norman Abramovitz]

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

[Nic Brough -Adaptavist-]

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)

[Nic Brough -Adaptavist-]

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.

[Miguel Ulloa]

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?

[Nic Brough -Adaptavist-]

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.

[Miguel Ulloa]

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

[Nic Brough -Adaptavist-]

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.

[Miguel Ulloa]

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

[Miguel Ulloa]

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.

[Nic Brough -Adaptavist-]

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

[Nic Brough -Adaptavist-]

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.

[Mariano Mazzieri]

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.

[Nic Brough -Adaptavist-]

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

[Nic Brough -Adaptavist-]

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

[Miguel Ulloa]

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.

[Mariano Mazzieri]

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.

[Miguel Ulloa]

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.

[Norman Abramovitz]

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.

[Nic Brough -Adaptavist-]

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.