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; } } }

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.

Accepted answers

All comments

Patricia Francezi_iDev_

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

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!

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

ILO Bitvoodoo

Thanks a lot! That worked well for me

Kirk Douglas_jqap36

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!

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-desk