nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Help needed after upgrade to JIra Server 8.5.5

James Malgieri

Situation: Jira Server upgraded from 8.1.0 to 8.5.5

Problems:

1) For many users the Issue header showing the Project name / Issue Key, Summary Key and Edit, Comment, Assign, etc keys stopped appearing for up to 2 days and just as mysteriously started showing up again. Note: this winking out/in is is still occuring.

2) I was doing a .csv import of the Issue Key, Summary and Comment Body (I was updating the comments of 69 Issues) when I started getting errors about fields in the .csv file that were not actually present. Most notable, I got over 22k errors about "Summary=null". note: each of the 69 Summary fields did contain text.

Has anyone ever experienced anything like this? If so, is there an explaination or solution?

Thank You,

Jim

Accepted answers

Dave Theodore [Coyote Creek Consulting]

Item #1 could be performance related. Did you adjust the JVM heap values? It might be worth increasing the memory.

Item #2, you need to use the following format as described in the CSV doc:

key,summary,comment1,comment2,comment3,...

where

key = The existing Jira issue key ( JRA-123 for example)

summary = The Summary of the issue. Note: whatever you have here will replace what is on the existing issue. Make it the same as what it is now.

comment1, ... = One comment per column. Use the format "date time;author;comment body" if you want to capture the date/time the comment was made and who made it. That username needs to be in Jira or the comment will be made by the user performing the CSV import.

All comments

Dave Theodore [Coyote Creek Consulting]

Item #1 could be performance related. Did you adjust the JVM heap values? It might be worth increasing the memory.

Item #2, you need to use the following format as described in the CSV doc:

key,summary,comment1,comment2,comment3,...

where

key = The existing Jira issue key ( JRA-123 for example)

summary = The Summary of the issue. Note: whatever you have here will replace what is on the existing issue. Make it the same as what it is now.

James Malgieri

Hi Dave,

Re: Item #2 We did an export from a TRAC database. The only way I know of to export the Commments is, after inputting your query, export via the History option. What we ended up with was thousands of comments which were output as a TIME column, User Column and a Comment Column - 1 group per row, with up to 30 comments (rows) belonging to the same Issue.

Time 1 - User A - Comment 1
Time 2 - User B - Comment 2

and so on.

I contatenated the time, user and comment columns for each row into a single column and then did a copy/paste-as-text into a new column which still ended up as 1 column per row.

Time 1;User A;Comment 1
Time 2;User B;Comment 2

Since we thought it was too time consuming to copy/paste each comment group pertaining to a single issue into the usual .csv format

IssueKey;Smmmary;Comment1;Comment2;...;CommentN

we just imported them in to Jira "as is" - which worked and was approved by the customer.

Dave Theodore [Coyote Creek Consulting]

When you first perform the import, there is a screen where you select the time format. That format needs to exactly match the format you are using in the CSV. My guess is that you had a difference in the two and this is what caused your issue. My recommendation would be to include the timezone, as well. We've done some migrations where the source and destination were in different time zones and the result was a shift on the time of each comment. Telling Jira which time zone the comments are in fixes that issue.

Fun stuff! I hope that helps.

James Malgieri

Dave,

You are absolutely correct about that. mm/dd/yyyy h:mm:ss a VS dd/mmm/yy h:mm a

And I actually thougth about that - seeing as how for the 1st time in along time the date/time were in their own column BUT I didn't convert the date/time formats because - up to now, of course - we had whole comment exports (Jira to Jira) where instance1 had a diff date/time format than instance2 and the import alway worked without problem. Jira would point out the format difference and add something like "date assumed but unable to parse date" - but it always worked.

Sigh . . . .

Thanks for your reply.

PS sometimes working with Jira is like "If it is Monday, the date is an even number and the moon is full" enforce <THIS> condition."

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

csv

jira-software

import

upgrade