More than a year has passed since the departure of Atlassian from the Russian market. Those who used its products perfectly understood the possibilities for automation in the system. This was done with the help of the basic functionality, as well as with the help of plugins like ScriptRunner. Automated various workflow settings, automatic assignment of tasks, behaviors fields and a lot of other things.

Since we are replacing Jira, Confluence and Jira Service Management in Russia, we implemented the same capabilities in EvaTeam products. This article tells what types of automations there are, in which cases to use a specific method and how to continue working as in Jira, but in the Russian service.

You can read introductory information about automation in EvaProject in this article, and in this one we will start immediately with technical details.

What our automation is based on

You can distinguish 4 types of automation used in the system: business processes, triggers, screens, cron. Each of them replaces similar functionality in Jira and is used to solve specific tasks. Separately, you can highlight bzPython, which replaces scripts in the ScriptRunner plugin. Let’s start with the first – business processes.

Business processes

They are used when you need to call some script when changing the status of a task/sprint, etc.

In Jira, a workflow is a path that a task takes from creation to completion.

Open, Done, and everything in between indicate the statuses a task can take, and arrows indicate possible transitions from one status to another. Workflows can be simple or complex, contain transition conditions, validators and actions. At EvaProject, we provide similar tools, but with more advanced functionality.

The scheme and principle of operation is similar to Jira – transition conditions, validators and actions are used. Several business processes can be combined into schemes and configured to work within certain projects with specified conditions (for example, for certain types of tasks).

How can a user understand that he needs this kind of automation? If you need to configure everything related to the status change, you can safely go to the system settings in the “Business Processes” section.

Anyone who has been using Jira for a long time knows about the third-party plugin ScriptRunner. It allows you to write your Groovy scripts that can directly use the JIRA Java API. Writing extensions in Groovy is certainly fun, but we have the best replacement.

As a basis for our business process automations, we took bzPython (business python) — good old Python, but with set variables and built-in functions. Its use makes it possible to make custom extensions for any employee who is friends with logic and analytics. Free and without SMS.

And we will immediately give several examples of using bzPython in our automations.

Examples of fetching data using bzPython

Certain properties of objects are embedded in the system, information about properties and objects can be obtained by simple bzPython queries.

For example, a task was assigned to a project, but it was changed. Consider three properties of the project field. The field in the CmfTask table in the task that refers to the project is called parent.

• self.name – get the name of the current object.

• self.cmf_owner – an object that contains information about the owner of the current object.

• self.cmf_owner.name – the name of the owner of the object

• is_changed – The object has been changed. A property is a type boolean and may matter True or False. To obtain information about changing the name of the task, we use the construction:

  self.name.is_changed

• old – the object was in the task before it was changed/deleted. The property contains information about the previous name that the task had, we can get data about it:

  self.name.old

• new – the object was assigned to the task after the change/addition. The property is the new name assigned to the task. Get information about it.

• # .new is always equal to the current value of the field and is used to increase the reading of self.name.new code

Getting nested tasks of the first level

# Вариант 1. Для текущей задачи
self.child_tasks

# Вариант 2. Для любой другой задачи
# Находим задачу по коду
task = models.CmfTask.get(code="DEV-1624986272")

# Получаем вложенные задачи циклом
for t in task.child_tasks:
cmf_alert(f'Получили вложенную задачу {t.name}')

Get the user who made the last change on the task

self.cmf_modified_by

Get the task that is the parent of the selected task

self.parent_task

Opportunities to manage automations

For the convenience of working with large scripts and business processes, it is possible to connect to an instance of the On-premise version using the IDE and write code not in a dialog box, but in a python file. So it will be much easier and simpler to configure everything you need. And this will allow you to control versions with git and, if there are several instances (prod, dev, test, etc.), transfer changes between them.

Triggers

With the statuses figured out, let’s move on to automation when changing fields. Triggers allow you to create an event if a field in a task or document has changed. Let’s consider an example in which we will try to appoint the person who left the comment as the executor of the task.

To do this, in the global settings, we create a new rule in the Automation – Triggers section. Its configuration will look like this:

