Documentation for JIRA 4.0. Documentation for other versions of JIRA is available too.

Skip to end of metadata
Go to start of metadata

On this page:

Overview of JIRA Events

JIRA uses an event-listener mechanism to alert the system that something has happened, and to peform appropriate action (e.g. send an email notification) based on the event that has occurred. Every issue operation within JIRA is associated with a particular event - e.g. the Issue Created event is fired when an issue has been created.

A Listener can execute a specified action once it has been notified that a particular event has been fired. For example, the MailListener can send an Issue Created email to a list of recipients defined in the appropriate Notification Scheme, whenever an issue is created.

Some events are fired by JIRA internally — e.g. an Issue Updated or Issue Moved event. Other events are fired from within workflow transition post-functions — e.g. an Issue Resolved event, or a Custom Event (see below).

Event Types

There are two types of events within JIRA:

  • System — System events are used throughout JIRA internally, and cannot be added or deleted. You can, however, make them Inactive (see below).
  • Custom — Custom events are used to generate an email notification (or invoke a listener) from a particular workflow transition's post-function. You can add/delete as many custom events as you need. Note that only inactive custom events can be deleted.

An event can be in either of the following states:

  • Active — the event is associated with at least one notification scheme or workflow transition post-function
  • Inactive — the event is not associated with any notification schemes or workflow transition post-functions.
    Note that the event state does not indicate whether the event is able to be fired. A custom event will only be fired if it is associated with a transition post-function for an active workflow (see 'Activating Workflow').

System Events

JIRA's built-in system events are:

Issue Created:

An issue has been entered into the system.

Issue Updated:

An issue has had its details changed.

Issue Assigned:

An issue has been assigned to a new user.

Issue Resolved:

An issue has been resolved (usually after being worked on and fixed).

Issue Closed:

An issue has been closed. (Note that an issue may be closed without being resolved; see Statuses ).

Issue Commented:

An issue has had a comment added to it.

Issue Comment Edited:

An issue's comment has been modified.

Issue Reopened:

An issue has been re-opened.

Issue Deleted:

An issue has been deleted.

Issue Moved:

An issue has been moved into this project.

Work Logged On Issue:

An issue has had hours logged against it (i.e. a worklog has been added).

Work Started On Issue:

The Assignee has started working on an issue.

Work Stopped On Issue:

The Assignee has stopped working on an issue.

Issue Worklog Updated:

An entry in an issue's worklog has been modified.

Issue Worklog Deleted:

An entry in an issue's worklog has been deleted.

Generic Event:

The exact nature of this event depends on the workflow transition post-function(s) which invoke it. As with Custom Events, you can use the Generic Event to generate an email notification (or invoke a listener) from a particular workflow transition's post-function (see Workflow and Notifications ).

Custom Events

You can fire a custom event from a custom transition post-function in a custom workflow. The appropriate listeners will be alerted of the custom transition by the firing of this event. For example, the associated notification scheme can be configured to notify users of the workflow transition based on the firing of this custom event.

Configuring Notifications for a Custom Event

Custom events are most commonly used to generate notifications for custom workflow transitions. For example, your organisation might need you to modify the default workflow by adding a workflow step called "QA_Inspection" (e.g. between "Resolve Issue" and "Close Issue"). You would typically also need to generate an email notification to the QA team whenever an issue progresses to the "QA_Inspection" step of the workflow.

There are three overall steps to achieve this:

  1. Add a custom event to the system (e.g. "Issue Awaiting QA").
  2. Configure the notification scheme to send an email when the custom event is fired.
  3. Configure the workflow transition post-function to fire the custom event.

Step 1. Add a Custom Event

  1. Navigate to the 'Administration' link from the main menu.
  2. Select the 'Events' link under the 'Global Settings' section in the sub-menu.
  3. Add a name and description for the new event.
  4. Select a default email template to be associated with the event.
  5. Click 'Add'.

The custom event must be associated with a default email notification template. A notification scheme configured to notify users of this event will use this email template when sending the notification.

The custom event will appear in the list of events defined within the system. Initially, the event will be marked as inactive as it is not associated with a notification scheme or workflow post-function.

Step 2. Configure Notification Scheme to send mail on Custom Event

  1. Navigate to the 'Administration' link from the main menu.
  2. Select the 'Notification Schemes' link under the Schemes section in the sub-menu.
  3. Select the notification scheme to edit.
  4. Add the recipients for the custom event as required - further details available here.

Step 3. Configure Workflow Transition Post-Function to Fire Custom Event

  1. Navigate to the 'Administration' link from the main menu.
  2. Select the 'Workflows' link under the 'Global Settings' section in the sub-menu.
  3. Navigate to workflow transition post-function screen to be edited - further details available here.
  4. Update the post-function to fire the custom event.
  5. Activate or associate the workflow (and scheme) with the appropriate project (see 'Activating Workflow').

Updates to Workflows on Disk

As of JIRA 3.6, all event references are made through the EVENT ID. For pre-JIRA 3.6 data, all database tables (Workflow, Notification, etc.) are updated automatically. However, it is necessary to manually update event references in workflows saved to disk. This upgrade guide provides details on the changes required.