Jira is an event-driven system. This means that, when an action occurs (for example, when an issue is created), Jira usually fires off a corresponding event. This event is then picked up by components that are designed to listen to the event. Not surprisingly, these are called listeners. When a listener picks up an event, it will perform its duty, such as keeping issues up to date with changes or sending an email to users who are watching the issue.
This mechanism allows Jira to process operations asynchronously. The advantage of this model is operations, such as sending emails, and it's separated from Jira's core functions such as issue creation. If there is a problem with the mail server, for example, you will not want this problem to prevent your users from creating issues.
There are two types of event in Jira:
- System events: These are internal events that are used by Jira, and they usually represent the main functionalities in Jira. They cannot be added, edited, or deleted.
- Custom events: These are events that are created by users. They can be added and deleted, and they are fired through workflow post functions.
The following table lists all the system events in Jira and what they are used for:
|
Event |
Description |
|
Issue Created |
This states that an issue has been created in Jira. |
|
Issue Updated |
This states that an issue has been updated (for example, changes to its fields). |
|
Issue Assigned |
This states that an issue has been assigned to a user. |
|
Issue Resolved |
This states that an issue has been resolved (usually applied to the resolve workflow transition). |
|
Issue Closed |
This states that an issue has been closed (usually applied to the closed workflow transition). |
|
Issue Commented |
This states that a comment has been added to an issue. |
|
Issue Comment Edited |
This states that a comment has been updated. |
|
Issue Reopened |
This states that an issue has been reopened (usually applied to the reopen workflow transition). |
|
Issue Deleted |
This states that an issue has been deleted from Jira. |
|
Issue Moved |
This states that an issue has been moved (to a different or the same project). |
|
Work Logged On Issue |
This states that the time has been logged on this issue (if time tracking has been enabled). |
|
Work Started On Issue |
This states that the assignee has started working on this issue (usually applied to the start progress workflow transition). |
|
Work Stopped On Issue |
This states that the assignee has stopped working on this issue (usually applied to the stop progress workflow transition). |
|
Issue Worklog Updated |
This states that the worklog has been updated (if time tracking has been enabled). |
|
Issue Worklog Deleted |
This states that the worklog has been deleted (if time tracking has been enabled). |
|
Generic Event |
This states that a generic event can be used by any workflow post function. |
|
Custom Event |
This states that the events that have created by the user to represent arbitrary events have been generated by business processes. |
As an administrator, you will be able to get a one-page view of all the events in Jira. You just need to do the following:
- Browse to the Jira administration console.
- Select the System tab and then the Events option. This will bring up the View Events page.
Each event is associated with a template, which is often referred to as a mail template. These templates define the content structure of emails when notifications are sent. For system events, you cannot change their templates (you can change the template files, however). For custom events, you can choose to use one of the existing templates or create your own mail template.
In the following sections, we will first look at how to create and register custom mail templates, create a new custom event to use the new template, and fire the new event when actions are performed on an issue. After that, we will look at how to tie events to notifications so that we can tell Jira who should receive notification emails for the event.