A Product Owner I was coaching recently requested that I use Jira Wizardry to change her Jira project’s Permission Scheme to limit the number of people who can create tickets within it. Apparently there were some rogue ticket creators in the organisation who needed reining in.

Now just because you can do something in software doesn’t mean you should. This seemed to be one of those cases where we should apply the XP principle of Do The Simplest Thing That Could Possibly Work. Specifically, most teams don’t want or need the additional Jira Admin load of maintaining/tweaking custom Permission Schemes for all their projects.

Fortunately I was able to re-use a solution that had worked for another colleague in the same organisation; a Compliance Officer who wanted an easy way to check the work being picked up by a development team so she could scan for potential compliance risks.

The Simplest Thing That Could Work in this case was to use a little-known but very useful bit of functionality within Jira, which is that you can have custom search results emailed to yourself at an interval of your choosing. I’ll show you the steps below, though I won’t try to reproduce Atlassian’s detailed step-by-step documentation – I’ll just skim through the main points.

The first step (as almost always in Jira) is to know what JQL query you need to return the set of tickets you are interested in. In this case, something like the following search seemed correct:

project IN (MEM) AND issuetype NOT IN (Sub-task) AND createdDate >= startOfDay(-3d) ORDER BY reporter

…pulling out all the relevant tickets created at some point in the last 3 days (three days because on a Monday morning you’ll be wanting to see tickets created during the previous Friday, which was 3 days ago), ordered by Reporter, which is the slightly odd Jira term for “the person who created the ticket”.

After running that search and confirming that the right set of results are being returned, the next step is to save the search. In Jira terminology a ‘saved search’ is called a “filter”, and a good tip for managing filters is to preface the Filter Name with your own initials; this makes it easier to find your own filters later when they are presented in a (potentially long) alphabetically-ordered list that includes many filters from other people.

After saving the filter, you may now want to share it so that your colleagues can also benefit from viewing it and/or subscribing to it.

The final step is to ‘subscribe’ to the filter, which is Jira-speak for “having the results emailed to you at an interval of your choosing”. You enter the Subscription dialog box having found the relevant filter in your Manage Filters list (see under the main ‘Issues’ menu item found on any Jira page) and clicking on ‘Subscribe’:

…and it should be pretty obvious from there:

And you can test it works straight away. You now have the option to edit that newly-created subscription from your My Filters list:

…and that gives you the ability to run the Subscription (ie send the email) immediately, rather than waiting for the scheduled time:

Both the Compliance Officer and the Product Owner now have an email arriving in their inboxes every morning at 09:00, which takes about 30 seconds to skim. This tells the Compliance Officer whether there are any new risks she needs to address, and tells the Product Owner exactly who has been creating new tickets in her project. Both can then take appropriate action.

Once you’ve done it a couple of times you can set up / amend / delete filters and subscriptions in a minute or two, a beautifully clear example of applying the Do The Simplest Thing That Could Work policy.

Jira subscriptions are a useful trick, and I’d recommend having a play around with the functionality even if you have no immediate need – you never know when it might come in useful.