Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Help needed after upgrade to JIra Server 8.5.5

James Malgieri
Contributor
July 29, 2020

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

 

1 answer

1 accepted

1 vote
Answer accepted
Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 29, 2020

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.

James Malgieri
Contributor
July 30, 2020

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.

  1. Time 1 - User A - Comment 1
  2. 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.

  1. Time 1;User A;Comment 1
  2. 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]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 30, 2020

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
Contributor
July 30, 2020

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

Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 30, 2020

Heh. Yeah. This stuff is messy business.  Many systems export field dates in one format and comment dates in a different format too. In that case, you have to separate the comments in to a second import of post-process the dates to put them in the same format as the field dates. Wait until you do sub-task associations! Fun times!

James Malgieri
Contributor
July 30, 2020

re: sub-tasks - Actually, if we have an Issue ID and a Parent ID it works out. 

However, links are a pain - but if we have an ID or any kind that we can grab onto (usually the DB record ID) we'll create a Custom temp field for the ID and for each type of link and then use a SIL script (not written by me) to relink everything.

I'm sure we'll be coming up against the sub-task associations you're thinking of soon enough and then I'll be back on here begging for help - lol.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
VERSION
8.5.5
TAGS
AUG Leaders

Atlassian Community Events