Сроки в Jira Automation: даты, часовые пояса и пограничные случаи

Сначала определите смысл срока

Сервисная команда хочет выставлять контрольную дату через несколько дней после регистрации заявки. В обсуждении все говорят «через три дня», но руководитель подразумевает рабочие дни, разработчик — семьдесят два часа, а исполнители — конец третьего календарного дня. Это три разных требования. До настройки выберите одно определение и укажите часовой пояс. Если обязательство зависит от рабочего календаря SLA, простой сдвиг даты может не учитывать праздники, время работы команды и паузы процесса.

Для примера возьмём внутреннее напоминание через три календарных дня, которое не заменяет SLA. Исходный момент — создание задачи, результат — отдельное поле контрольной даты. Пользовательский Due date оставим в ведении планирования, чтобы автоматизация не перезаписывала договорённости исполнителя. В документации поля прямо напишите, почему оно вычисляется и кто вправе сделать исключение.

Разделяйте дату и точный момент времени

Поле даты хранит календарный день, а поле даты со временем представляет более точный момент. Если задача создана около полуночи, преобразование времени между часовыми поясами может дать разные календарные дни. Выбирайте тип поля по требованию: напоминание к началу рабочего дня и эскалация строго через несколько часов требуют разных моделей. Не исправляйте смещение строковым удалением части значения, пока не поняли, в каком часовом поясе оно сформировано.

Smart values предоставляют операции над датами, включая прибавление дней и форматирование. Пример {{issue.created.plusDays(3).jiraDate}} иллюстрирует расчёт календарной даты от создания; перед применением проверьте его в Log action на своих данных. Если необходимо явное преобразование часового пояса, сверяйте доступную операцию с актуальной документацией и используйте идентификатор региона, соответствующий команде. Не считайте форматирование эквивалентом преобразования времени.

Настройка правила без перезаписи ручных решений

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

Если срок должен пересчитываться после изменения определённого бизнес-параметра, вынесите это в отдельное правило с явным триггером изменения поля. Решите, когда сохраняется вручную установленное значение и как пользователь отмечает исключение. Без такого соглашения возникает борьба между человеком и автоматизацией: исполнитель исправляет дату, правило возвращает её обратно, а журнал становится единственным местом, где можно понять причину.

Проверьте календарные границы

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

Проверяйте не только значение в журнале, но и отображение поля под учётными записями с разными настройками времени. Если пользователи видят разные часы, это может быть нормальным отображением одного момента. Если различается календарная дата в поле, предназначенном для дня, проверьте цепочку преобразований. Не проверяйте расчёт только на сегодняшнем полудне: такой пример почти никогда не выявляет граничную ошибку.

Ошибки, наблюдение и исправление данных

Пустая исходная дата, неправильный идентификатор поля и неверное ожидание от рабочих дней — отдельные причины, для которых нужны разные действия. При пустом значении остановите изменение и выведите диагностическое сообщение без содержимого заявки. При ошибке прав проверяйте исполнителя правила и доступность поля. При ошибке бизнес-календаря изменяйте требование и расчёт, а не подбирайте постоянный сдвиг, который случайно работает на текущей неделе.

Для отката сохраните список задач, прежние значения и время запуска. Отключите правило до массовой коррекции. Исправляйте только значения, оставшиеся от ошибочного расчёта; вручную изменённые даты требуют проверки владельцем задачи. После внедрения периодически сравнивайте небольшую выборку с ручным расчётом и повторяйте граничные тесты при смене часового пояса команды или типа поля. Такой контроль дешевле расследования внезапно пропущенных обязательств.

Пример таблицы ожидаемых дат

Владелец процесса может подготовить небольшую таблицу без технических выражений: исходный момент, часовой пояс, правило отсчёта, ожидаемый календарный день и допустимое исключение. Разработчик добавляет рядом вычисленный результат Automation и причину расхождения. Для примеров конца месяца и пятницы заранее решите, должны ли выходные входить в расчёт. После согласования эту таблицу сохраняют вместе с правилом и повторяют при изменении календаря. Такой артефакт помогает отделить дефект настройки от изменения бизнес-требования и предотвращает спор о значении фразы «через несколько дней» после первого инцидента.