Jira Cloud: Releasing multi-project old tickets from Kanban board without spamming developer’s inbox

[#1]

This is an interesting case I always wanted to make better: almost every project you come to has a lot of older unreleased tickets, that are already on production for quite some time. And developers (without proper jira management) continue to use the Kanban board that becomes more crowded in the Done / Closed column (and it can hit 400, 1000 tickets and be slow and almost pointless to use). Typical story, huh?

So what to do, if you want to release all those older tickets and don’t bother developers with, say, 450 updates on every ticket that fixVersion has been set to each one of them? The answer (and thanks to AUG Moscow Community) is to swap notification scheme for related projects while releasing.

• Note 1: now, there may be a question: why didn't I do bulk edit of the tickets with the checkbox of 'Send Emails for this Update' marked off? The answer is that I didn't want to manually create versions to release in every single project.
• Note 2: somehow, there was no ability at that time (in the dropdown) to select no notification scheme. It appeared only when I had +1 blank notification scheme created.
• Note 3: This is the first time I post into Atlassian Community and I have a huge feeling that it's something trivial and lame, as all of the pros will do it much neater :)

References: https://confluence.atlassian.com/adminjiraserver071/creating-a-notification-scheme-802592629.html

Steps

1. Go to Jira Settings -> Issues -> Notification Schemes (usually there's just one by default)

2. Create a blank scheme (as in the screenshot). It means that the events (like in my case it is ‘Issue Updated’ would not send any notifications).

3. Now go to the Project Settings -> Notification Schemes. Swap the notification scheme for the blank one in the Project Settings

4. Take a look at notification schemes in jira settings (it should not include one project attached to the blank scheme.

5. And finally release the Done/ Closed tickets on the Kanban board -> voila, no email notifications were sent at all.

You’ll still get the events themselves logged in Jira, event if notifications weren't sent.

Other solutions

Might include turning off outgoing emails, but after turning them on events will build up a queue of notification that missed scheduled sendout :) So don’t do this.

[Dave Sky]

Good tut! Too many users either don't realize they can do certain things to improve usage, or they just don't want to take the time or effort to learn. At a previous company, we used something like this to manage old tickets and notifications, and it worked out well when we just took the time to learn it and make it happen.

[Matt Doar]

Turning off emails or changing the notification scheme has a small risk that changes made by other people may not send the expected notification. What I usually do is ignore the Release button and replace the default subfilter with something such as 

status != closed or resolutiondate > -2w

Then the board will show all active issues and the issues closed in the last two weeks. 

"Release" on a Kanban ticket always seemed a bit of a hack to me, and the default subfilter performs very poorly when it uses unreleasedVersions() in a large Jira instance

[HOZAIFA QUAYUM]

Awesome! thanks for sharing, I've been looking to clean up my  teams Jira instance, but one of the things keeping me from doing so was exactly this spamming their inboxes :)  

[Marat Kiniabulatov]

@Matt Doar i totally agree with you :)

In this particular case we basically reiterated releasing and assigning a version to see where we at with features implemented. And this approach just a bit better helped us to get the grasp of what we've already achieved vs. backlog! 

I'd totally agree with replacing Release button with subfilter, and would say that when the process is organized neatly there's no even a need for a release button of a kind :)

[Gezim Shehu [Communardo]]

It's a nice idea, but in an active instance this would have to be scheduled as maintenance period, to avoid missing any other notifications.

I always use a similar sub-filter as already mentioned by @Matt Doar, which is also why I was not particularly excited about the new feature that "cleans up" your backlog (Hide completed issues older than).

In support boards I use

fixVersion in unreleasedVersions() OR fixVersion is EMPTY and (resolutiondate is EMPTY OR resolutiondate >=-8h) 

[Marat Kiniabulatov]

@Gezim Shehu [Communardo] thanks for the feedback. I have the privilege to be the only more-or-less jira admin in that particular org, and maintenance period was just early morning before people came to work :)

In bigger orgs certainly this is a less neat solution!

[Gezim Shehu [Communardo]]

@Marat Kiniabulatovwell for what's worth, the solution is "Jira-ish" enough for me :).

Keep up the posting in the Community.

Looking forward to it!

[Tanya L Christensen]

I work on a very large instance. I like the idea of changing the scheme for the one project.  However, in our instance that would require a request into the support team who are global admin.  There are pros and cons to each option. Giving folks different ideas to do the same thing is what this community is all about.  Keep on sharing your ideas.  😊👍

[Matt Doar]

You can speed up 

fixVersion in unreleasedVersions()

by putting the relevant project keys in the parens, comma-separated

[Marat Kiniabulatov]

@Matt Doar didn't know it, super-helpful! Thanks man!

[Jess Hostetter (DO NOT USE)]

This is a very interesting idea, plus it gets the old scary backlog cleaned up!

I have also had good results with shifting projects from the default to a "Useful Notifications" notification scheme, which only sends messages for the following events:

• Issue Assigned
• Issue Reopened
• Issue Commented