Why should deleting issues in Jira be restricted?

[#1]

Question

Why don’t you recommend deleting issues in Jira?

---

Answer

In my own Jira applications, and when helping clients, I always recommend removing the ability to delete issues. Normally, I don’t recommend setting too may Jira restrictions. In most cases, my advice is to only restrict capabilities that are necessary for governance and compliance purposes. Otherwise, start with the most transparency possible and add restrictions slowly as needed. I find that many user-created problems can be solved through education. Except for a very small number of Jira projects, like your corporate security project for example, most projects and issues can probably be open for most users to interact with. Don’t restrict actions so heavily that users must contact application administrators to perform simple operations.

One Exception: The Delete Issues Permission

There’s one exception to my usual position on user restrictions. I always remove the delete issues permission. There are many reasons to consider restricting this capability.

Risks of Deleting Issues

• You cannot restore deleted issues; they are gone forever.
• There’s no record of who deleted an issue or why.
• Deletion creates a numbering gap in the index.

While a numbering gap won’t cause Jira application errors, it bothers me when I can query for CUST-19 and CUST-21 but not CUST-20, like in the example below. CUST-20 is no longer there. If there’s a long list of issues, will users even realize some are missing? Probably not.

CUST-20 not displayed in the issue list

Additionally, if a user directly queries for a missing issue, they’ll see the error message displayed below. When they report this to the Jira administration team, they’ll waste time troubleshooting a permissions error which is not the real problem.

CUST-20 is deleted and cannot be returned

Issue Deletion Alternatives

Instead of deleting, encourage users to re-purpose unneeded issues or close them with resolutions like Won’t Do, Duplicate, or Cannot Reproduce.

Closed unneeded issues with a descriptive resolution

Jira can handle many millions of issues. It’s not like you need to delete some or you’ll run out!

Editing a Permission Scheme

To check your application’s permissions or modify a Permission Scheme, login as a Jira application administrator and visit: Admin > Issues > Permission schemes. In the example permission scheme below, the Delete Issues permission is granted to “Any logged in user”. Click the “Remove” link on the right to remove that entry and others. Note: Project-level permissions are not available in the Jira Cloud free plan.

The “Delete Issues” permission in a Permission Scheme

TIP: Also consider whether users should be able to remove ALL comments, attachments, and worklogs. I generally allow users to remove or edit their own objects but not everyone else’s.

For additional help with permissions, permission schemes, or Jira best practices take my Jira, Jira Service Management, and Confluence courses on LinkedIn Learning.

[Dave Mathijs]

I share you opinion @Rachel Wright but Jira will "complain" (i.e. display a warning for admins) if you remove this permission, even for customers in a service project.

[Rachel Wright]

Thanks for the comment @Dave Mathijs! I know - that nag message in JSM is so annoying.

If anyone is wondering, we're discussing the "This service project has configuration problems and may not work as expected." error that admins see in a Jira Service Management project.

Here's the "error" displayed after removing users from the "Delete issues" permission. I would love to be able to tell Jira (and my fellow admins) that we made this decision on purpose and to stop recommending we "fix" it. :)

[Matt Doar _Adaptavist_]

Another approach is to hide issues to be deleted using an Issue Security Scheme. But in practice I just suggest people close the issue and move on. Except when there is confidential info in the issue, then deletion can be considered. And also remember to delete that issue in your staging instances and DR backups

[Joe Pitt]

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

 Deleting issues destroys historical data. Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

 None of my users have delete permission.

[Stephen_Lugton]

Thanks for the article @Rachel Wright and for everyone else's input; we don't normally allow issues to be deleted, but one way we dealt with this at a previous company was to have a deleted issues project with limited access that deleted issues could be copied to using an admin only automation, with a comment added to say which project it came from and why it was deleted

[Susan Waldrip]

Great article, @Rachel Wright! It never made sense to me why the Delete Issues permission was a default for customers(?!) and Service Desk users (agents), and I turned that off a while back but always wondered if there was a good reason to keep it on that I hadn't thought of. I agree that a deleted issue can be gone forever, and we have minimal record retention requirements for all our work so far but we added the Revyz Data Manager for Jira app (no affiliation) because of its security and ability to restore so many things -- including issues and attachments. It's been a relief to have that capability, and I also like @Stephen_Lugton's separate project idea if you can't afford or don't want an add-on. Thanks for posting this!