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

Question

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?

M_S_ · Answer

@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.

M_S_ · Answer

@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_ · Answer

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.