Group Notifications in JIRA
My team has inherited a very messy process for posting safety alerts production. It started out innocently enough but has grown over the years, spreading through the organization like a fungus. For sake of argument I call it a process, but it is more like a non-deterministic sequence of events supported by a scaffold of personal relationships, secret knowledge, and incantations that cause some files to appear on a production machine.
We recently moved the whole process into JIRA to safeguard our mental health and make outcomes more predictable. It is far from perfect, but it prevents the process from degenerating into a game of broken telephone. Everyone involved, be they content creators, editors, or operations can see the status of the work for themselves and forgo a cubicle hunt to find the next link in the chain.
JIRA is a godsend, but does not support notifying groups. Issues are expected to travel point-to-point. For the most part this arrangement works well, but causes friction when you don’t know which person should be handling an issue. This limitation can be particularly troublesome when a task must go through several hands before being completed. When someone is absent, a request could languish for days because the submitter does not know to whom a ticket should be directed. Obviously, such a delay is unacceptable for posting recall notices.
To get around this snag we used a some scripting inside JIRA to send changes to tickets to all members of a group. We also added a new type of Issue and installed the excellent Script Runner plugin which comes with some useful scripts right out of the can.
First off, we created a group in JIRA containing everyone involved with posting recall alerts. Next we added the new issue type, “Publish Alert,” and added it to a new project, “Alerts”. It is not necessary to use a separate project, but less confusing to other staff.
Next, we activated a Builtin Script Listener to watch Publish Alert tickets and mail them to everyone in the group.
It is possible to add listeners directly into the JIRA workflow, but I felt this mechanism might be harder to maintain. Messing around with workflows isn’t for the faint of heart, and it is easy to forget what the triggers might be doing because JIRA has them buried way down in the workflow configuration pages.
Another approach would have been to add all members of the group as listeners to the ticket. The members of the group would have to be retrieved and each added as a listener in turn, but this would have meant more being more dependent on JIRA’s internal API than I was comfortable with.
The listener is activated each time a Publish Alert ticket is added or modified. The trigger is set in the listener’s “Condition” configuration line.
issue.issueTypeObject.name == 'Publish Alert'
A more complex trigger might eliminate the need for an additional Issue type, and use some other criteria. On the other hand the whole thing is easier for non-technical folks to use if they only have to remember the issue type, and not specific settings.
The subject line can contain code. The $issue reference resolves to the current Issue object.
$issue: New Alert
The email body is generated from a template. Script Runner sets references to the current Issue and ComponentManager into the template context. The issue title, assignees, comments, and the rest of it are available from these objects. My template shows the issue’s status and most recent comment.
A new alert is available. $issue
- Reported by: $issue.reporter.displayName
- Assigned to: $issue.assignee.displayName
- Status: $issue.status.name
- Summary: $issue.summary
The last stanza prints the most recent comment, if one exists.
The final piece of the puzzle is to tell the listener to send the mail to everyone in the group, in the “To issue fields”:
group:alert-editors
And that’s it.