Mark for deletion

[Michael Kornatzki]

Hi,

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?

Thanks,

michael

[Christian Czaia _Decadis AG_]

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"  

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

Cheers

[Michael Kornatzki]

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

[Christian Czaia _Decadis AG_]

"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

[Nic Brough -Adaptavist-]

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.

[Michael Kornatzki]

Damn it didn't work 

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.

SUBISSUES CAN NOT HAVE ANOTER SECURITYLEVEL AS THE MAINISSUE!!!
Sadly that atlassian don't realize this requirement (https://jira.atlassian.com/browse/JRA-5869).

Some ideas?

[Nic Brough -Adaptavist-]

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

[Michael Kornatzki]

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

[Nic Brough -Adaptavist-]

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.

[Michael Kornatzki]

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

[Nic Brough -Adaptavist-]

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.

[Michael Kornatzki]

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)

[Nic Brough -Adaptavist-]

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.