Users will often want to get progress updates on their issues after they have logged them. So, instead of business users having to ask for updates, we will proactively update them through our newly acquired knowledge; that is JIRA notifications.
In Chapter 4, Field Management, we added a custom field called Escalation List, which allows users to add who else will receive notifications along with the issue's reporter and assignee.
Another customization we have made is to the workflows in Chapter 6, Workflows and Business Processes, with new transitions. We need to make sure those transitions fire appropriate events and also send out notifications. In summary, we need to do the following:
While you can achieve both by using other JIRA features, such as adding users as watchers to the issue and reusing existing JIRA system events, this exercise will explore the options available to you, and as you will see in later chapters, there are other criteria to consider while deciding on the best approach.
The first step to enable e-mail communication, as you will have guessed, is to register mail servers in JIRA. If you are using the standalone distribution of JIRA, it is recommended that you add your mail server by entering the host information:
After adding your mail server, you can try sending yourself a quick test mail to see if JIRA is able to access your server successfully.
In Chapter 6, Workflows and Business Processes, we created two new workflow transitions. One is for the help desk staff to request additional information from the business user, and another for the business user to supply the requested information. What you need to do now is create custom events for the transitions when they are executed:
Info Requested
.This is the request information event
.With your event created, you now need to update your workflow so that your transitions can fire the correct event:
In this case, you can reuse the Issue Updated event and it will work just as fine. However, there are advantages to having your own custom events as it helps to distinguish exactly what is the nature of the update. When you have the listeners' components in JIRA, having specialized events helps to distinguish the origin and act accordingly.
Now you need to have your own notification scheme, so you can start adding notifications to your events. We will be basing our notification scheme on the default scheme to help us get things set up quickly:
Help Desk Notification Scheme
.This will create a new notification scheme with the basic notifications prepopulated. All you need to do now is modify the events and add your own notification needs.
There are two rules you need to follow to add our notifications. First, you need to add notifications for your custom events, so that e-mails will be sent out when they are fired. Second, you will want users specified in the CC list custom field to also receive e-mails along with the assignee and reporter of the issue:
Nice and easy. With just a few clicks, JIRA has allowed us to add a new notification to not only all the system events, but also our new custom events.
The last step, as always, is to associate your scheme with projects for activation:
Help Desk
project.With just a few clicks, you have enabled your JIRA to automatically send out e-mails to update users with their issue's progress. Not only this, you have tied in the custom fields you created from earlier chapters to manage who, along with the issue assignee and reporter, will also get the notifications. So let's put this to test!
If you do not receive e-mails from JIRA, check your mail queue and see if the mail is getting generated, and follow the steps from the Troubleshooting Notifications section.