Migrated issues from one project to another project is not showing linked fields details

[Kay]

I migrated issues from a team-managed project to another team-managed project but the information of the linked jira field in the first project is not displaying in the second project when I click on an issue after migration.

Do I have to create another custom field for the new project or how can I resolve this?

[Trudy Claspill]

Hello @Kay 

What is the "linked jira field"? Can you show us an example of an issue in the source project with that field and an example of that field in a migrated issue in the destination project?

[Kay]

I do not have a screenshot of the issue in the source project as I have migrated all to the new project but I have a attached a screenshot of the issue in the new project.

All the jira field in the previous project were populated but it is not showing in the new project. All the issues migrated were done/resolved issues and their jira fields(linked field) were showing in the previous project but not in the new project.

I transitioned an issue back to the source project to get a screenshot of the jira fields but it did not show again even in the source project

[Trudy Claspill]

Hello @Kay 

Some fields are system defined and will be able to receive the data when issues are migrated between projects, like the Summary and Description fields.

Some system defined fields are list fields, like Issue Type and Status, and the ability to receive the data depends on whether or not the list has the same values.

In Team Managed projects it is also possible to reuse Globally defined custom fields (fields that have been set up for Company Managed projects). In that case if the two Team Managed projects reused the same Global custom field, then the data should transfer successfully during the move of an issue.

However, Team Managed projects support creating custom fields that are local to just the one project. When that occurs the data will not move successfully from one project to another, even if both projects have a field with the same name and configuration. Custom fields that are local to the team managed project are unknown to other team managed projects. When you move an issue from one project to another, Jira has no way to determine the destination field for those locally defined fields. The data is deleted during the issue moving process. It won't be recovered is you move the issue back to the original project.

[Kay]

The custom field are global custom field, see example of config. shot

[Trudy Claspill]

Let me know if I am understanding your scenario correctly.

You created a Global custom field named Location. In both the source and the destination Team Managed projects you searched for this global custom field and added it rather than adding a new project-specific field.

Can you create a dummy issue in the original Team Managed project?

And then can you use this API against that dummy issue in the source project and an issue in the destination project to get the JSON for all fields for each of those issues?

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

Look through the data for the Location field. Confirm that for that field the output for each issue shows an identical "customfield_#####" id.

When I added a Global Select List custom field (with a global context) to two Team Managed projects, set the value for the field, and then moved the issue to another Team Managed project, then the value did carry over from the source project to the destination project.

[Kay]

Created a global custom field, the custom field was shown/populated in the issues/tickets while in the source project and issue was resolved/done in the source project. these issue was then migrated to the new project but when I click on the issue, it did not display the details in those custom fields (it shows 'none' as seen in the attached screenshot)

[Trudy Claspill]

The screen image you provided that shows "Default Configuration" is for a field named Location. I don't see a field by that name in the second screen image you provided showing data from an issue.

For whichever field is missing data you think should've been migrated, please use the steps I provided (repeated below) to get the output from an issue in the source project and the destination project, and confirm that the issues actually have the same custom field id in both projects.

Can you create a dummy issue in the original Team Managed project?

And then can you use this API against that dummy issue in the source project and an issue in the destination project to get the JSON for all fields for each of those issues?

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

Look through the data for the Location field. Confirm that for that field the output for each issue shows an identical "customfield_#####" id.

[Kay]

I tried it, it did not work. typed this url -https://<companyname.atlassian.net>/rest/api/2/MI-67/<MI-67>?expand=names

was taking me to bing search

the issue and issue key is MI-67

[Trudy Claspill]

The URL you used is wrong.

https://<companyname.atlassian.net>/rest/api/2/MI-67/<MI-67>?expand=names

It should be:

https://<yourinstanceurl>/rest/api/2/issue/MI-67?expand=names

...and, of course, replacing <yourinstanceurl> with the actual base URL for your instance.

i.e.

https://myCompanyName.atlassian.net/rest/api/2/issue/MI-67?expand=names

[Kay]

Thanks for the correction. I tried it but it says issue does not exist or I do not have permissions. I tried with another issue and the result was same.

P.S I have Jira admin rights

[Trudy Claspill]

What is the actual URL you used?

Did you replace <yourinstanceurl> with the actual base URL for the Jira instance you are using?

Where I used myCompanyName.atlassian.net - that is just an example. You have to use the base URL for your Jira instance there.

[Kay]

tried it with another issue and was able to see the fields

[Trudy Claspill]

You need to get the JSON data for an issue in the destination project and an issue in the source project to compare the custom field IDs. If there are no issues in the source project then you will have to add an issue to that project.

[Kay]

Thank you for your response.

 I have compared an issue in the source project with an issue in the new project and the custom field IDs are the same but the values are 'null' in the new project

[Trudy Claspill]

Can you show us the information from the JSON output for this field?

Can you show us the information from the Custom Fields screen for this field so we can see how it is configured?

Can you confirm for us that the custom field ID you see in the JSON output for that field matches the custom field ID associated with the globally defined field? If you select the Edit option for the field in the Custom Fields list the URL will include the ID for the field:

secure/admin/EditCustomField!default.jspa?id=10009

You have said that the source and destination projects are both team managed. Are they Software or Service Management projects? The screen image that you provided that shows multiple fields with None for the value includes fields that are typically used in Service Management projects.

[Kay]

I have included a screenshot of the JSON output , custom field screen for the field - ticket purpose. the custom ID values are the same

They source and destination projects are team-managed service management projects

[Trudy Claspill]

Thank you!

Those screen images appear to confirm that you are working with a globally defined field, at least for Ticket Purpose, in the Team Managed projects.

The testing I did was with Software projects. I will test again with Service Management projects.

[Trudy Claspill]

I have now tested with two Service Management Team Managed projects, and using a Select List (single) custom field. The data in the field carried over to remain in that field when the issue was moved to the second project.

I'm sorry, but I am not able to recreate your issue.

At this point I recommend that you contact Atlassian support directly:

https://support.atlassian.com/contact/#/

[Kay]

Thank you for your efforts