MySQl code for same:

SELECT p.pname, r.NAME as request_type_name , CONCAT(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
and p.pkey = "PKEY" -- add the pkey or pname to filter
ORDER BY p.pname

Also you need to make sure that the "request type" can be used for this issue type in import. As the logs dont show any warning or error, but after import you see that the request type is still empty due to "This request type is not applicable for current issue type"

any update on this please? Or a workaround that works to import Request Type?

Cheers

JJ just added a comment/question that is similar to my CLOUD experience.  I don't get errors but the value does not import either.

In CLOUD I believe it is "impossible" to query the SQL DB to get the request type ID since we cloud users have not access to a SQL DB, right?

I found the correct format for my database using the SQL and now the file will actually import whereas before it would cause an error. But even with the correct value in the customer request type column, the customer request type is not being set.

@rodneykdsouza for example, zzz/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, here 'zzz' is the project key (the text part of any issue id in lowercase, for example if you have a ticket ABC-23 then it would be 'abc'), the rest with the x's is the request type id, and there is a slash in between ('/').

@moofoo Do you have an update?   

@shashankPincha  what do you mean by "keep everything lowercase" if you are using IDs and not names?

By the way I am using Jira Cloud and and importing data from a non-Jira system but I can easily update the CSV file to whatever is needed by destination Jira.   Nothing is working - except for Bulk Update after import.

@moofoo I've tried the below combinations, nothing works:

PROJECT_ID/REQUEST_TYPE_ID
PROJECT_NAME/REQUEST_TYPE_ID
PROJECT_ID/REQUEST_TYPE_NAME
PROJECT_NAME/REQUEST_TYPE_NAME

Kindly suggest.

Edit:

Use PROJECT_ID/REQUEST_TYPE_ID but keep everything lowercase, it'll work. Thank you,

Hi,

I can see the issue still exists. Yet the real problem is slightly more complicated: the values in CSV file do follow the format of request type that is required for the import to work. And it is not really easy to fix, since adding it would make issues only have valid request type in context of one project.

A workaround for this would be to manually change the request type column' values in the CSV file to follow the format

${PROJECT_NAME}/${REQUEST_TYPE_NAME}

and making sure the project exists and that the issues are being imported to that project.

For example, if the project the issues are exported from is test1 and the request type is Get IT Help, the values in CSV (as exported by Jira) would be just Get IT Help.

But in order for issues to be properly imported to the project test2, the values in CSV should be test2/Get IT Help.

I will update this ticket and we shall discuss this with the team to see what we can do.

Cheers,
Jira ServiceDesk team

Thanks for the fix on this issue, but what exactly IS the fix that was provided.

Can we now use the name of the Request Type ?  It appears that we still need to use something else or more than just the request type name still

I struggled for quite some time with this, but the workaround is to use the request_type_key !!  (and not the request_type_name).

In my case this is a GUID as I created new Request Types. (eg.  "mgxhelpd/87ef1f2e-9f92-47f9-bae7-358f684d62ad".

(btw, you can raise the 1000 bulk limit)