С момента ухода компании 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. К примеру, задаче назначили проект, а затем изменили его. Рассмотрим три свойства поля проекта. Поле в таблице CmfTask у задачи, которое ссылается на проект называется parent. self.name - получить имя текущего объекта. self.cmf_owner - объект, в котором содержится информация о владельце текущего объекта.  self.cmf_owner.name - имя владельца объекта is_changed - объект был изменен. Свойство представляет собой тип boolean и может иметь значения True или False. Для получения информации об изменении имени в задаче используем конструкцию: old - объект был у задачи, до изменения/удаления. Свойство содержит информацию о предыдущем имени, который был у задачи, получить данные по нему можем: new - объект был назначен задаче после изменения/добавления. Свойство представляет собой новое имя, назначенное задаче. Получить информацию по нему. # .new  всегда равен текущему значению поля и используется для повышения читаемости кода self.name.new Для удобства работы с большими скриптами и бизнес-процессами, есть возможность подключиться к инстансу On-premise версии с помощью IDE и писать код не в диалоговом окне, а в python-файле. Так будет гораздо легче и проще настроить все что вам нужно. А ещё это позволит контролировать версии git'ом и при наличии нескольких инстансов (prod, dev, test и т.п.) переносить изменения между ними. Со статусами разобрались, переходим к автоматизации при изменении полей. Триггеры позволяют создать событие, если у задачи или документа изменилось какое-то поле. Рассмотрим пример, в котором попробуем назначить исполнителем по задаче того, кто оставил комментарий. Для этого в глобальных настройках мы создаем новое правило в разделе Автоматизация - Триггеры. Его настройка будет выглядеть так: Здесь мы определили условия для события — при событии комментирования в объектах с моделью Задача (CmfTask) будет происходить нужное действие. Теперь определим что конкретно нам нужно. Для этого в пункте Триггер выставим выполняемый код. После сохранения у нас будет готова ловушка для ваших коллег. Теперь кто прокомментировал задачу, тот и будет её делать. С помощью стандартной настройки в 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  Eva ScriptRunner Скрытие/отображение полей ui_fields.custom_field1.hidden = True ui_fields.custom_field2.hidden = False customField1.setHidden(true) customField2.setHidden(false) Выставление режима "только для чтения"  ui_fields.custom_field1.readonly = True // По имени final String fieldName = "CustomField" getFieldByName(fieldName).setReadOnly(true) // По id getFieldById(IssueFieldConstants.DUE_DATE).setReadOnly(true) Возможности системы позволяют автоматизировать действия не только по событиям и действиям, но и по времени. С помощью Cron можно настроить периодические автоматизации по заданному времени или через определенный период. Сделать это можно в глобальных настройках "Автоматизация Cron". Например, попробуем взять задачи, у которых статус не менялся 7 дней, отметить их как закрытые и отправить сообщение владельцу задачи. В настройках создаем Cron-событие по автозакрытию. Самое важное здесь - поле "Выполняемый код". В нем записывается скрипт bzPython. Выглядит он вот так: Чтобы настроить период выполнения данного скрипта, используется поле "Выражение Cron". В примере мы настроили выполнение каждый день в 00:00. А вы можете настроить любой нужный период. Для этого есть 5 колонок (Минута, Час, День, Месяц, День недели), в них может находиться число, список чисел, разделённых запятыми, диапазон чисел, разделённых тире или символ '*'. Вот пару примеров таких выражений: Запись времени Описание 5 0 * * * Выполняется каждый день в 0 часов 5 минут 0 22 * * 1-5 Выполняется каждый рабочий день в 22:00 23 */2 * * * Выполняется в 0:23, 2:23, 4:23 и т.д. 5 4 * * sun Выполняется в 4:05 в воскресенье 15 10,13 * * 1,4  Выполняется в понедельник и четверг в 10:15 и 13:15 0-59 * * * *  Выполняется ежеминутно 0-59/2 * * * *  Выполняется по четным минутам В EvaProject есть типы автоматизации, которые вы использовали в Jira. Они встроены и все из них можно использовать без установки дополнительных плагинов. В зависимости от того, что конкретно вы хотите автоматизировать, вы выбираете нужный тип. Если автоматизация вызывается при смене статуса - Автоматизация Бизнес-процессов; Если нужно настроить автоматизацию при изменении любого другого поля (не статуса) - Триггеры; Нужно работать со свойствами полей в задаче (также как вы делали это с Behaviors в Jira) - Экраны; Если нужно периодическое событие - Cron.