Required fields in Service Desk Request types not working

Teodor_junivk

Jira Cloud

Service Desk Project

Error:  When trying to adjust Request Types so that certain visible fields are Required.

In detail: admin will click the desired field to be required, select Yes and hit update to confirm the choice.

 

Then nothing happens and the choice is not confirmed, when the page is refreshed/saved, the field is not set to Required.

This does not affect the summary and description fields, which can be selected as required. Custom fields added to the issue type screen for this specific service desk request cannot be made required. How can I resolve this? Is this something to do with the field configuration/custom fields?

 

Please note that this issue only affects the request type which is used for the Email Requests. When other Request types are created with custom fields, I can make any field within that request type compulsory.

 

Any help much appreciated

Vasi

Hey Teodor,

I was about to suggest you to contact Support, however the last detail cleared things pretty well.

So by design Service Desk cannot distinguish more than two fields in the email: summary and description. These would be subject of the email and its content.
As a result, it is not possible to set more than 2 "required" fields for a request type that is used for email channel as Service Desk won't be able to set those extra fields during ticket creation.

In your case, when we are trying to set another "required" field, error should be like:

This request type is used by the email channel and Jira Service Desk cannot fill in field Component/s automatically from emails.

However nothing is actually happening and no errors are shown.

I found a bug that explains this behaviour:
https://jira.atlassian.com/browse/JSDCLOUD-6047

Summarising the above:
It is expected that you cannot set extra "required" field for a request type that is associated with email, however it was wrong that there are no errors shown.

Hope this helps and explains your case.

Thanks,
Vasily