cc: ialexeyenko maybe this bug that takindele is describing is something that Jira bugfix team wants to look at. 

takindele please read my comment here https://jira.atlassian.com/browse/JRASERVER-64415?focusedCommentId=966592&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-966592

It is really hard to say if this is a bug. The behaviour is that when importer create new custom field it puts it into project context. 

When you then import to another project you cannot select the previously created custom field as it is not visible to the next project.

Workaround here is to manually change context of custom field to global after first import or create custom fields manually with global context before using any importer. 

I don't think we should be messing with custom fields context from inside importer especially if the custom fields are created manually not by the importer itself.  

Hello irene

Yes you are correct - Redmine Importer only creates (and tries to reuse) text Custom Fields - the reason for that is the limited Redmine REST API. There is no way to determine the field type - Redmine is only returing text values.

This has changed in Redmine 2.4+ (Redmine REST API in 2.4) - since this version we have the possibility to check Custom Fields definitions. Unfortunately that's also not yet supported - JIM-1140.

ajakubowski, the workaround you've described does not work for my case. I've created custom fields in Global context before the import, however, the importer still creates duplicate fields for the project context. It happens for all the fields where type is not text.

I have a support ticket with screenshots and import log here: https://support.atlassian.com/browse/JST-85865

As examined this issue affects other importers as well.

There are two aspects of this issue:
1. When during import new custom field is created it is assigned only to currently selected (those that are imported to) projects. Then in second import one cannot select those custom fields when importing to different project. This is intended behaviour.
2. When one select to import issues to existing project mapping to fields associated with this project should be possible - but currently is not - this is the actual bug.

The workaround for this is to create first (or change those created during first import) custom fields and assign them "Global context" instead of project context.