How does issue events, custom fields behave while importing.

Question

we have 100 projects in source and 500 projects in target.we are planning to Export with the option "Export all project" as single file and then import.

what happens to issue events, issue link types, statuses, priorities, resolutions, workflow transitions, roles after import if they exist with same name on target as the source.

how about custom fields such as CC List (watcher type), Epic Colour,Epic Link,epic name,Epic Status,Epic/Theme,Project CC List,Rank (LOCKED), Rank (Obsolete) LOCKED,Sprint (LOCKED).

please let us know.

Thanks,
Harish.

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

Hi Srinivas,

The mapping from issue types to workflows is given by "workflow schemes". So as long as the workflow schemes have different names in source and target, the other projects in target will not be impacted. If there were name collissions between source and target workflow schemes, then you could rename some of the source workflow schemes. I think that would be a very low impact change for the users.

The process you suggest would certainly avoid overwriting issue types. You could also apply the same approach to priorities, status and resolutions.

Nevertheless, let me insist in talking previously with the users or team leads. However you do it, if issue type "X" means "A" for the teams working in the source instance, but it means "B" for teams using the target instance and tomorrow it is going to mean "B" for everybody... the teams working today in the source instance deserve at least some warning before the change actually takes place.

srinivasp · Answer

Hi Jose,

Thank you for suggestions.. Issue Type is usually associated with workflow and for different projects different workflows might exist for same issue types. I agree it will conflict views when same issue type is configured to different projects having independent workflows. On the target instance we have around 200 issue types and on source around 100, having more than 50 common types. I believe users might not agree for renaming all these issue types and also it takes lot to time to coordinate with all teams about this change. How about manually adding the issue types that are not existing in target and skipping the 'issue type' global object while importing? Does it help avoiding overwriting of issue types? Similar approach  also avoids recreating Priority, Status and Resolution.  Please suggest.

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

Hi Harish,

Transferring the configuration for all the 100 projects in a single XML configuration file is certainly the best option in this situation. As you are about to carry out a huge migration, try it previously in a staging instance, which is an exact clone of target with its 500 projects. Use often the simulated load feature to review and check in advance which actions will be performed.

All global objects, in a real import are created new if they do not exist in the target and modify the existing object if there is a prevously existing object in the target instance that matches the imported object. "Matches" usually means "they have the same name", the exceptions are detailed in the How it works page in the documentation. That page is the best starting point to know these details about the operation of Project Configurator.

All the items mentioned in the question are global objects, assuming you mean "event types" when talking about "issue events". Workflow transitions are not handled independently, but as a part of the whole workflow. You can see the full list of supported object types in the documentation.

Custom fields are special. They can behave as the rest of JIRA objects (as explained above) or you can enable the "smart custom field contexts" option. In this case the import will create separate configuration contexts for the imported projects, so that existing projects are not affected.

All standard custom field types that come with JIRA "out of the box" are supported. About "locked" custom fields: their configuration in both instances will likely be the same so the import should make no changes. Nevertheless, check before in a simulated import.

Last but not least, you are going to merge two instances of JIRA. Suppose this example: in the source instance issue type "Task" means "Simple action on a piece of equipment" and in the target issue type "Task" means "Small development job that is part of a story". Then you have a logical problem. You have to decide how to reconcile those conflicting views before merging both instances. Maybe you can rename "Task" in the source to "Hardware task"? Rename in the target to "Story task"? Perhaps that decision must be made by users or project leads with your assistance...

Regards!