Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Администратор создал правило: при новом инциденте создать задачу разработчикам, добавить комментарий и перевести исходное обращение. В редакторе всё выглядит правильно, но исполнение падает на первом действии. Проверка под своей учётной записью не помогает, потому что правило выполняется с другой идентичностью.
Начинайте диагностику с конкретного исполнения, а не с общего просмотра конфигурации. В большом правиле часть действий могла уже завершиться. Сохраните идентификатор исполнения, ключ исходной задачи и время: это позволит найти созданные объекты и не принять повтор за независимый новый запрос пользователя.
Модель и договорённости
Разделите владельца правила и его актора. Составьте список действий и целевых проектов: чтение исходной задачи, создание связанной, запись ссылки, комментарий и переход. Для каждого действия определите минимальное разрешение и возможное ограничение безопасности задачи. Межпроектный сценарий требует проверки обеих сторон, а не только проекта, где находится правило.
Для целевого проекта проверьте не только разрешение создания, но и допустимость типа задачи и необходимых полей. Отдельно рассмотрите безопасность исходной задачи. Актор должен видеть сведения, которые правило читает, но это не повод открывать ему все проекты или делать глобальным администратором.
Порядок внедрения
Откройте журнал конкретного исполнения и найдите первое неуспешное действие. Проверьте актора в свойствах правила, затем его права в целевом проекте. Убедитесь, что выбранный тип задачи существует и нужные поля доступны. Исправляйте конкретное отсутствующее разрешение через согласованную роль, после чего повторяйте проверку следующего действия.
После исправления первого разрешения повторите ограниченный сценарий и остановитесь на следующем неподтверждённом действии. Сохраните, какое право помогло конкретному шагу. Для межпроектного правила ведите отдельную матрицу исходного и целевого проекта. Так владельцы схем смогут при будущем изменении заранее увидеть, какие автоматические операции необходимо перепроверить без выдачи глобальных полномочий актору.
Проверки на реальных сценариях
Прогоните правило на тестовой задаче и проверьте созданную связь, комментарий и конечный статус. Добавьте задачу с ограниченной видимостью и вариант без обязательного поля. Сравните результат после исправления прав с исходной ошибкой в журнале. Проверяйте, что актор не получил возможность создавать задачи в постороннем проекте.
Добавьте тест, где первое действие успешно, а следующее намеренно запрещено. Он показывает, умеет ли команда обнаружить частичный результат. После возврата минимального разрешения проверьте безопасное продолжение: повтор не должен клонировать уже созданную работу или публиковать одинаковый комментарий несколько раз.
Ошибки и диагностика
Широкое назначение администратора маскирует проблему и расширяет последствия будущей ошибки правила. Ещё один риск — повторить частично выполненное правило и создать вторую связанную задачу. Прежде чем повторять исполнение, проверьте уже выполненные действия и существующие связи. При необходимости временно добавьте защиту от повторного создания.
Перед повтором исполнения посмотрите, какие действия уже завершились. Неудача последнего перехода не отменяет ранее созданную связанную задачу, поэтому обычный повтор всего правила способен размножить полезную работу.
Возврат и восстановление
Сохраните прежние назначения прав и конфигурацию правила. Если изменение дало лишний доступ, остановите правило и верните конкретное назначение роли. Сверьте задачи, созданные за период пилота, и исправьте связи вручную по журналу. Не удаляйте результаты автоматически: разработчики могли уже добавить полезные данные или начать работу.
Если право выдано слишком широко, сначала остановите правило и сузьте назначение. Затем проверьте, какие задачи актор успел создать или изменить в период расширенного доступа. Восстановите ошибочные связи и уведомите владельцев затронутой работы по принятому внутреннему процессу. Повторное включение допускайте после положительной и отрицательной проверки минимального набора разрешений.
Приёмка и дальнейший контроль
Считайте отказы по действиям, повторные создания и число исключительных разрешений актора. Владелец правила должен знать, какие проекты оно затрагивает и почему. Диагностика завершена, когда правило работает с минимальным набором прав, а повторная проверка не вызывает скрытых дублей и непредусмотренных изменений.
В карточке правила храните назначение, владельца, актора и список затрагиваемых проектов. При изменении схемы прав этот список помогает заранее выбрать нужные проверки. Если правило перестало быть нужным, отключайте его вместе с пересмотром исключительных прав технической идентичности, а не оставляйте полномочия навсегда.
Механизм продукта и применимость
Atlassian связывает ошибку получения полей при создании задачи в Automation, в частности, с отсутствием у актора права создания в целевом проекте. Для последующих действий нужны соответствующие разрешения на редактирование, комментарии и переходы.
Ссылочная инструкция Atlassian разбирает конкретный класс ошибки создания в Cloud Automation. При проверке permission scheme учитывайте company-managed модель. В team-managed проекте ищите соответствующие настройки доступа проекта. Наличие владельца-администратора не подменяет проверку актора и разрешений каждого действия в целевой конфигурации.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу