Mantis bug tracker (mantisbt) настраиваемое поле динамического перечисления

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

Управление -> Управление настраиваемыми полями -> «Номер прежней работы»

Имя: «Номер устаревшего задания»
Тип: Перечисление
Возможные значения: = legacy_job_number
Значение по умолчанию: 0
Доступ для чтения и записи: просмотр
Мин. Длина: 1
Макс. Длина: 0
Добавить в фильтр: отмечено
Отображать при создании заданий: отмечено
Отображать при обновлении заданий: отмечено

custom_functions_inc.php

function custom_function_override_enum_legacy_job_number() {
    $t_project_name = project_get_name( helper_get_current_project() );
    $t_job_time_code = htmlentities(trim(substr(date('U'), 6, 9)));
    $t_project_description = project_get_field( helper_get_current_project(), 'description', '' );

    $t_project_description = "$t_project_description";
    $t_job_code = $t_project_description . "2012" . $t_job_time_code; 
    $t_possible_values_array = array("", "$t_job_code");

    $t_possible_values = implode( '|', $t_possible_values_array );

    return $t_possible_values;
}

Проблема, с которой я сталкиваюсь, заключается в том, что каждый раз, когда я пытаюсь отправить новое задание или обновить существующее, добавив поле «Номер прежнего задания» как есть, я получаю ошибку приложения № 1303: «Недопустимое значение для поля« Устаревшее задание » Число".'

Я отследил проблему до значения метки времени, созданного $ t_job_time_code = htmlentities (trim (substr (date ('U'), 6, 9))); - если я удалю его, отчет об ошибке отправляется нормально. (Как видите, я просто жестко запрограммировал дату в $ t_job_code, что не идеально, но работает.)

В конечном итоге я хочу добавить четырехзначное число к строке «номер прежней работы», которая с вероятностью 99,99% будет уникальной, поскольку она будет использоваться для идентификации конкретной ошибки. Я думал, что для этого подойдет использование временной метки, поскольку она постоянно увеличивается, но, очевидно, Mantis это не нравится. Я пробовал несколько вариантов этого и действительно не хочу использовать случайное число, сгенерированное rand () или mt_rand (), поскольку это все еще может привести к дублированию.

Может ли кто-нибудь помочь объяснить (1) почему это происходит и (2) что я могу попытаться исправить?

Большое спасибо за ваше внимание и помощь.

Бест, Питер


php customization mantis
person pmlodzik    schedule 25.06.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

После завершения дополнительного анализа у меня появилась прочная теория о том, что является причиной проблемы. Я обнаружил, что могу использовать дату («Y») и дату («m») для создания строки формы

201207

При отправке отчета об ошибке с включенной этой строкой, к моему удивлению, он работал нормально. Последним препятствием был уникальный номер в конце «кода вакансии». Я обнаружил, что если бы я использовал date ('U'), 6, 9 для генерации последних трех чисел, отправка отчета об ошибке не удалась каждый раз, вероятно, потому, что последняя цифра меняется каждую секунду.

Если, однако, я использую date ('U'), 4, 3 и отправляю отчет об ошибке, это работает. По моим приблизительным подсчетам, последняя цифра в этой строке - 0000001000 в контексте всей временной метки UNIX - меняется чуть чаще, чем каждые 16 минут. Как я уже упоминал вначале, мне нужен был способ сгенерировать уникальный номер. Я считаю, что мой первый метод не работал, потому что при первоначальной загрузке страницы отчета об ошибке был создан один «код задания». Допустим, это был «ADM2012447». Но поскольку временная метка Unix постоянно увеличивается, отправка отчета об ошибке привела к отправке другого трехзначного числа вместе с отчетом об ошибке, что Mantis не понравилось.

Опять же, это просто прочная теория, а не подтвержденный факт. Пожалуйста, поправьте меня, если я ошибаюсь.

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

Спасибо всем, кто прочитал и рассмотрел эту проблему.

person pmlodzik    schedule 04.07.2012