Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Request type is not recognized during csv import

Vincent Naudion May 4, 2020

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

9 votes
Trevor Olexy
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 15, 2021

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
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 28, 2022

Thanks a lot! That worked well for me

Kirk Douglas February 3, 2023

easy one and worked great!

Tyler Krzanowski
Contributor
May 17, 2024

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
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 30, 2024

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

 

1 vote
Whitni Smith
Contributor
March 21, 2022

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
Contributor
March 21, 2022

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

1 vote
Patricia Francezi
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 5, 2020

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 May 5, 2020

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 November 10, 2020

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

 

Best Regards,

Chris

Christian Schnatz November 10, 2020

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

Jamie Schwartz
Contributor
April 25, 2021

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 April 25, 2021

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
Contributor
April 25, 2021

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
Product Admin
TAGS
AUG Leaders

Atlassian Community Events