4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in JiraPermissions 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 delete 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, delete 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: Delete permissions? Very important.

Types of Delete Permissions

Amongst these permissions are four groups:

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues

And 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 the majority 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 a fairly innocuous permission and can be assigned to any user with access to a project, unless you have very strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are fairly 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 might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than the spreadsheet they were looking for. 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 year’s worth of tickets.

If something is deleted in Jira, it’s gone forever. This can be a nightmare for many, but 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.

Stop worrying about Jira and make full use of its powerful features!  We can help you implement and optimize your Jira instance, contact us, and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration verify bespoke
4 min read

The Journey to Atlassian SSO, Part I - What Are the Signs that it's Time for Single Sign On?

By resolution on Jan 28, 2021 12:54:01 PM

Blogpost-display-image_The Journey to Atlassian SSO, Part 1 - What Are the Signs that its Time for Single Sign On--1Praecipio Consulting has partnered with our friends at resolutionan Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

journey-to-atlassian-sso-eliminate-friction-blog-1

The password syndrome 

Passwords are the weakest link in tech: we use them every hour, we forget them every day and ask for recovery emails constantly. We replace passwords with less complex alternatives so often that we have assumed it's fine to let them degrade: in the end, the only problem I have to deal with as a user is not gaining access to my accounts. Who would ever want to exploit my accounts? 

Single sign-on kills password fatigue by killing passwords- in plural. But oftentimes, many business stakeholders still view SSO as a nice-to-have supplement that eliminates user friction, failing to recognize the web of security risks that it solves.  

An overview of the symptoms of password fatigue for the different corporate ranks can help technical leaders kickstart the journey to onboard a suitable SSO solution. Having a solid case can also make them more persuasive security evangelists.  

Pain points for users 

Many employees will just reuse the same memorable password in order to maintain access to their accounts. Many others will not access certain applications if an unwanted login blocks their way. User fatigue will then result in low tech adoption for applications that are not central to the employee's job description, with compliance and open enrollment software as two front runners in this race to oblivion.  

When business processes are not followed, information will be lost or remain siloed, and business productivity and collaboration will suffer. Employees whose performance relies on the compliance and open enrollment software everybody has dropped will have a very hard time completing their job. Many companies using Jira Core to support these types of processes fail to recognize the threat that login friction poses to the general adoption of the mandated tool. 

Pain points for security officers 

In the long run, poor password hygiene results in infections. How long until someone loses the paper notebook where her passwords are written? How long until it's found by the wrong hands on a plane or at a workshop outside the office? 

Security officers have many reasons to panic in a culture of security last with no SSO. Besides the password leaks, outdated user accounts can easily expose classified information to roles that lack the required clearance. Or disgruntled employees may discover they can still access the company's code repository on Bitbucket. 

Pain points for administrators 

A very revealing symptom that a company is in urgent need of an SSO solution is buried in the recurring tasks of system administrators. Discontinuing accounts of leavers in a timely manner or adjusting the permissions of an employee who has moved to a different department are extremely difficult tasks without a centralized user management function. 

Besides eating up the available seats in your licenses, lacking an automated method for provisioning users into applications has serious repercussions. For starters, new users will have to wait in a queue until an administrator is available. 

Administrators must also enforce security measures when credentials are compromised, often at the cost of major productivity setbacks. Have you ever had to set new credentials for all your accounts? Yes, it feels pretty much like your first day at the job again. 

Pain points for Help Desks 

Password frustration is a more visible phenomenon on the user side. But make the experiment of asking a Help Desk agent working at a large corporation without SSO in place how many password recovery calls he must attend every day. And how that work ranks in his important vs urgent matrix. 

High volumes of password replacement calls are among the key factors associated with low productivity of Help Desks. In ITIL jargon, they are technically requests, but in practice they're just a manifestation of the recurring problem: the dire need for an SSO. With an SSO in place, password recovery requests will be rare. They will still happen, particularly if you still have a password expiration policy (and there's a reason why Microsoft has abandoned that recommendation). But ownership will be much more effective, and you will have a maximum of 1 request per user. 

A single source of truth 

As much as single sign-on solves the password management problem, it's important to remind stakeholders that it also has the important benefit of centralizing employee accounts for all mandated enterprise software.  Admittedly, one immediate effect of that centralization is that users will have only one master key to all their applications. But the other side of the story is even more important: single sign-on connects user management for individual applications to a single source of truth, maintaining tight enforcement over access rights that eliminates the need for IT heroics. 

The good news is that many enterprises already have the necessary infrastructure in place to easily set up an SSO solution. Customers of Office 365, for example, can enable their central directory on Azure AD for free. A continuation to this article will offer a practical overview of your available options. It will detail what kind of identity resources are necessary to set up a single sign-on, what are the most common configurations of centralized user directories for Atlassian applications, and what tricks can get you a leading Identity Provider at an affordable price.

Topics: blog sign standardize security verify resolution

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us