Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-81999

Values mapped to "Issue ID" field upon import will be saved to "External Issue ID" custom field

XMLWordPrintable

    • 460
    • 36

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    • Hide
      Atlassian Update – 13 August 2024

      Hi everyone,
      Thank you for bringing this issue to our attention.
      The current behaviour is that we save the value mapped to Issue ID as a custom field. This behaviour is intentional, as it allows users to update the issues based on the earlier used ID in the CSV file.

      As this is working as expected, we are going to convert this into a Suggestion, to understand the level of interest in making a change. We do not plan to change this behaviour. If it has significant impact on your work, please do not hesitate to reach out to me and share examples to help us understand your use cases better.

      Thank you again for providing valuable feedback to our team!

      Regards,
      Varad Pingale
      vpingale@atlassian.com
      Product Manager, Jira Cloud

      Show
      Atlassian Update – 13 August 2024 Hi everyone, Thank you for bringing this issue to our attention. The current behaviour is that we save the value mapped to Issue ID as a custom field. This behaviour is intentional, as it allows users to update the issues based on the earlier used ID in the CSV file. As this is working as expected, we are going to convert this into a Suggestion, to understand the level of interest in making a change. We do not plan to change this behaviour. If it has significant impact on your work, please do not hesitate to reach out to me and share examples to help us understand your use cases better. Thank you again for providing valuable feedback to our team! Regards, Varad Pingale vpingale@atlassian.com Product Manager, Jira Cloud

      Expected Behavior

      Issues will be imported based on the ID specified in CSV file, which will be discarded after the import process is complete. This scenario is suggested when importing issues and subtasks on Importing data from CSV - Encapsulating JIRA data structure in your CSV file

      Actual Behavior

      The values to the Issue ID field during a CSV import are saved to an "External Issue ID" field. When performing new imports, they will usually not work properly because it's rather difficult to find unique ID values. We should have two different options upon import: "Issue ID" - a value that will only be used within that import process to link issues; and "External Issue ID" for when users want to map the ID that came from the source system.

      Steps to Reproduce

      Try to import a file containing the following data twice, mapping "id" to "Issue ID" and "parent id" to "Parent ID".

      id,parent id,summary
1,,"Test"
,1,"Test sub-task"

      The value set on "Issue ID" will be replicated to the "External Issue ID" value of the issue with summary "Test". Upon a new import, it will skip that issue and register the following on the import log:

      External issue 1 already exists as PROJ-1, not importing.

      Notes

      This may cause problems with sub-tasks links if you use the parent-id field as it will be mapped to the already existing external issue id and not the current CSV issue id.

      Workaround

            [JRACLOUD-81999] Values mapped to "Issue ID" field upon import will be saved to "External Issue ID" custom field

            Michiel Schuijer added a comment -

            Hi,
            I'm arriving here after creating a support request about an issue we encountered with the importer.
            In our way of working, we have some teams who request new projects regularly, to onboard new customers, and to prepare such project they provide the Atlassian team (my team), with several CSV files they prepare in a spreadsheet.
            Each file has its own issue types and relations between them defined in the file, and in some cases links to issues existing already in other projects. The files do not link to issues between each other, each file is self-contained.
            In the past this used to work fine, but recently we cleaned up the abundance in "External issue id" fields, because we had more than 25 of them over time, and since then we see the process is running into the problem described in this 'suggestion': consecutive CSV uploads into the same project, run into problems because parent-child relationships get mixed up, when using the same id's in each file. This even happens when we remove (thrash) the "External issue id" field, which is strange to me and seems like a bug.

            The only workaround we found, is to merge the separate files into one large file, with unique id's in them for parent-child relationships.

            For the business units it is easiest to work from a spreadsheet to update the ~2000–2500 issues they want to be available in the new projects: epic, task and sub-task issues mostly. These should be modified each time, to have small differences per customer, which is easily done from a spreadsheet, not from Jira.

            For Jira admins it is most convenient to use template projects which we can copy and clone, including issues, but that is not so easily done, and only with the help of a commercial app (Deep Clone, for example), and still does not meet the exact requirements from the business units, so we keep at it with the CSV imports.

            That is the use case we have. I'm interested to know of alternatives, or improvements in the way Jira handles CSV imports. Ideally, project admins could do this themselves, without the need for a Jira admin.

            Michiel Schuijer added a comment - Hi, I'm arriving here after creating a support request about an issue we encountered with the importer. In our way of working, we have some teams who request new projects regularly, to onboard new customers, and to prepare such project they provide the Atlassian team (my team), with several CSV files they prepare in a spreadsheet. Each file has its own issue types and relations between them defined in the file, and in some cases links to issues existing already in other projects. The files do not link to issues between each other, each file is self-contained. In the past this used to work fine, but recently we cleaned up the abundance in "External issue id" fields, because we had more than 25 of them over time, and since then we see the process is running into the problem described in this 'suggestion': consecutive CSV uploads into the same project, run into problems because parent-child relationships get mixed up, when using the same id's in each file. This even happens when we remove (thrash) the "External issue id" field, which is strange to me and seems like a bug. The only workaround we found, is to merge the separate files into one large file, with unique id's in them for parent-child relationships. For the business units it is easiest to work from a spreadsheet to update the ~2000–2500 issues they want to be available in the new projects: epic, task and sub-task issues mostly. These should be modified each time, to have small differences per customer, which is easily done from a spreadsheet, not from Jira. For Jira admins it is most convenient to use template projects which we can copy and clone, including issues, but that is not so easily done, and only with the help of a commercial app (Deep Clone, for example), and still does not meet the exact requirements from the business units, so we keep at it with the CSV imports. That is the use case we have. I'm interested to know of alternatives, or improvements in the way Jira handles CSV imports. Ideally, project admins could do this themselves, without the need for a Jira admin.

            Prashanth M added a comment -

            Hello!

            We’re looking to improve the import experience in Jira and are keen to understand how our community is using the Jira Import Module (JIM). If you’ve used JIM to migrate/move data into Jira recently, we’d love to hear about your experience. Please take a few minutes to fill out this survey. Your feedback will help us learn how we can improve your experience in importing data.

            Survey link - https://forms.gle/NYNkmS92r96z42QV9

            Thanks!

            Prashanth M
            Product Manager, Jira Platform

            Prashanth M added a comment - Hello! We’re looking to improve the import experience in Jira and are keen to understand how our community is using the Jira Import Module (JIM). If you’ve used JIM to migrate/move data into Jira recently, we’d love to hear about your experience. Please take a few minutes to  fill out this survey . Your feedback will help us learn how we can improve your experience in importing data. Survey link -  https://forms.gle/NYNkmS92r96z42QV9 Thanks! Prashanth M Product Manager, Jira Platform

              ae05a449a74b Varad Pingale (Inactive)
              jpalharini Joao Palharini (Inactive)
              Votes:
              30 Vote for this issue
              Watchers:
              30 Start watching this issue

                Created:
                Updated: