Bugzilla: проверки изменений багов

What links here (1) →

В рамках , в Bugzilla был реализован общий механизм «проверок корректности изменений» багов.

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

Проверка состояния

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

Заморозка багов

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

Юз-кейсы в Bug:61225 были следующие:

• Запретить закрывать баги продукта TN-RMS, у которых не проставлены поля Sprint, Agreement, Whiteboard.
• Запретить ASSIGNить баги продуктов CIS-Forms и NewPlatform, кроме компонентов components и misc, у которых не проставлено поле Sprint.

Юз-кейсы в Bug:68921 следующие:

• Запретить списывать время в баг, который попал в счета. Желательно также запретить изменения полей WBS и Agreement. Можно вообще все изменения запретить, оставить только возможность добавлять комментарии.
• Запретить списывать время задним числом в баг, который попал в старые счета, на старые периоды, при этом разрешить списывать время задним числом на новые периоды.

Принцип работы

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

В случае, если проверка запускается до внесения изменений — получаем режим «заморозки багов». Если после — это проверка корректности внесённых изменений.

Кроме того, можно выбрать поля, которые запрещено (или разрешено) изменять при изменении подходящих под запрос багов. Можно даже уточнить, что запрещено (разрешено) изменение конкретного поля на конкретное значение (например, статуса на CLOSED).

Выбирать конкретные поля для разрешения изменений можно только для проверок, запускаемых при обновлениях багов, ибо при создании бага понятие «изменение полей» отсутствует. Аналогично при создании бага нельзя выбрать режим «предварительной проверки», ибо до создания бага нечего проверять.

Атрибуты проверки

Итак, получаем следующий набор атрибутов проверки:

• Сохранённый запрос — запрос поиска, на котором основана проверка.
• Сообщение об ошибке.
• «Проверять создание новых багов» — запускать ли проверку при создании новых багов, попадающих под сохранённый запрос.
• «Проверять обновления багов» — запускать ли проверку при изменении существующих багов, попадающих под сохранённый запрос.
• «Предварительная проверка» — режим заморозки багов.
• «Запрещать изменения?» — если да, то будет ошибка и операция заблокируется, если нет — только предупреждение.

Фильтр по отдельным полям, работает только при изменении багов, при создании багов игнорируется:

• «Запрещать изменения всех полей» — если да, то запрещаются все изменения, кроме перечисленных ниже, как исключения. Если нет (режим «разрешения») — разрешаются все изменения, кроме перечисленных.
• Список полей-исключений — исключения «поле + значение» (либо «любое значение», когда значение не задано) для предыдущего пункта.
• В списке полей есть специальное поле «Backdated worktime», с помощью которого можно запретить вводить трудозатраты задним числом. Например, чтобы запретить вводить трудозатраты задним числом раньше 2010-09-01, нужно выбрать поле «Backdated worktime» и значение «2010-09-01». Пустое значение означает полный запрет ввода трудозатрат задним числом. Флажок «Запрещать изменения всех полей» должен быть сброшен!

Предикаты создаются и редактируются из Administration → Checkers (нужно быть членом группы bz_editcheckers).

Создание проверки

Чтобы создать предикат, нужно:

1. Задать и сохранить под каким-нибудь именем любой запрос поиска. Это будут «некорректные» по смыслу баги.
2. Нажать «добавить предикат», выбрать созданный запрос и задать желаемые параметры.

Запрос поиска можно скрыть из панели сохранённых поисков, показываемых всегда, с личной страницы Preferences → Saved Searches.

Пример

Пример (запретить закрывать баги продукта TN-RMS, у которых не проставлены поля Sprint, Agreement, Whiteboard):

1. Задаём запрос поиска:

   Product = TN-RMS

   Status = CLOSED

   SCRUM Sprint# is equal to "" ("" — пустая строка)

   OR Agreement is equal to "" ("" — пустая строка)

   OR Whiteboard is equal to "" ("" — пустая строка)

2. Добавляем предикат:
   • «Проверять создание новых багов» — нет
   • «Проверять обновления багов» — да
   • «Предварительная проверка» — нет
   • «Запрещать изменения?» — да
   • «Запрещать изменения всех полей» — нет
   • Добавить поле-исключение «Status» и новое значение «CLOSED», чтобы разрешить изменять уже закрытые баги с пустыми полями (старые баги).

---

Статья реплицируется в Wiki4IntraNet.