Mark for deletion


i can prevent that a user can delete an issue.

In our system it is not allowed to delete issues. This was a requirement of some public accountants.

In the old days (JIRA 4) i make a new status and modify all reports to ignore the status.

Now i don't want to modify the sources but with only 3 categories fo status it is a problem.

The new delete status is not of the category "todo", "in progress" or "done" it is far away from this.


Is there another way to not really delete issues?



4 answers

I don't really get it. "Deleted" seems to be a final status. Doesn't matter if the category is called done. You don't even see this in the UI. Make it green and you're "done" wink 

Other than this, you could hide the issues by applying a security level. 


Yes, but

  • if you look at how many issues you have resolved you get a wrong result.
  • If you show your done issues in the navigator you has allways the "deleted" ones

I also thought about to set the security level to hide the "deleted" issues

"if you look at how many issues you have resolved you get a wrong result"- not really. Filters are either based on statuses or resolutions. So you got two options: A - don't set a resolution when you transition to the "Deleted" status - B - add sth. like AND status != Deleted to your queries to filter out the "deleted" issues Or do as Nic says. Move them to another project

Oh, and if you use an issue security level, the users will see graphs based on numbers that look like the issue has been deleted too - the issues really are totally hidden.

0 votes

Another option I've used in the past is to set up a project that has all issue types and all fields available in it, and move the issues over to it instead of "delete".  Hide it from all but the admins if you want.   You'll lose versions and components during the move, and it'll still look like there are holes in the sprint reports in Agile, but it'll do the trick.

Thanks Christian and Nick for the answers.

I guess i will give it a try to hide the issues with a security level.

Btw. B - add sth. like AND status != Deleted to your queries to filter out the "deleted" issues
This can only work if i use own filter but sadly not in all other reports, plugins, ...

But how can i do this? If one has the possibility to see the securitylevel then he can see the issue further. I am not the only person who can "delete" issues.
Well, if i hide the delete-menu-entry and make a new entry with a user who can set the security-level then it will work (i guess)

Damn it didn't work sad

The idea with the security level was good and i am finished with my plugin.

Now as i test the funktion i was wondering why on some issues the securitylevel didn't changed.

Sadly that atlassian don't realize this requirement (

Some ideas?

It's not a case of them "not realising", it's more a case of "it's an utter nightmare which should NEVER be implemented because it doesn't work in the real world". Sub-tasks absolutely should take the same security level as their parent. I didn't realise you were talking about covering subtasks as well, or I'd have yelled before, sorry! Anyway, your options are still

Hi Nic, there are different point of views about "Sub-tasks absolutely should take the same security level as their parent" depend of the use of jira. Anyway i go further with the solution to set the securitylevel. If i want to "delete" a subtask i clone the parent set the securitylevel ant move the subissue i want "delete" to the clone mainissue. cheers, michael

I'm well aware of the varying opinions on this, and I've experienced the utter mess that doing it differently makes. On paper, some of the approaches to varying levels work. In real life, they simply do not. If you think you need a sub-task with a different level, you're wrong, you need to move it to a separate issue. In my experience, the only good thing that's ever come of implementing different security on sub-tasks is that it got me six weeks of well paid work to untangle the mess it made. I think you've hit on the only security-level related solution for sub-tasks there.

Well, i thank you very much for your help but it isn't it a little bit arrogant to say that all the others are with their requirements wrong. What kind of problems one get with varying levels? Maybe i never asked if i know them. If you work with external developers which should not see all the subissues why do i should create another mainissue with the identical information in it only to hide a subissues. I didn't have your experience and again i am very thankful that you have the time to answer but i don't see the Problems but the benefits (from my point of work).

I've worked in exactly that situation and it does not work. If a subtask cannot be seen by a developer, then his understanding of the main task is incomplete. This leads you into a place where a developer can easily write perfectly good stuff which is fine for his part of the task and breaks the rest of it. He has no way of knowing. Broken. Don't do it.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,397 views 15 19
Read article

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