Yes i found the solution. Actually there are two imports.
One is 'Bulk Create CSV Import' and other is 'External CSV Import'
When i used the external import; i found all the missing fields there.
Please see below screenshots for more details.
I do not have an answer to this, but this relates to an ongoing thread I posted a while back. If they were to ever add this functionality, being able to control comment visibility at the bulk import level would also be nice...
I have been trying to resolve this in recent days. A CSV with comments with date and time (12 hour clock) imported all times as AM - not good. That was using "dd/MM/yyyy HH:mm a" as the date import mask in JIRA.
In the end, I converted all the comment times in the CSV to 24 hour format and removed the AM PM suffix using search and replace in Excel. So you end up with this structure (note the space between date and time):
10/10/2019 16:45;<userid>;comment detail
The date mask in JIRA was set to "dd/MM/yyyy HH:mm"
This worked perfectly, gave the comment the correct time and date and attributed it to the correct user (provided the user ID maps to a live account).
My userID was actually mapped to a staff number but yours will be different.
Might hopefully be of help to someone. Amending all the comments was painful but can be automated with a bit of creative thinking to identify a unique string then just search and replace.
There is a bug in the documentation that indicates that the comment date format is always "dd/MM/yyyy HH:mm" (as Andrew shows above), but that is not always the case. The format is actually whatever you decide when you setup the import initially, so comment date format must match the format of all other date fields. The default is actually:
dd/MMM/yy h:mm a
Even though, no matter what date format you choose, the import wizard always shows the following syntax while mapping a field to the Comment Body field:
To preserve the comment author/date use format. E.g. "05/05/2010 11:20:30; adam; This is a comment."
I've created a ticket with Atlassian to update their documentation, including the message displayed above, accordingly.
I'll update this with a non-support issue number once they provide one (either existing or new).
Please vote for this issue to ensure that it gets enough attention so that the Atlassian documentation is updated at the very least or, preferably, so that Atlassian updates the importer to properly reflect the expected date format based on what you chose at the start of the process:
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event