Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,359,884
Community Members
 
Community Events
168
Community Groups

Request type is not recognized during csv import

Hi, I have multiple issues during CSV import :

+ Ticket request type value is not recognized and produce an error :

Cannot add value [ [Technical support] ] to CustomField Request Type in Issue 

Technical support request type is exact name of the value exported in CSV file from Jira.

+ Tickets are imported as Status = Closed + Resolution = Done + Resolved date in the past, but SLA are calculated based on import date, why?

Thanks for help. I have 14 customers to migrate and a bit afraid right now :( SLA calculation is needed for global reporting.

3 answers

I found it slightly odd that the requestType was a custom field, but anyways, I was able to solve this by going to the request type config page, clicking into the edit view of the request type, and getting the ID of the object from the URL path. Then in the csv for importing, I just set the ID for the corresponding request type. Just the integer, no strings. And amazingly it worked as expected. hope this helps someone!

Thanks a lot! That worked well for me

Just as an update -- 
Context - we have 20 CRT and we migrated a help desk from JIRA Server to JIRA Data Center and this is what worked for us. 

There is some manual work here but having the CRT information was imperative to the migration, if they didn't have that then we couldn't migrate. 

We used Scriptrunner to run this script in the console for where the new project would be - 
import com.onresolve.scriptrunner.db.DatabaseUtil
DatabaseUtil.withSql('Jira DB Connection') { sql ->
sql.rows("""SELECT p.pname, r."NAME" as request_type_name , (po."KEY" || '/' || r."KEY") AS request_type_key
FROM "AO_54307E_VIEWPORT" po, "AO_54307E_VIEWPORTFORM" r, project p
WHERE po."ID"=r."VIEWPORT_ID" AND po."PROJECT_ID"=p.id
ORDER BY p.pname""")
}

It output all of the request type IDs for us for the new project not the source project, I then did a page search for the project that I needed the IDs for and then I matched them up with the CRT names and using Excel used a relational vlookup table to match the field values in the csv file and then imported using "external import" and we were good to go. 

The CRT ID would replace the CRT field in your CSV file -- the format would be 
$projectkey/crt-id
example: arlhelp/92370ba6-f16a-4459-a289-58d77940f56r


This is the JSD Server ticket that helped the most - https://jira.atlassian.com/browse/JSDSERVER-1335  

 

You're looking for values request_type_key (from Scriptrunner output) or data-key (from XML file)

The CRT ID would replace the CRT field in your CSV file -- the format would be 
$projectkey/crt-id
example: arlhelp/92370ba6-f16a-4459-a289-58d77940f56r

Hi, 

If you are migrating from Server to Cloud, You will need to map the old Request Type ID to the new one in cloud, and convert your CSV. 

From the SLA, bulk import is like creating new issues, so the SLA starts from the creation.

If you are running a brand new cloud instance, I would suggest to use the backup import feature in cloud. 

You can backup from server, donwload a XML and import in your instance. 

https://confluence.atlassian.com/adminjiraserver071/backing-up-data-802592964.html?_ga=2.27475002.725920450.1588417440-1804366156.1576771644

Check your server instance to verify if the docs are correct for you. 

Check also this doc:

https://confluence.atlassian.com/adminjiracloud/importing-issues-776636788.html?_ga=2.23755836.725920450.1588417440-1804366156.1576771644

 

Be aware that you need to understand carefully the steps. 

 

If my answer provided clarity for you, I would ask to accept it :)

Thanks for reply :-)

 

That doesn't clarify me yet, I explain.

Concerning Request type, csv export has been done from cloud, and I'm trying to import this csv, considering some other fields values. Request type should be imported like it has been exported.

 

Concerning my SLA issue, I don't use bulk import, but CSV import, that's 2 different things. Bulk use import date as creation yes, but CSV use created date from csv issue lines. That's necessary cause my tickets have been created and solved some months ago.

 

I saw on forums that's there is an issue with SLA count from CSV import, it doesn't stop cause not triggered by import action (resolution changes, resolved date... ) I'm looking for a workaround in order to have correct SLA calculation = resolved date - created date. For reporting purpose.

Hi @Vincent Naudion  did you ever managed to import your request type properly? 

 

Best Regards,

Chris

Used a bulk change of all imported issues to change the requestType to the new value...

I'm having this same problem and I cannot use the work around like Christian mentioned because I have several different request types I need to import. Why is this failing when the request type in my csv matches exactly how I would search for it using JQL --- as in it has the request type name plus the project key in parenthesis and it's still not working and getting same issue as Christian originally reported. 

Hi Jamie,

maybe you can import each request type on it‘s own, bulk change the type afterwards and then do the next one...pretty annoying but the only option I see.

regards,

chris  

Good point. Looks like this will be my Sunday Funday :) Thanks Christian. Hopefully Atlassian can get this fixed soon. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

An unofficial way to monitor a JSM mail handler for errors

...eturns true if any content is returned for the webResponse.body.data.first s...

660 views 3 19
Read article

Atlassian Community Events