Применимость: Data Center. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Какое действие должно быть запрещено
Команда разрешает переводить изменение в готовность к релизу только при наличии ответственного и плана возврата. Проверка заполненности двух полей полезна, но ещё не доказывает готовность: значение может состоять из пробелов, ответственный может быть недоступен, а переход может выполняться интеграцией. Сначала сформулируйте минимальную проверяемую политику. Не пытайтесь автоматически оценить качество инженерного плана одним условием длины текста; содержательную оценку оставьте согласующему.
Разделите проверки на объективные и экспертные. Наличие значения, допустимый риск и согласованный статус являются объективными признаками. Достаточность плана возврата — решение ответственного специалиста, которое можно отразить отдельным подтверждением. Валидатор должен проверять именно согласованные признаки и выдавать понятное сообщение, а не превращаться в скрытую систему принятия решений внутри workflow.
Выберите правильный компонент workflow
Condition определяет доступность перехода, validator проверяет допустимость его выполнения, а post function выполняет работу в процессе перехода. Для отказа из-за неполных данных нужен валидатор. Если спрятать переход условием, пользователь может не понять, чего не хватает. Если обнаружить проблему поздно в post function, восстановление становится сложнее. Выбор компонента влияет на пользовательский опыт и надёжность процесса.
В ScriptRunner доступны готовые и скриптовые валидаторы; начните с подходящего стандартного варианта, если он выражает требование без кода. Для скриптового варианта сверяйте контекст и поддерживаемые API установленной версии. Не копируйте фрагмент из Data Center в Cloud и не смешивайте примеры разных поколений API. В этой инструкции важна схема проверки; конкретную реализацию под поля экземпляра следует проверить на тестовом workflow.
Проверяйте данные, введённые на переходе
Если пользователь заполняет план возврата на transition screen, валидатор должен оценивать данные этого перехода, а не старое сохранённое состояние. Проверьте данный сценарий отдельно: задача до открытия экрана не имеет плана, пользователь вводит корректный текст и успешно выполняет действие. Обратный пример — удаление плана на том же экране — должно привести к отказу. Ошибка контекста делает правило внешне случайным и подталкивает пользователей к обходным действиям.
Для полей используйте устойчивые идентификаторы там, где это поддерживает выбранный механизм, и документируйте их назначение. Названия могут повторяться или меняться. Сообщение должно перечислять требуемое действие: заполнить план возврата и выбрать ответственного. Не выводите внутренний стек ошибки пользователю. Непредвиденное исключение в скрипте — технический инцидент, который нужно диагностировать отдельно от нормального отказа бизнес-проверки.
Матрица переходов и регрессия
Проверьте оба поля заполнены, каждое пустое отдельно, оба пустые, текст из пробелов и корректные данные, введённые непосредственно на переходе. Добавьте пользователя другой роли и используемую REST-интеграцию. Если существуют альтернативные переходы в тот же статус, определите, должны ли они иметь такую же проверку. Ограничение одного перехода не предотвращает обход через другой маршрут workflow.
Перед публикацией убедитесь, какие проекты используют общую схему. Изменение shared workflow может затронуть команды, для которых поля не применимы. При необходимости выделите отдельный процесс вместо расширения условных исключений внутри одного скрипта. Сохраните тестовые ключи и ожидаемые результаты. После обновления Jira или ScriptRunner повторите компактный набор переходов, особенно если менялся контекст экрана или API полей.
Публикация и возврат к прежнему процессу
Подготовьте изменение на тестовом экземпляре или согласованной копии workflow. Сохраните прежнюю конфигурацию, список зависимых проектов и инструкцию публикации. Сообщите команде точное новое требование и пример приемлемого заполнения. В первые дни смотрите отказы и обращения: массовая ошибка на всех задачах обычно означает проблему конфигурации, а не внезапное ухудшение дисциплины команды.
При ошибке остановите публикацию следующих изменений и верните предыдущую конфигурацию валидатора через поддерживаемое редактирование workflow. Не исправляйте проблему прямой записью в базу Jira. Проверьте задачи, которые успели перейти по неверной проверке, и согласуйте адресное восстановление. Итогом должна стать прозрачная граница готовности: корректные данные проходят, неполные получают полезное сообщение, а все предусмотренные каналы выполнения соблюдают одно требование.
Приёмка владельцем процесса
Приёмку валидатора завершает человек, отвечающий за релизный процесс. Он должен увидеть успешный переход с корректными данными и понятный отказ с неполными. Дополнительно покажите альтернативный маршрут workflow и используемую интеграцию. Если какой-то канал намеренно освобождён от проверки, зафиксируйте основание и компенсирующий контроль. Не оставляйте исключение скрытым внутри сложного условия скрипта. Согласованная матрица переходов помогает проводить будущие изменения без случайного обхода обязательства и объяснять пользователям, почему один переход доступен, а другой требует дополнительного заполнения.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу