JIRA Project configurator issue - mixed case statuses

[Roy Chapman]

On the SOURCE instance I have a status called "Signed off" on the DESTINATION instance I have a status called "Signed Off".  The PC creates the project configuration with non complaints (it doesn't create the status because this already exists), but a subsequent project import fails with

The status 'Signed off' is required for the import but does not exist in the current JIRA instance.

Can the PC detect mixed case duplicates and flag as an error in teh verify step? 

[José Marañón [Awnaba Software S.L.] · Accepted solution]

I suppose when you say "a subsequent project import fails" you mean you were using JIRA Project ImportTool to bring project data into the new instance.

In that case, I think this is an inconsistency of JIRA Project ImportTool, because JIRA treats names of statuses and other issue constants in a case independent way. Most important, if you have in JIRA a status called "Signed off" and you try to create another one with name "Signed Off" JIRA will reject it saying that there is another status with the same name.

cannot-create-status-with-different-case.png

I think Project Configurator could detect this condition and warn the user, but that would not solve your problem, unless you could remove the existing status in the target instance before the import. This would not be possible if that status was being used in workflows.

I think a good workaround would be to edit JIRA XML backup files and "fix" the status names there. AFAIK, the status name only appears once in the entity for the status. This is a line in "entity.xml", one of the files that make up the backup .zip compressed file. It appears like this:

<Status id="10000" sequence="7" name="Signed off" description="A new status" iconurl="/images/icons/statuses/generic.png" statuscategory="2"/>

[Roy Chapman]

You are correct in saying that the issue is the data importer, not the Project Configurator. I managed to fix this by renaming the status in the source and re-export the data so that it used this name. It would be helpful if these types of conflicts could be identified during the PC import phase as a warning.