Mantis bug tracker (mantisbt) dynamic enum custom field

Question

I am working on customizing an installation of the Mantis bugtracker, version 1.2.8, to include a dynamic custom enum field on the bug report page. I was able to figure out how to setup the dynamic enum and created the corresponding function to generate its possible values. Here is what I have so far:

Manage -> Manage Custom Fields -> "Legacy Job Number"

Name: "Legacy Job Number"
Type: Enumeration
Possible Values: =legacy_job_number
Default Value: 0
Read and Write access: viewer
Min. Length: 1
Max. Length: 0
Add to Filter: checked
Display When Creating Jobs: checked
Display When Updating Jobs: checked

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;
}

The problem that I am having is that every time I try to submit a new job or update an existing job with the "legacy job number" field attached as-is, I get Application Error #1303, 'Invalid value for field "Legacy Job Number".'

I have tracked the problem down to the timestamp value generated by $t_job_time_code = htmlentities(trim(substr(date('U'), 6, 9))); -- if I remove it, the bug report submits fine. (As you can see, I'm just hard-coding the date in $t_job_code, which is not ideal, but works.)

What I ultimately want to do is postpend a four-digit number to the "legacy job number" string that is 99.99% likely to be unique, as it will be used to identify a specific bug. I thought that using a timestamp would work well for this since it constantly increments, but apparently Mantis does not like that. I have tried a number of variations on this and really don't want to use a random number generated by rand() or mt_rand() since that could still result in duplicates.

Can anyone help to explain (1) why this is happening, and (2) what I might try to fix it?

Many thanks for your consideration and help.

Best, Peter

Answer 1

After completing additional analysis, I have a solid theory about what is causing the problem. I found that I was able to use date("Y") and date("m") to generate a string of the form

201207

When submitting a bug report with this string included, to my surprise it worked fine. The last hurdle was the unique number on the end of the "job code". I found that if I used date('U'), 6, 9 to generate the last three numbers, submitting the bug report failed every time, likely because the last digit changes every second.

If, however, I use date('U'), 4, 3 and submit the bug report, it works. By my rough calculations, the last digit in this string -- 0000001000 in the context of the entire UNIX timestamp --- changes slightly more than every 16 minutes. As I mentioned initially, I needed some way to generate a unique number. I believe that my first method wasn't working because when the bug report page was initially loaded, one "job code" was created. Let's say it was "ADM2012447". But because the Unix timestamp is continually incremented, submitting the bug report resulted in a different 3 digit number being submitted with the bug report, something which Mantis did not like.

Again, this is just a solid theory, not a confirmed fact. Please correct me if I am mistaken.

As a final word on my solution, I realize that if two or more bug reports are submitted in any given 16ish minute window, they are likely to have identical job code numbers. If this does happen, it will likely be pretty isolated based on system use, and even if it's not, Mantis's own unique bug numbering system will allow for easy differentiation.

Thank you to all those who read and considered this problem.