С момента ухода компании Atlassian с российского рынка прошло уже больше года. Те кто пользовался её продуктами, отлично понимал возможности для автоматизации в системе. Это делалось и с помощью базового функционала, а также с помощью плагинов вроде ScriptRunner. Автоматизировали различные настройки workflow, автоматическое назначение задач, behaviors-поля и кучу всего другого. 

Так как мы заменяем Jira, Confluence и Jira Service Management в России, мы реализовали те же самые возможности в продуктах EvaTeam. В этой статье рассказывается какие виды автоматизаций есть, в каких случаях использовать конкретный способ и как продолжить работать также как в Jira, но в российском сервисе.

Вводную информацию про автоматизацию в EvaProject вы можете прочитать в этой статье, ну а в этой начнем сразу с технических подробностей.

На чем базируется наша автоматизация 

Можно выделить 4 типа автоматизаций, которые используются в системе: бизнес-процессы, триггеры, экраны, cron. Каждый из них заменяет аналогичный функционал в Jira и используется для решения конкретных задач. Отдельно ещё можно выделить bzPython, который заменяет скрипты в плагине ScriptRunner. Начнем с самого первого — бизнес-процессов. 

Бизнес-процессы

Используются когда нужно вызвать какой-либо скрипт при смене статуса задачи/спринта и т.п.

В Jira рабочий процесс представляет собой путь, который проходит задача от создания до завершения.

Open (Открыто), Done (Завершено) и все промежуточные метки обозначают статус, который задача может принимать, а стрелки обозначают возможные переходы из одного статуса в другой. Рабочие процессы могут быть простыми или сложными, содержать условия перехода, валидаторы и действия. В EvaProject мы предоставляем аналогичные инструменты, но с гораздо более расширенным функционалом.

Схема и принцип работы аналогичен Jira — используются условия перехода, валидаторы и действия. Несколько бизнес-процессов можно объединить в схемы и настроить их для работы в рамках определенных проектов с заданными условиями (например, для определенных типов задач).

Как пользователь может понять что ему нужен именно такой вид автоматизации? Если нужно настроить всё что связано со сменой статуса, можно смело идти в настройки системы в раздел "Бизнес-процессы".

Тот кто пользуется Jira давно, знает про сторонний плагин ScriptRunner. Он позволяет писать свои скрипты на Groovy, которые могут напрямую использовать JIRA Java API. Писать расширения на Groovy конечно приятно, но у нас есть лучшая замена.

В качестве основы для своих автоматизаций бизнес-процессов мы взяли bzPython (бизнес-пайтон) — старый добрый Python, но с предустановленными переменными и встроенными функциями. Его использование дает возможность делать кастомные расширения любому сотруднику, который дружит с логикой и аналитикой. Бесплатно и без смс.

И сразу приведем пару примеров использования bzPython в наших автоматизациях.

Примеры получения данных с использованием bzPython

В системе заложены определенные свойства объектов, информацию о свойствах и объектах можно получить простыми запросами bzPython.

К примеру, задаче назначили проект, а затем изменили его. Рассмотрим три свойства поля проекта. Поле в таблице CmfTask у задачи, которое ссылается на проект называется parent.

• self.name - получить имя текущего объекта.

• self.cmf_owner - объект, в котором содержится информация о владельце текущего объекта. 

• self.cmf_owner.name - имя владельца объекта

• is_changed - объект был изменен. Свойство представляет собой тип boolean и может иметь значения True или False. Для получения информации об изменении имени в задаче используем конструкцию:

  self.name.is_changed

• old - объект был у задачи, до изменения/удаления. Свойство содержит информацию о предыдущем имени, который был у задачи, получить данные по нему можем:

  self.name.old

• new - объект был назначен задаче после изменения/добавления. Свойство представляет собой новое имя, назначенное задаче. Получить информацию по нему.

• # .new всегда равен текущему значению поля и используется для повышения читаемости кода self.name.new

Получение вложенных задач первого уровня 

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

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

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

Получение пользователя, который проводил последнее изменение над задачей 

self.cmf_modified_by

Получение задачи, которая является родительской для выбранной задачи 

self.parent_task

Возможности для управления автоматизациями

Для удобства работы с большими скриптами и бизнес-процессами, есть возможность подключиться к инстансу On-premise версии с помощью IDE и писать код не в диалоговом окне, а в python-файле. Так будет гораздо легче и проще настроить все что вам нужно. А ещё это позволит контролировать версии git'ом и при наличии нескольких инстансов (prod, dev, test и т.п.) переносить изменения между ними.

Триггеры

Со статусами разобрались, переходим к автоматизации при изменении полей. Триггеры позволяют создать событие, если у задачи или документа изменилось какое-то поле. Рассмотрим пример, в котором попробуем назначить исполнителем по задаче того, кто оставил комментарий.

