MantisBT не показывает журнал изменений

Я использую MantisBT для отслеживания проблем и на данный момент собрал ряд проблем. Однако мой журнал изменений остается пустым

Информация журнала изменений отсутствует. Проблемы включаются после того, как у проектов есть версии, и проблемы решаются с помощью набора «исправлено в версии».

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

Я настроил свой рабочий процесс и подозреваю, что это одна из причин.

# custom access list
$g_access_levels_enum_string = '10:VIEWER,20:REPORTER,30:ENGINEER,40:CCB,90:ADMINISTRATOR';

# custom resolution list
$g_resolution_enum_string = '10:OPEN,20:REOPEN,30:WONTFIX,60:DISPOSITIONED, 70:FIXED';

Из того, что я смог определить, для появления журнала изменений вам нужно 1) выпущенная версия (сделано) 2) ошибка с исправленной версией, соответствующей этой (сделано 3) ошибка закрыта как «исправленная»

теперь в свежем MantisBT (и тестирование показывает, что журнал изменений работает), FIXED имеет константу 20, поэтому часть меня подозревает, что это моя g_resolution_enum_string, но это также означает, что должна быть другая переменная, которая устанавливает, какой порог следует использовать

$g_bug_resolution_fixed_threshold = FIXED;

Это не работает

Что мне не хватает? Также, если это важно... мои версии помечены: v0.0, v0.1, v0.2 (т.е. с префиксом 'v')


mantis
person Naib    schedule 06.08.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я предлагаю вам прочитать раздел перечислений, в частности

Строки, включенные в перечисления здесь, предназначены только для целей документации.

Таким образом, ваше определение перечисления 70:FIXED на самом деле не соответствует константе FIXED, которая, как вы указали, по-прежнему имеет значение 20, что означает, что $g_bug_resolution_fixed_threshold фактически указывает на ваш 20:REOPEN... Вы можете определить свои собственные константы.

Также обратите внимание, что есть еще один важный порог в этом контексте, $g_bug_resolution_not_fixed_threshold - разрешения выше него считаются разрешенными неудачным способом. По умолчанию установлено значение _UNABLE_TO_REPRODUCE_ (40).

Другими словами, чтобы проблема появилась в журнале изменений, она должна соответствовать всем следующим критериям (ссылка):

  • статус >= bug_resolution_fixed_threshold
  • разрешение >= bug_resolution_fixed_threshold
  • разрешение ‹ bug_resolution_not_fixed_threshold

Обратите внимание, что это стандартное поведение можно изменить с помощью пользовательская функция.

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

person dregad    schedule 22.08.2018