Subtask with partent-id from export do not link to the right parent story (csv import system)

[Mark Bakkers]

From my export out of JIRA i got the following info:

Story - PR13P-5058 - 42847 (issue id) - IH Lozen van spuiwater uit recreatieve visvijvers
Sub-task - PR13P-5184 - 42973(issue id) - 42847 (parent id) - Ontwerp checken
Sub-task - PR13P-5185 - 42974(issue id) - 42847 (parent id) - Bouw checken
Sub-task - PR13P-5186 - 42975(issue id) - 42847 (parent id) - Test checken

I tried to create more subtasks for story PR13P-5058 by doing an csv import

with subtaks - empty - issue key - empty (issue id) - 42847 (parent id) - new subtask.

This always worked. But now it seems the new substaks is created under the wrong story PR13P-5038 which in my export has parent id = 42827 (is seems almost the same except for one 4=2. 

When i search for 42847 with external- issue-id in te jira search, it finds: PR13P-5038.

What is wrong here, why is the parent id in the export not matching the same story in the search with external issue id? 

How can I connect my new subtask to the right story PR13P-5058?? Help spend a lot of time already....

[Andy Heinzer · Accepted solution]

Hi Mark,

If I understand correctly here it sounds like there is a problem in regards to the way in which subtasks are being mapped to the parent issue when being imported from a CSV file.

Could you please let me know more about your Jira instance?  For example, this question is tagged as Jira Server, could you let me know what version of Jira this is?

I would also be interested to see if you run the following SQL query against your database to see the results here.

select * from jiraissue where id=42847;

This should only return a single issue, but I'd be interested to see what the issuenum is for this. 

I am also interested to learn more about the source and destinations here: Are these the same Jira instance?  Or is it possible you might be working with two different Jira sites in order to somehow synchronize data between these two sites?

[Mark Bakkers]

Thanks for your kind reply and I will ask our dba-er to run the query it would be interesting to see which result we get back. I als will get back on the Jira version and where the server is running?

We use one jira/confluence instance so no data is synchonised.

Thanks

[Mark Bakkers]

We use JIRA  v8.12.

The query on data base give result:  id | pkey | issuenum | project | reporter | assignee | creator | issuetype | summary | description
| environment | priority | resolution | issuestatus | created | updated | duedate | resolutiondate | votes | watches | timeorigi nalestimate | timeestimate | timespent | workflow_id | security | fixfor | component | archivedby | archiveddate | archived -------+------+----------+---------+---------------+----------+--------------+-----------+---------------------------------------------------+-------------------------- --+-------------+----------+------------+-------------+----------------------------+----------------------------+---------+----------------+-------+---------+---------- ------------+--------------+-----------+-------------+----------+--------+-----------+------------+--------------+---------- 42847 | | 5058 | 10315 | JIRAUSER11901 | | mark.bakkers | 10001 | IH Lozen van spuiwater uit recreatieve visvijvers | Inv. Besluit Afdeling 2.1 6 | | | | 10000 | 2020-07-10 17:41:10.434+02 | 2020-07-10 17:41:10.434+02 | | | 0 | 0 |
| | | 51060 | | | | | | N

So in the database the right story PR13P-5058. But somehow with the import it went wrong, can browser caching be an issue with imports?

[Mark Luijendijk]

Taking over from Mark Bakkers.

The exact version is 8.12.1

[Andy Heinzer]

Thanks for the additional information.  I walked back through the steps in Importing data from CSV and specifically the section on creating sub-tasks.  And I think I can see a scenario that would have caused this behavior now.

It looks like you are re-using the actual issue id here for the parent issue (42847), however there really is not a need to use that value here.  The importer is not actually mapping to the true issue id of the issue in Jira.  If the importer is updating an existing issue, it has to do that only when mapping to the actual issue-key (PR13P-5058).  But that said, the CSV importer is looking at the issue id field here and then using that value to store a value into the 'External Issue Id' custom field here. 

This could explain why another issue in your system already has that value for that field and in turn this could be causing future sub-tasks to map to an unexpected parent like so here.  There is a related bug to this were we document this behavior over in JRASERVER-66150.  And another over in JRASERVER-64699.

I would try to either clear that 'External Issue Id' field after a CSV import OR when importing a new file I would try to make sure that issue id in my file is unique to that entry and then update the parent_id values to match it for the sub-tasks.

Try this and let me know if you have any questions about this.

Andy