Concepts

Explain the concepts

Workflowrules provides a flexible and powerful linguistic way to manage Jira workflow logic.

Condition rule

Condition rule is essentially a boolean expression that is to be evaluated by workflow execution.

The typical use of condition rule is checking if the data matches some criteria such as:

  • a number is greater than another number
  • a text equals to another text or matches a pattern
  • a date is before or after another date

It supports logical operators (AND, OR) so that you can combine multiple simple expressions for complex logic. Parentheses can be used for grouping the parts of complex expressions.

Besides, condition rule also has built-in support for high order predicate which can check if a list of items match a certain condition:

  • all of the items match (<condition>)
  • any of the items match (<condition>)
  • none of the items match (<condition>)

Examples can be found at examples.

Validator rule

Validator rule is built on top of condition rule as the purpose of validation is to produce a boolean result. The only difference is that validator rule allows to specify a string message as the validation result. This is a feature introduced since version 2.2.0.

Examples can be found at examples.

Action rule

Action rule is a combination of condition and action. It uses the form of if <condition> then <then-action> else <else-action>. The condition part is exactly the same as the condition rule. When it evaluates to true, the then-action part will be triggered. Otherwise the else-action is selected. This is similar to if-else expression/statement of most programming languages.

The action part represents one or more operations to be performed automatically when it is chosen. The currently supported actions include:

  • Add comment to an issue
  • Add label/version to an issue
  • Add or remove wathcer
  • Assign an issue to a user
  • Update fields of the issue
  • Send email notification

Examples can be found at examples.

The list is growing along the time so feedback is welcome. A future feature is that users will be able to define their own actions.

The language

In the core of the plugin is a domain language that is designed for the use of non-developer. It could be seen as kind of Business Readable DSL according to Martin Fowler.

  • It is domain specific. It has Jira concepts and terminologies built into the language vocabulary.

  • It is limited. It does not allow you to do arbitrary things and crash Jira. You can only write business logic in the defined context.

  • It is verbose. It is trying to mimic natural language but not trying too hard as long as it is readable for casual user.

  • It is growing. It is designed to be growing with the vocabulary defined on domain model.

  • It is statically typed. Each phrase has an associated type and the type constraint is applied during editing so that you have little chance to write wrong things.

  • It is truly writable for people even with no coding experience. The smart editor predicts what can be written based on context information. Anything that is not valid for syntax and semantics will be caught right away.

The domain model

The domain (Jira) model is the foundation of the language. In the context of Jira, the model contains domain concepts like “Issue”, “project” and “user”, which represents the entities that can be used in the language. And domain concepts may have attributes or operations which represent phrases of the language.

Current Jira domain concepts can be found at Reference.

In the long run, the Jira model will be exposed for customization so that users can extend the vocabulary and enhance the language to meet specific needs.


Last modified January 15, 2020