Request type is not recognized during csv import

[Vincent Naudion]

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.

[Trevor Olexy]

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!

[ILO Bitvoodoo]

Thanks a lot! That worked well for me

[Kirk Douglas]

easy one and worked great!

[Tyler Krzanowski]

This is exactly what I was looking for!  I was racking my brain trying to figure out the issue.

You saved me so much time!  

Thank you Trevor!  

[Christian Scherer]

Hello together,

my issue is solved, Request Type is available when using Import from external system reachable under ACME/secure/admin/ExternalImport1.jspa

Request Type is not available when using ACME/secure/BulkCreateSetupPage!default.jspa?externalSystem=com.atlassian.jira.plugins.jim-plugin%3AbulkCreateCsv

Thanks,

Christian

Hi Tyler,

since you are the last one commenting here: 

When I am asked to map the fields while importing, there is no Jira field e.g. "Request Type" available for me to map the ID to (Issue Type would be available, but that does not fit).

Do you still see that JIRA field "Request Type" in you GUI? Or did Atlassian remove the feature?

Thanks,

Christian

[Whitni Smith]

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)

[Whitni Smith]

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

[Patricia Francezi]

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 :)

[Vincent Naudion]

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.

[Christian Schnatz]

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

Best Regards,

Chris

[Christian Schnatz]

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

[Jamie Schwartz]

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. 

[Christian Schnatz]

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  

[Jamie Schwartz]

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