Применимость: Data Center. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий условно обязательного поля
В процессе управления изменениями инженер выбирает уровень риска. Для высокого риска необходимо указать план возврата, для низкого достаточно обычного описания. Behaviours помогают адаптировать форму: показать подсказку, сделать поле обязательным или изменить доступность на поддерживаемом экране. Это уменьшает число ошибок пользователя во время заполнения. Однако удобство интерфейса и гарантия соблюдения бизнес-правила являются разными задачами.
Сначала определите, на каком переходе план возврата действительно обязателен. Возможно, черновик высокого риска должен сохраняться без него, а отправка на согласование — блокироваться. Если сразу запрещать любой черновик, пользователи начнут вставлять бессмысленные заглушки. Условие должно поддерживать реальный порядок подготовки изменения. Владелец процесса заранее согласует тексты подсказок и понятное сообщение об ошибке.
Ограничьте область Behaviour
Создайте mapping для нужного проекта и типа задачи. Не применяйте правило ко всем проектам только потому, что поле риска глобальное. В разных командах одинаковое название поля может иметь другой смысл. Проверьте поддерживаемые поля, экраны и особенности установленной версии ScriptRunner. Примеры для Data Center не следует автоматически переносить в Cloud: реализация и доступные методы отличаются.
Опишите состояния формы в небольшой таблице: риск пустой, низкий, высокий, изменён с высокого на низкий. Для каждого состояния укажите видимость, обязательность и подсказку. Проверьте начальную загрузку уже существующей задачи: недостаточно реагировать только на ручное изменение риска. При возврате к низкому риску поле не должно оставаться обязательным из-за состояния предыдущего взаимодействия. Значение плана не удаляйте автоматически при скрытии без отдельного требования.
Разделите помощь пользователю и контроль перехода
Behaviours предназначены для поведения поддерживаемых форм. Они не заменяют серверную бизнес-проверку для всех каналов изменения. Если запрет обязателен независимо от интерфейса, настройте соответствующий workflow validator на переходе согласования. Тогда форма помогает заполнить данные заранее, а валидатор обеспечивает отказ в момент действия. Не считайте скрытое поле механизмом ограничения доступа к данным: конфиденциальность обеспечивается моделью разрешений и архитектурой хранения.
Проверьте REST-интеграции, импорт, массовые операции и другие автоматизации, используемые в вашей Jira. Цель проверки — понять, где действует помощь формы и где требуется независимая проверка. Не ожидайте, что одно UI-правило перехватит любой способ редактирования. Для интеграций опишите обязательный набор данных и понятную обработку отказа перехода, чтобы внешняя система не повторяла некорректный запрос бесконечно.
Проверка формы реальными пользователями
Пройдите сценарий под инженером, согласующим и пользователем только с просмотром. Проверьте создание, редактирование и нужный переход, если эти экраны входят в поддержку и mapping. Уделите внимание пустому риску, существующему плану возврата и смене типа задачи. Подсказка должна объяснять ожидаемое содержимое: последовательность возврата, ответственный и проверка результата. Формулировка «обязательное поле» не помогает подготовить качественный план.
Добавьте проверку конфликтов с другими Behaviours и конфигурацией поля. Если одно правило делает поле доступным, а другое скрывает, пользователь увидит непредсказуемое поведение. Не исправляйте конфликт случайным порядком скриптов: объедините ответственность или чётко разделите области. Сохраняйте исходную конфигурацию и записывайте, какое правило управляет каждым аспектом поля. Это особенно важно при общих схемах нескольких проектов.
Ошибки и управляемый откат
Если форма стала недоступной для заполнения, отключите узкий mapping или проблемный Behaviour и проверьте базовый экран. Серверный валидатор при этом продолжит выполнять согласованную проверку перехода; пользователям потребуется понятная инструкция, какие данные заполнить вручную. Если ошибка находится в самом бизнес-условии, временное отключение валидатора требует владельца процесса и контроля затронутых переходов, иначе незаполненные изменения попадут в согласование.
После исправления повторите матрицу состояний и проверьте хотя бы один внешний канал перехода. Сравните число отказов, качество заполнения и обращения пользователей. Успешный Behaviour делает правильное заполнение очевидным, а не просто увеличивает число обязательных полей. Документируйте границы применимости рядом с конфигурацией: проект, тип, экран, зависимые поля и отдельный валидатор. При обновлении ScriptRunner эта запись станет основой короткой регрессионной проверки.
Подсказка вместо бессмысленного ограничения
Покажите форму нескольким инженерам до включения обязательности. Попросите их заполнить план возврата на реальном, но обезличенном примере и объяснить, что они поняли из подсказки. Если все вставляют одинаковую формальную фразу, проблема может быть в требовании, а не в интерфейсе. Добавьте короткий образец структуры: условие начала возврата, последовательность действий, ответственный и способ проверки. Не заполняйте эту структуру автоматически как готовое подтверждение. Содержательная подсказка помогает получить данные для решения, тогда как одно красное обозначение обязательного поля лишь заставляет пользователя вводить любой текст.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу