Log inSkip to main contentSkip to sidebar
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
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.
Lets say a user wants to import the QA_Contacts field from a Bugzilla instance. As this field cannot yet be imported as per this feature request: https://ecosystem.atlassian.net/browse/JIM-533
So the logical thing to do is to import the field separately via CSV import. The problem here is that the Updated field of the issue will be overwritten with the latest date. This is a big problem for customers who want to preserve historical data on older, closed tickets.
Even if you manually specify the Updated field to a column in the CSV file, the CSV importer does not import those values and the Date Updated field will be set to the latest date, and not to the value you specified in the CSV import.
is related to
JRASERVER-64492CSV Import does not import the "Date Updated" field for existing issues
Gathering Interest
was cloned as
JRACLOUD-81946CSV Import does not import the "Date Updated" field
Another use case: Our team has requested a change in the datatype of a field, because it has a better UI for their workflow (from Checkbox to Multi-Select). I cannot change the field datatype (a separate functionality gap, IMO), but I can create a new field with the new datatype. Obviously if creating a new field, I would like to populate it with the old field's data and delete the old field, so that users aren't having to search across two fields to find relevant historical issues or include two fields in filters, etc. However, to populate the new field with the old field's data will require updating thousands of closed historic tickets that otherwise haven't been touched in years, which is its own data pollution – I don't wish to make these appear to be active/recently active tickets. So, we abandon the whole project and stick with the datatype that has bad UI, because migrating the data would create an even worse user experience.
Katie Nix
added a comment - Another use case: Our team has requested a change in the datatype of a field, because it has a better UI for their workflow (from Checkbox to Multi-Select). I cannot change the field datatype (a separate functionality gap, IMO), but I can create a new field with the new datatype. Obviously if creating a new field, I would like to populate it with the old field's data and delete the old field, so that users aren't having to search across two fields to find relevant historical issues or include two fields in filters, etc. However, to populate the new field with the old field's data will require updating thousands of closed historic tickets that otherwise haven't been touched in years, which is its own data pollution – I don't wish to make these appear to be active/recently active tickets. So, we abandon the whole project and stick with the datatype that has bad UI, because migrating the data would create an even worse user experience.
Importing and post-importing old projects and custom fields from a Server instance to Cloud.
It is not always possible to import all the issues when they do not exist and therefore would be created during the import preserving the "Updated date" (as, at least, someone witnessed in one of the linked issues).
Sometimes, you need to add, tweak, fix data. If you imported several thousands issues already, and you have all the project environment set, maybe even in production already — it is not possible to just delete the project, and start it all over again.
As it was said in... sorry... 23/Jun/0013 1:27 AM, "I don't think we are going to fix this issue ... Circumventing it would require serious hacks and operating directly on DB".
Perhaps. Yet we also have some handcraft to prepare the data for import operating directly on DB and having a small chunk of our time spent just in vain is not a comfortable user experience.
There isn't even a hint under the "Updated date" mapping that it will not work. Like a hint under the "Comment body" which reminds to concatenate date + author + comment into one.
I don't know the architecture of the Cloud Jira to be honest. But wouldn't it be possible to trigger the "Update issue" event after the import actions on that issue, passing datetime from CSV as an argument to the event handler?
Andrey Ivanov
added a comment - - edited Importing and post-importing old projects and custom fields from a Server instance to Cloud.
It is not always possible to import all the issues when they do not exist and therefore would be created during the import preserving the "Updated date" (as, at least, someone witnessed in one of the linked issues).
Sometimes, you need to add, tweak, fix data. If you imported several thousands issues already, and you have all the project environment set, maybe even in production already — it is not possible to just delete the project, and start it all over again.
As it was said in... sorry... 23/Jun/0013 1:27 AM , "I don't think we are going to fix this issue ... Circumventing it would require serious hacks and operating directly on DB".
Perhaps. Yet we also have some handcraft to prepare the data for import operating directly on DB and having a small chunk of our time spent just in vain is not a comfortable user experience.
There isn't even a hint under the "Updated date" mapping that it will not work. Like a hint under the "Comment body" which reminds to concatenate date + author + comment into one.
I don't know the architecture of the Cloud Jira to be honest. But wouldn't it be possible to trigger the "Update issue" event after the import actions on that issue, passing datetime from CSV as an argument to the event handler?
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.
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
When migrating from Server to Cloud not all custom fields are supported because of new Cloud API. So we need to re-migrate them by using of CSV.
But we don't want to touch the 'Updated Date' of more than 100K issues because of this inability.
Please find the solution to bring custom fields values without updating updated date 🙏
With kind regards
Slava
Slava Gefen
added a comment - When migrating from Server to Cloud not all custom fields are supported because of new Cloud API. So we need to re-migrate them by using of CSV.
But we don't want to touch the 'Updated Date' of more than 100K issues because of this inability.
Please find the solution to bring custom fields values without updating updated date 🙏
With kind regards
Slava
Dario B
added a comment - The External System Import has been removed from JIRA Cloud.
Only importing from CSV and JSON are currently supported. Please refer to below KB for details on how to import from CSV:
https://confluence.atlassian.com/adminjiracloud/importing-data-from-csv-776636762.html
Difficulty aside, this is a needed fix. There are problems with importing custom fields with the importer, so it makes sense to import them with csv - except for this problem. Losing information about last modification date is not a good option.
Ignat (Inactive)
added a comment - Difficulty aside, this is a needed fix. There are problems with importing custom fields with the importer, so it makes sense to import them with csv - except for this problem. Losing information about last modification date is not a good option.
I don't think we are going to fix this issue. CSV import supports "updating" and "Date Updated" is automatically set to "now" by JIRA when doing the update. Circumventing it would require serious hacks and operating directly on DB, which would make JIM more fragile.
Wojtek Seliga (Inactive)
added a comment - I don't think we are going to fix this issue. CSV import supports "updating" and "Date Updated" is automatically set to "now" by JIRA when doing the update. Circumventing it would require serious hacks and operating directly on DB, which would make JIM more fragile.
Unassigned
Anonymous
Votes:
53Vote for this issue
Watchers:
63Start watching this issue
Created:
Updated:
{"errorMessages":["jqlTooComplex"],"errors":{}}
[{"id":-1,"name":"My open issues","jql":"assignee = currentUser() AND resolution = Unresolved order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-2,"name":"Reported by me","jql":"reporter = currentUser() order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-4,"name":"All issues","jql":"order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-5,"name":"Open issues","jql":"resolution = Unresolved order by priority DESC,updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-9,"name":"Done issues","jql":"statusCategory = Done order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-3,"name":"Viewed recently","jql":"issuekey in issueHistory() order by lastViewed DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-6,"name":"Created recently","jql":"created >= -1w order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-7,"name":"Resolved recently","jql":"resolutiondate >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-8,"name":"Updated recently","jql":"updated >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false}]
Another use case: Our team has requested a change in the datatype of a field, because it has a better UI for their workflow (from Checkbox to Multi-Select). I cannot change the field datatype (a separate functionality gap, IMO), but I can create a new field with the new datatype. Obviously if creating a new field, I would like to populate it with the old field's data and delete the old field, so that users aren't having to search across two fields to find relevant historical issues or include two fields in filters, etc. However, to populate the new field with the old field's data will require updating thousands of closed historic tickets that otherwise haven't been touched in years, which is its own data pollution – I don't wish to make these appear to be active/recently active tickets. So, we abandon the whole project and stick with the datatype that has bad UI, because migrating the data would create an even worse user experience.