Here we have defined the conditions for the event – in case of a commenting event, the required action will occur in objects with the Task model (CmfTask). Now let’s determine what exactly we need. To do this, in the Trigger item, we will put the code that is being executed.

# self - текущий комментарий
task = self.parent
task.responsible = g.current_user
task.save()

After saving, we will have a trap ready for your colleagues. Now someone commented on the task, he will do it.

Automation Screens (similar to Behaviors fields)

With the help of standard Jira settings, you can determine which fields will be in tasks in general. However, customizing the behavior in the ScriptRunner plugin allows you to customize how the fields will behave depending on the context, task type, etc. Without installing such a plugin, you can configure the same in EvaProject using screen automation.

This functionality extends the standard field configuration options available in Jira and gives you the ability to use contextual information such as current field values, status, or user information as conditional logic.

Here are some examples of what you can customize:

• Make the field mandatory depending on the other data entered on the issue screen.

• Make a field read-only based on a user’s or group’s role.

• Check the field data on the server side before submitting the problem screen.

• Set field value depending on other job data.

In EvaProject, this can be done without installing an additional plugin. Everything is free and works immediately. To start using, you just need to go to the settings and select “Automation Screens”.

The module is intended for customizing the display logic of screen forms using bzPython. The handler is launched when the object is requested and after its fields are changed (on the transition form, the code is also launched when the fields are changed, but without saving the changes in the object).

The launch of the handler can be limited by the following filters (specified in the handler settings):

• Model,

• Filter by logical object type,

• Filter by type of activity,

• Filter according to the Business Process Diagram,

• Filter by project.

List of properties that can be changed:

• visible – displaying the field on the form (True – the field is displayed, False – it is hidden);

• widget – redefinition of the widget near the field;

• caption – redefinition of the name of the field that is displayed on the form;

• comment – ​​field comment;

• readonly – read-only field (True – read-only, False – changes are available);

• required – the field must be filled in (only works on the transition form and the application creation form in ServiceDesk);

• required_changed – the field must be changed (works only on the transition form and the form for creating an application in ServiceDesk);

• choices – a list of fields for selection (in the format {code1: caption1, code2: caption2}, for example: {-2: “Minimum”, -1: “Low”, 0: “Normal”, 1: “High”, 2: “Critical”});

• options_list_filter – an additional BQL filter for the object selection field.

An example of creating automation

A comparison of how it works in EvaProject and Jira using the Scriptrunner plugin

Cron

The capabilities of the system allow you to automate actions not only by events and actions, but also by time. With the help of Cron, you can set up periodic automations at a given time or for a certain period. You can do this in the global “Cron Automation” settings.

For example, let’s try to take tasks whose status has not changed for 7 days, mark them as closed and send a message to the owner of the task.

In the settings, we create a Cron event from auto-closing.

The most important thing here is the “Executable code” field. It writes a bzPython script. It looks like this:

seven_days_ago = g.now - timedelta(days=7)
# Находим задачи, у которых статус не менялся 7 дней
tasks = models.CmfTask.list(filter=[['status_modified_at', '<=', seven_days_ago], ['cache_status_type', '!=', 'CLOSED']])
for task in tasks:
  task.status = task.workflow.get_default_status(status_code="closed")
  task.save()
  # Отправляем сообщение владельцу задачи
  models.CmfNotify.place_notify(obj=task, person=task.cmf_owner,
    msg= {task.code} отмечена как выполненная автоматически', text="Заголовок")

The “Cron expression” field is used to set the execution period of this script. In the example, we set it to run every day at 00:00. And you can set any period. There are 5 columns for this (Minute, Hour, Day, Month, Day of the week), they can contain a number, a list of numbers separated by commas, a range of numbers separated by dashes or the symbol ‘*‘.

Here are some examples of such expressions:

Conclusion

EvaProject has the types of automation you used in Jira. They are built-in and all can be used without installing additional plugins.

Depending on what exactly you want to automate, you choose the type you need.

1. If automation is called for status changes – Automation Business processes;

2. If you need to configure automation when changing another field (not status) – Triggers;

3. You need to work with the properties of the fields in the task (just like you did with Behaviors Jira) – Screens;

4. If a periodic event is required – Cron.