Tested with Mantis 1.1.8, Mantis 1.2.4, Bugzilla 2.20 and Bugzilla 3.6.3 with various combinations - built-in priority vs. custom fields - looks good now

Problem with the configuration file was that Priority value mappings were saved with a key having an uppercase letter, we expected them to be all lowercase when reading so it wasn't possible to match value to the field.

Now all fields are stored lowercase. Fixed similar problem for Severity too.

Renamed ValueMappingDefinition.getName to getExternalFieldId so name will suggest the actual usage.

Attached sample cfg file which shows this problem.

Critical bug found: even if you specify the mapping for the priority (built-in system field) it's ignored by the importer (tried with Bugzilla) and new priorities are created as if "Map as is" were used.

That's a good win-win compromise, Wojtek. Thank you.

I am for allowing the user to decide how map priority and severity - in the same way as we do for resolution: i.e. on the wizard page for built-in fields we should display Mantis/Bugzilla severity and priority on the left and in the combo/editbox on the right built-in JIRA priority + any custom fields.

I think that creating always custom fields for priority and severity is not the best idea - we should utilize as much as possible JIRA built-in priority field.

Hi Roy,
please decide if we're going to import Priority and Severity from Mantis and Bugzilla (we import now Severity as JIRA's Priority). I think it would be best to use custom fields for both of Mantis/Bugzilla fields (check my previous comment on the rationale for this).

I think we've already spoken about this and you were for importing both of them. Don't remember exactly.

I think it would be awesome to fix it for 2.0

Cheers,
Pawel

I think it would be best if we created custom fields for both Severity and Priority - so we would not pollute JIRA Priority values. We can call it like "Original Priority", or "External Priority", or "Bugzilla Priority".

Thank you, Pawel, for raising the issue detailed in my JIRA FAQ comment. I've resolved not to continue the "fight" on the more general semantics issue (i.e. JIRA confusing Severity with Priority), but this singular Mantis import issue can be a deal-breaker for those wishing to move their issue tracking enterprise to JIRA. If, in the absence of a built-in Severity field in JIRA, the Mantis Severity values are getting mapped to Priority, then the Mantis Priority values are getting lost in translation, and really need to be mapped somewhere. My contention was that, since the import plug-in is happily creating a "Mantis ID" custom field and populating it with the original Mantis issue ID, it shouldn't be a big deal to generate a "Mantis Priority" custom field and populate it with the original Priority field values from the incoming Mantis issues.

To your question regarding what former Mantis users might expect the most from the JIRA importer: I'm quite certain it would be not to lose any data on the way over. JIRA really is a new mindset; a new and wonderful way of working issues. Mantis users migrating to JIRA really do need to get over themselves and acclimate to the new paradigm. But working with Priority values in Mantis that are now just not there in JIRA is a bit jarring. The importer really needs to bring them over, too, and find a place for them. My above suggestion seems to be the best course of action...and probably not a big dev hit at all.

Yeah, JIM-147 is similar but that's not exactly what I'm proposing here.

The idea is to import Severity as Severity and Priority as Priority.