Atlassian Team Senior Engineer
One of the popular features in JIRA, Atlassian’s project management and bug tracking software, is the ability to search for JIRA Issues. You can search for Issues using the Basic search. This allows you to simply pick Project or Issue types and a variety of other things, to find the Issues you are looking for. You can also use the Advanced search, which allows you to type in your own JQL statement; JIRA has a convenient autocomplete feature that makes this much more intuitive to use.
You can then save these searches and share them on JIRA. Some people call these saved searches “Filters.” Why write a search over again when you can just refer back to it or share it with a friend, right? Simple and convenient. Also, these search filters can be used within JIRA in many places: Agile Boards, Dashboard Gadgets, subscriptions, and more.
In this blog I’m going to spell out a gotcha that happens with filters—filter sharing—and how this can make administering JIRA a big headache. The good news is, there is a simple way to resolve this filter sharing problem. You will be able to keep the administration efforts down yet still allow your users the ease of using these filters and having the access they need to do their work.
JIRA Filters Can Simplify Your Life
JIRA filters enable you to easily pull up the exact Issue you’re looking for, without the need to create a new JQL query every time you want to pull that data up. For example, you can use JIRA filters to call up Issues that are bugs only, bugs that have been fixed, bugs that were fixed by a specified date, etc.
JIRA Filters Can Also be a big headache
Like I said, when you save a JIRA filter there’s a built-in functionality that allows you to share it. Which, on the surface, sounds like a good thing…and is a good thing, but is something you need to pay attention to. Why should everyone have to “reinvent the wheel” and take the time to write a search query when you’ve already written it? Just give them yours. Done.
Well, the potential problems come from the fact that JIRA filters can be shared with everybody, with no way for you to see or know that others—perhaps hundreds of others—are depending on the filters you create. For a filter that is shared with everybody, there is no simple way to find how many Agile Boards, Reports, subscriptions, etc. are relying on this filter. When you look at your filter, as far as you can see, it’s just your filter. If something is using it, it is at their own risk, because you can change your filter at any time. If and when you do change your filters, these changes affect everyone and everything that is now depending on them. And these changes happen without notice or warning to anyone else.
Say your company has 1,000 people and each person has 100 filters in the system, all of which have been set to “share with everyone.” Imagine just one person changing one of these widely shared filters. The Agile Boards depending on this filter could change. Issues could go missing. Boards could stop functioning. The reports depending on this filter could show wrong totals. The dashboard gadgets depending on this filter could show wrong results. It can take a lot of time to find the source cause of these problems and right any possible wrongs that occurred because this one filter was changed. Now, imagine what would happen if everyone (not just one person) randomly changed their filters. The result would be chaos! You’d end up with lots of unhappy users and a lot of time spent by your administrators getting to the root causes of the problems.
Luckily there’s an Easy Solution
Want to avoid all of this? The solution is simple: Don’t share your filters with “everybody.” If you’re going to share a filter, only share it with a specific JIRA Project, or, to narrow things down even further, with specific Project Roles within that JIRA Project.
Yes, even with this approach there’s still a chance that someone will change the definition of a filter. But now instead of affecting everyone in the company, the change will only affect members of that person’s project team.