You need to define strings to match the enumerations too.

Reference http://www.mantisbt.org/docs/master-1.2.x/en/administration_guide.html#ADMIN.CUSTOMIZE.ENUMS

I left out the string enumerations for brevity, sorry. Here they are:

<?php
switch( $g_active_langauge ) {
default:
$s_status_enum_string = '1:todo,2:inprocess,3:toverify,4:done';

            $s_todo_bug_title = 'Mark task as needing to be done.';
            $s_todo_bug_button = 'To do';
            $s_email_notification_title_for_status_bug_todo = 'The following task needs to be done.';

            $s_inprocess_bug_title = 'Mark task in progress';
            $s_inprocess_bug_button = 'In progress';
            $s_email_notification_title_for_status_bug_inprocess = 'The following task is in progress';

            $s_toverify_bug_title = 'Mark task ready for verification';
            $s_toverify_bug_button = 'Ready for verification';
            $s_email_notification_title_for_status_bug_toverify = 'The following task is ready for verification';

            $s_story_bug_title = 'Mark task done';
            $s_story_bug_button = 'Done';
            $s_email_notification_title_for_status_bug_story = 'The following task is DONE';
    break;

}

I've since added 50:dummy to my enums, just so I could get those tickets out of that state. And since I've added 50:dummy, my tickets now assign to the "todo" state by default, as they were supposed to.

My problem wasn't with @50@ not getting a string associated, it was that it was there at all. When I redefined my enums, I didn't include 50 or 90 anywhere, but they still showed up.

My guess is that the '50' and '90' states are hardcoded somewhere. I haven't tried grepping the source to find them.

Didn't check, but overriding the defaults of the following options in your config_inc.php should fix the issue.

$g_bug_submitstatus = NEW;
$g_bug_feedback_status = FEEDBACK;
$g_bug_closed_status_threshold = CLOSED;

Check config_defaults_inc.php for more details.

Questionable
4c) bug_assigned_status = 1
4d) bug_readonly_status_threshold = 1
4e) bug_reopen_status = 1
4f) bug_resolved_status_threshold = 1

Maybe better
4c) bug_assigned_status = 2
4d) bug_readonly_status_threshold = 4
4e) bug_reopen_status = 1
4f) bug_resolved_status_threshold = 4
+
4g) bug_submit_status = 1
4h) bug_feedback_status = 1
4i) bug_closed_status_threshold = 4;

Unless I'm seriously (mis)understanding the purpose of the interface, the settings I have in place here should accomplish the same thing, right?

And, like I said, since I added 50:dummy to the enum set, I was able to rescue the issues, and new issues properly get assigned the 'todo' status.

This isn't about something impeding my workflow; I've already got a workaround in place. I'm reporting this because of the apparent bug in Mantis that required the workaround...

(Edit: That's misunderstanding...)

I am quite sure that you will get some more problems with your configuration.
I recommend to try my "Maybe better" setting (without any dummy).

I'm reporting this because of the apparent bug in Mantis
It might be a MantisBT bug (something hardcoded as mentioned by you) if you still get the issue after using my recommended settings.

Maybe it's just a wrong configuration.
I have no time to check it at the moment.

OK, I'll give the new settings a try.

mikemol,

You did not provide any feedback; I am therefore resolving this issue as "no change required". Feel free to reopen the issue at a later time.