Для этого в глобальных настройках мы создаем новое правило в разделе Автоматизация - Триггеры. Его настройка будет выглядеть так:

Здесь мы определили условия для события — при событии комментирования в объектах с моделью Задача (CmfTask) будет происходить нужное действие. Теперь определим что конкретно нам нужно. Для этого в пункте Триггер выставим выполняемый код.

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

После сохранения у нас будет готова ловушка для ваших коллег. Теперь кто прокомментировал задачу, тот и будет её делать.

Автоматизация Экраны (аналог Behaviors полей)

С помощью стандартной настройки в Jira можно определить какие поля вообще будут в задачах. Однако настройка поведения в плагине ScriptRunner позволяет вам наладить то, как поля будут себя вести в зависимости от контекста, типа задачи и т.д. Без установки такого плагина можно настроить тоже самое в EvaProject с помощью автоматизации экранов.

Данный функционал позволяет расширить стандартные параметры конфигурации полей, доступные в Jira, и дают вам возможность использовать контекстную информацию, такую ​​как текущие значения полей, статус или сведения о пользователе, в качестве условной логики.

Вот некоторые примеры того, что можно настроить:

• Сделать поле обязательным в зависимости от других данных, введенных на экране выдачи.

• Сделать поле доступным только для чтения в зависимости от роли пользователя или группы.

• Выполнить проверку данных поля на стороне сервера перед отправкой экрана проблемы.

• Установить значение поля в зависимости от других данных в задаче.

В EvaProject это можно делать без установки дополнительного плагина. Все бесплатно и сразу работает. Чтобы начать пользоваться нужно просто перейти в настройки и выбрать "Автоматизация Экраны".

Модуль предназначен для кастомизации логики отображения экранных форм с помощью bzPython. Обработчик запускается при запросе объекта и после изменения его полей (на форме перехода код тоже запускается в момент изменения полей, но без сохранения изменений в объекте).

Запуск обработчика можно ограничить следующими фильтрами (указываются в настройках обработчика):

• Модель,

• Фильтр по логическому типу объекта,

• Фильтр по виду деятельности,

• Фильтр по Схеме Бизнес-процессов,

• Фильтр по Проекту.

Список свойств, которые можно изменять:

• visible - отображение поля на форме (True - поле отображается, False - скрыто);

• widget - переопределение виджета у поля;

• caption - переопределение имени поля, отображаемого на форме;

• comment - комментарий поля;

• readonly - поле только для чтения (True - только для чтения, False - доступно для изменения);

• required - поле обязательно для заполнения (работает только на форме перехода и форме создания заявки в ServiceDesk);

• required_changed - поле обязательно для изменения (работает только на форме перехода и форме создания заявки в ServiceDesk);

• choices - список полей для выбора (в формате {code1: caption1, code2: caption2}, например: { -2: "Минимальный", -1: "Низкий", 0: "Обычный", 1: "Высокий", 2: "Критичный"});

• options_list_filter - дополнительный BQL-фильтр для поля выбора объекта.

Пример создания автоматизации

Сравнение того, как это работает в EvaProject и в Jira с использованием плагина Scriptrunner

⁠Cron

Возможности системы позволяют автоматизировать действия не только по событиям и действиям, но и по времени. С помощью Cron можно настроить периодические автоматизации по заданному времени или через определенный период. Сделать это можно в глобальных настройках "Автоматизация Cron".

Например, попробуем взять задачи, у которых статус не менялся 7 дней, отметить их как закрытые и отправить сообщение владельцу задачи.

В настройках создаем Cron-событие по автозакрытию.

Самое важное здесь - поле "Выполняемый код". В нем записывается скрипт bzPython. Выглядит он вот так:

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='Заголовок')

Чтобы настроить период выполнения данного скрипта, используется поле "Выражение Cron". В примере мы настроили выполнение каждый день в 00:00. А вы можете настроить любой нужный период. Для этого есть 5 колонок (Минута, Час, День, Месяц, День недели), в них может находиться число, список чисел, разделённых запятыми, диапазон чисел, разделённых тире или символ '*'.

Вот пару примеров таких выражений:

⁠Заключение

В EvaProject есть типы автоматизации, которые вы использовали в Jira. Они встроены и все из них можно использовать без установки дополнительных плагинов.

В зависимости от того, что конкретно вы хотите автоматизировать, вы выбираете нужный тип.

1. Если автоматизация вызывается при смене статуса - Автоматизация Бизнес-процессов;

2. Если нужно настроить автоматизацию при изменении любого другого поля (не статуса) - Триггеры;

3. Нужно работать со свойствами полей в задаче (также как вы делали это с Behaviors в Jira) - Экраны;

4. Если нужно периодическое событие - Cron.