Permissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.
And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the Jira delete issue permissions.
“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.
You see, Jira delete issue permissions are so incredibly critical for one reason:
There is no recycling bin in out-of-the-box Jira.
This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.
So, to summarize: Jira delete issue permissions? Very important.
Types of Jira Issue Delete Permissions
To begin, it’s important to understand the Jira delete issue permissions structure. Within Jira, there are four groups of delete permissions:
- Delete Worklogs
- Delete Comments
- Delete Attachments
- Delete Issues
And then within those permissions, there are two types:
- Delete Own
- Delete All
Delete Own Permissions
The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for most of the above-mentioned groups, with the exception of Issues.
Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is an innocuous permission and can be assigned to any users with access to a project, unless you have strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are limited.
Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”
Delete Own Attachments is another permission that can be used for tidying. This feature might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than a spreadsheet for the project. It’s fairly low impact as well and can likely be given out to any users within your project, especially if you’re following the Backup Rule of 3 or similar internally.
Delete All Permissions
Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.
Delete All Worklogs, Delete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.
And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a years’ worth of tickets.
Remember: when something is deleted in Jira, it’s gone forever. This permanence can be a nightmare for many, especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.
Conclusion
Stop worrying about Jira and make full use of its powerful features! We have several Jira best practices resources for you to check out, like this article on using Jira labels and also this one about how to make use of Jira Epics.
We are also a fan of learning by example. Discover how Crocs implemented Jira Software best practices to clean up work flows, keep teams connected, and standardize how they managed projects across the organization.
Explore more ways we can help your teams succeed in putting your Atlassian tools to work, or contact us and one of our experts will be in touch shortly.
