Importing external project via JSON with epic links ignores/overwrites 'updated' date/time

[M_S_]

I am trying to migrate data from an external project via JSON. Obviously, older records have creation and updated date/time in the past and I would like to keep that history. 

When I import data with the "updated" field set, then everything works fine:

{
 "issueType": "Bug",
 "externalId": "XXX-2",
 "created" : "2012-08-31T17:59:02",
 "updated" : "2012-09-12T15:20:12",
 ...
}

I am now also trying to import epics and link issues to them like this:

{
 "issueType": "Bug",
 "externalId": "XXX-2",
 "created" : "2012-08-31T17:59:02",
 "updated" : "2012-09-12T15:20:12",
 "customFieldValues": [
 {
   "fieldName": "Epic Link",
   "fieldType": "com.pyxis.greenhopper.jira:gh-epic-link",
   "value": "Epic Name of Linked Epic"
 }],
 ...
}

This imports the epic links fine, but epics and issues with epic links get their "updated" field set to the import date/time, rather than the specified (historic) date/time.

The issue's history show that "Epic Link" / "Epic Child" gets set with the current date/time.

This is hurting the import a lot. 

Is this a known issue? Is there a workaround for this?

[ASweeten]

Hello M.S.

Thanks for reaching out to us with this inquiry about the updated field's timestamp changing to current time after JSON import of the issue.  Unfortunately, the behavior you are seeing is a known limitation of the import process.  After the issue exists, any number of updates you make are going to trigger the updated field to be changed.  You are in a similar situation as the customer in this other forum post, where they were wanting to make some changes to the imported issues without modifying the updated timestamp. 

The workaround provided for this situation was manual modification of the database by roughly following the directions in this KB article.  It is definitely a few extra steps, but it will allow you to ultimately retain your timestamp history after making all necessary post-import cleanup tasks to get your data in the right place.

Cheers
~Andrew Sweeten
Atlassian Support

[M_S_]

Thank you for your response. I have feedback regarding two aspects:

First, I will look into the described workaround to update the issue's timestamp (here: update) via SQL. This is certainly something I can do.

However, note that after the import is finished, the JIRA feed is also populated with incorrect updates, stating that lots of issues were updated. This is apparently not addressed by the KB article, but may disappear over time when new "actual" changes roll in.

Second - and more important - I am hesitant to accept this as a limitation, where in my use-case it looks more like a defect. I understand that if the importer was updating existing issues, then their timestamps would change - similar to if I manually edited these. 

This is NOT what I am doing. I am importing new issues (none of these exist) in one step. As stated, the process of providing an update timestamp in the import actually works fine ... until an epic link is added. 

Could you explain why the presence of the epic link needs to count as an update, rather than setting any other property on the issue, as well as setting "regular" issue links? 

Again, this works fine (issues with "updated" and issue links):

{
 "projects": [
 {
 "key": "XX",
 "issues": [
 {
 "externalId": "XX-123",
 "issueType": "Bug",
 "summary": "...",
 "description": "...",
 "created": "2011-06-21T09:31:45",
 "resolutionDate": "2011-12-21T16:31:02",
 "updated": "2012-01-27T20:27:16",
 ...
 }
 ,
 ...
 ]
 }
 ],
 "links": [
 {
 "name": "See Also",
 "sourceId": "XX-123",
 "destinationId": "XX-456"
 } 
 ]
}

whereas this does not (same, just with epic link):

{
 "projects": [
 {
 "key": "XX",
 "issues": [
 {
 "externalId": "XX-123",
 "issueType": "Bug",
 "summary": "...",
 "description": "...",
 "created": "2011-06-21T09:31:45",
 "resolutionDate": "2011-12-21T16:31:02",
 "updated": "2012-01-27T20:27:16",
 ...
 }
 ,
 ...
 "customFieldValues": [
 {
 "fieldName": "Epic Link",
 "fieldType": "com.pyxis.greenhopper.jira:gh-epic-link",
 "value": "Epic Name"
 }
 ],
 ]
 }
 ],
 "links": [
 {
 "name": "See Also",
 "sourceId": "XX-123",
 "destinationId": "XX-456"
 } 
 ]
}

So the pure presence of the custom field com.pyxis.greenhopper.jira:gh-epic-link causes the difference in behaviour, although, there is clearly no update after the issue exists.

Specifically the fact that issue links work, but epic links don't is irritating.

That does not seem to be correct. 

[M_S_]

@ASweeten: Haven't seen feedback on this. Do you find my reasoning why I consider the behavior to be a defect plausible? Again, if I were updating issues after the import, then I would understand your point. However, I am not doing that. All the data is in the import.

[M_S_]

@AnnWorley: may I kindly ask you to perhaps look into this one? I am still convinced, this should be considered a bug - if not regarding implementation, then regarding design - but I have not had feedback from Andrew regarding my arguments.

If this one does not get addressed, we will not be able to use the importer with Epic Links. The proposed workaround using SQL does not address all problems created by the importer.