Concepts

Event Rule

Event rule operates based on a model of event, condition, and action. When an event happens, the predicate is checked, then conditions are checked, and finally, designated actions are taken. You get to decide which event a rule is triggered by, what conditions (if any) will be checked, and ultimately what actions should be taken as a result.

The Event rule DSL is very similar to the Workflow Rules DSL. It uses natural language like syntax with built-in Jira terminologies for event processing.

Let’s take a look at a typical event rule:

when

The when part define what kind of event the rule is interested in. It is the trigger of the rule.

An optional where can be specified to filter the event by checking the data associated with the event. The filter predicate is dependent on the kind of event. In the case of issue update event, the field name predicate is available.

if

The if part is the condition which determines whether the rule should be applied in specific circumstances. It can be used to check general issue properties. The condition is optional and if it is not specified, the action will be triggered whenever the event happens.

then

The then part defines what the rule do, such as to update the issue field or notify users. Any number of actions can be added to a rule, and when the rule’s conditions are met, all of the actions on the rule will be taken.

Other than the obviously different syntactic form, the more important difference is that event rule DSL is declarative. How the predicates are matched, how the rules are triggered and in what order they are executed are determined by event reactor and event runtime.

Event Reactor

Event reactor is the basic concept that allows you to organize rules which work together as part of the same purpose.

Normally each event rule represents an individual event reaction logic. Sometimes, it can work on its own. But in most cases, two or more rules are supposed to work together in order to solve a business problem. As an example, you may create a series of rules to detect the creation, deletion, update of the issues with highest priority.

Other than the “group” function, event reactor can also be used to control how the rules are evaluated and fired. The default behaviour is the rules under the same reactor are evaluated in the descending order of priority and all matched rules are fired following the same order.

It is possible to introduce some different execution behaviour. For example, only the highest priority rule is expected to be fired when condition is matched. This will be useful when you don’t expect more than one rule to be executed.

Rule Chaining

Rules can be chained. One rule can emit a synthetic custom event in the action immediately or after a period of time. Then another rule listening for the custom event will be triggered. This allows rules to express more complex event logic.

One interesting use case is to monitor if the high priority issue is assigned within 4 hours. This can be easily implemented using a delayed custom event.

Check out this example.