Need this correction of bug as soon as possible !

Thanks

Hi,

I don't feel that this meets the use case that I'm looking to solve for. I'm trying to change the issue type on existing request types in the Admin panel. For example:

1. Request Type A = Issue Type A
2. Replace Issue Type A with another issue type because Issue Type A doesn't fit the needs properly. Let's call this Issue Type B. I do this by removing Issue Type A and adding Issue Type B. 
3. Request Type A shows invalid Issue Type <-- I can't modify the issue type at all to make it be Issue Type B now. 

Can we please address this use case?

Thanks!

Great, This was something we where waiting for. Glad that this is active and working!

Works great and stable.

Any concerns while this issue is still in progress?

Hi 09f95f6ac926 , sorry for the late response. I didn't see an email, could you please get in touch at jgonsalkorale@atlassian.com ? 

Jehan - I emailed you last week (Aug 24). Did you receive my reply?
Thank you,
Glen

Jehan,

Thank you so much for finally releasing this feature. Works great for us. One recommendation on future features - can Atlassian also implement a GLOBAL feature configuration option so as to avoid having to configure each individual project. This way the admin has the option to do at global or project level. 

thanks again. 

Hi 09f95f6ac926, 

It sounds like many of these issues relate to our recent release that updated the create issue experience. Would you be able to email me your instance? I can turn off the flag that surfaces the request type's configuration in the issue create experience to resolve these issues immediately while we make changes to this experience to better suit your needs. 

You can email me at jgonsalkorale@atlassian.com

Looking forward to hearing from you,

Jehan Gonsalkorale

Product Manager, Jira Service Management

Hello Jehan,

While this solution does accommodate the overall requirement, its application is causing our team new struggles.

In the Issue View (or Issue Create) screen, being forced to select a Request Type also forces the screen layout to reflect the customer portal Request Form layout. This causes unexpected results which we are now dealing with.

1. One problem we had to immediately address was some field validation rules in the workflow. Where a field was required upon Create Issue Screen, this field was not added to the Request Form. Now that creating an issue forces use of a Request Type and using the customer portal Request Form screen, we had to remove the validation rule which compromises our teams' process.
   -Practically, one example of many, we have a custom field Responsible Team.
   --When an agent creates an issue they were forced to select the appropriate Responsible Team, thereby putting it into the proper Queue.
   --We cannot add this field to the customer portal Request Form as it isn’t appropriate for customers to see nor fill in.
2. We have many different Request Types and as a result, numerous fields are differently either required, optional, or simply not added to the request type.
   -Previously, the Issue View screen had all the fields in the right margin.
   -Now, having the Issue View screen reflect the Request Type layout, our agents never know where to look for a particular field as it could by anywhere depending on which Request Type is used.
   --One example of many: Due Date field is sometimes optional and added on a Request Form for the customer to fill in. However, on other request types, sometimes an agent will still add a Due Date on a request type which does not have the field available on the Request Form. Therefore, the field is either in the issue view screen (on various Tabs) or on the right margin.
   --The order or placement of the fields on the Issue View screen are also non-standard, again pending the Request Form.
3. On the Create Issue screen, we used to have fields in a certain, logical order. Now, using the Request Type (Form), some fields are prevented from being placed at the top of the form.
   -Eg, Custom field = Responsible Team or Assignee are forced to be a the end of the form, assuming that the logic is: Hidden fields go to the end of the Request Form.
   --This is simply irritating and especially illogical, now that we’ve had to remove its validation (Ref #1 above).
   --The Create Issue screen fields used to be in order: Summary, Responsible Team, Assignee, Reporter, then other fields.
   --NOW, the Create Issue screen fields, forcing Request Type form layout, the fields are in this order: Reporter, Summary, other fields, then at the very bottom—Assignee, Responsible Team and any other hidden fields.

Please consider these complications in the Feature Lab for refinement.
Thank you,
Glen

Hi all, 

Thanks to every one for their patience. We have launched a new feature in the "Feature Labs" section of the project. To access this feature, simply click on "Project Settings" > "Features" and scroll to the bottom. 

If you turn on this feature, whenever an issue is moved or any other action is taken that causes the request type to be lost, the request type field is updated so that it is not null. 

By default, it will select the first request type alphabetically. But you can override the default by setting the request type yourself. 

This is a "Feature Lab" feature which means that it is an early solution that will be refined later on. This feature does work as expected and will be fully supported. 

So, what will change?

1. We are looking to have the default request type selection be respected in the issue create experience within Jira. This is not available now but will be available later. 
2. We will eventually move this out of the Feature Lab and provide a better UX but this will provide an immediate solution to those that need this.

I'd love to know whether this feature meets your expectations, looking forward to hearing from you all!

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

Any update on this? We need it to fulfill our Incident Response requirements.

any update?

can someone please provide status on this feature request? thank you!

Update available?

Any update possible?

Any update on this feature. We would really love to see this rolled out soon. thanks

I assume the following issue is related: https://jira.atlassian.com/browse/JRACLOUD-79309

Any progress on that issue? "Late next month" has passed 

Jehan - thanks for the update. What exactly do you mean by 'if an issue is moved'? Are you saying that if I change the issue type that it will auto-select the request type?

Hi all, 

We are working on a solution to this problem. The first release is planned for late next month where we will auto-select a request type if an issue is moved. We will also roll out improvements to the "Create" issue experience where there is a split select that auto-selects a request type where one is available. 

The first release will autoselect the first request type of an issue type alphabetically but we later intend to let admins configure which request type should be the default per issue type. 

I would love to hear your thoughts on this, hope it helps. 

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

It beggars belief that: 1) Why this needs to be voted on in the first place as it is clearly not a feature request, it is something that should not happen. 2) That this has been open for 7 years!  Come on Atlassian, I resolved the issue with a simple automation routine, surely you being owners and developers can put a proper fix in place in less than 7 years.

The only reason these things don't get enough votes or watchers is because nobody knows they are there.  I didn't know the existence of this request until I have logged the issue as a support ticket so using those numbers as a basis to not do anything is simply not acceptable.

This is causing us issues since moving from Data Center to Cloud. I understand there are architectural differences between the versions but these types of missing functionally (in this case essentially missing a field on a screen), it just baffles me...

The sooner the better on this one

Any updates pls, scheduled for when?

Any updates on this ticket? 

The automation does work unless the issue has an invalid request type assigned to it already. We filter some of our email requests through to another issue type and we have a specific request type for one of the issue types. Unfortunately it does not swap them because the original request type stays on the job even though its logically impossible for it to be assigned. I have reached out to Atlassian about this bug but no answer yet.

EDIT: Atlassian got back to me today, turns out there is an action to re-fetch the issue data so this now works correctly

They've added an option in Automation Rules to change the Request Type on the available triggers / conditions.

Would be better as default functionality on changing Issue Type but in the meantime you can use an Automation Rule as a workaround?

Any update on this ? 

ridicilous.... open since 6 years?? 

Can we please get an update and status of when this issue will actually be planned and worked: Auto set the Customer Request Type when there is only one associated with the Issue Type????

This does not seem to be a complex task for the development team and feels like they should be able to knock this out pretty quickly OR at least provide the ability to set the request type during the move wizard.

thank you

Hi all,

I have struggled a lot with this and managed to get the request type updated by automation. Here are steps how.

 1. Find a field ID of a Request Type field:

      a. You can use API: {YourDomain}/rest/api/3/issue/

      b. And find “requesttype” field and copy the Field Id

2. Then you need to find for your project various request types keys using this API (this uses internal Jira rest API that is a subject to change according to Attlasian)

      a. {YourDomain}/rest/servicedesk/1/servicedesk/request/

/request-types

      b. Replace issue ID  in the URL by an issue ID from your project (to get issue ID use the REST API from step 1)

3. Here write down the portalKey and Key values for each request type that you are planning to use 

4. ** In the automation you can use trigger - update issue type - and then use an advance edit field option to update the request type.

          a. The field update value should consist of Project key + “/” + Key

          b. In the advanced edit field option in the automation use JSON such as following example (use the custom field Id found in step 1):

{
 "fields": {
 "customfield_10010": "TEST/default006"
 }
}

This is broadly explained here https://confluence.atlassian.com/jirakb/how-to-set-the-request-type-when-creating-an-issue-using-jira-core-rest-api-in-atlassian-cloud-974366000.html

This is a long term major issue for us as well as employees tend to forget to reset the Customer Request Type after an issue change. Currently I am subscribed to a filter to detect any missing Customer Request Type values on Jira Serivce Mangement issues and then manually fix them. This is annoying and I really would appreciate having this feature to be able to be set within an Automation rules.

Voted for it!

running into this now..  this platform needs wayyyyyyy more agility in the way we can change things.

This is so urgent! When issue type is changed, the request type becomes a blank field. And customers won't receive the "customers notifications" emails when a public comments is added, for example. This is so dangerous! Please, Atlassian, give attention to this problem. Agents won't notice the problem and customers stop receiving notifications!

 Another basic functionality that is missing that I'm voting for among so many...

Based on the roadmap it looks like request type will be editable in automation in Q2 this year so there is light at the end of the tunnel. I think it will make a great impact and make things a lot simpler.

https://www.atlassian.com/roadmap/cloud?status=comingSoon&selectedProduct=jiraService 

Workarounds are great, but should not be necessary. This should be basic, out-of-the-box functionality.

Edit: cannot add screenshots here, trying to explain via plain text.

The second part can be seen by a reply i wrote here: https://community.atlassian.com/t5/Jira-Service-Management/Automate-Request-Type-change-upon-Issue-Type-change/qaq-p/1271735#U1691289

Hello everyone,

we found a workaround for this limitation.

The request type cannot be changed via automation or be included on a transition screen, however it can be changed via transition by utilizing the post-function "Update Issue Custom Field" and use it to set a value to field "Request Type".

You will need to get the know the technical name of the desired request type as you cannot inform the label the customer sees (it will just empty the value of your field)

For this you can either reach out to Atlassian to check your Clouds database or use the following solution:

Use post-function "Copy Value from Other Field" and configure it to copy value from field "Request Type" to any Free-Text-Field. Now the technical name can be extracted from your designated text field.

To use this with automation you could set up a rule that triggers a self-looping transition which has this post function.

Best Regards

Dan

Jehan - any status on this? thanks

This missing feature makes it a nightmare to manage omni-channel requests.  I also have automations that create tickets in specific scenarios and I can't select the request type.  The fact that you tie the user interface to the request type and it won't update makes it an awful experience for our CS agents.  When dealing with high volumes (1000+ requests/day), it adds a drop down selection and a screen refresh for every single transaction.

Also very eager to have this, glad to hear it is planned.

Jehan - thanks for the update. I am curious though - what are the other higher priority stories/issues your team is working now which is causing the delay on this?  Why can't the 'request type' field be added to the change issue type wizard so that the user can automatically set it when changing issue types and setting any other fields. This seems like a fairly easy implementation to me AND should be high priority due to the new issue layout and several other areas of the system trigger off of the request type and what it is set to. Thanks 

Hi all, thank you very much for your interest here. We are looking to solve this soon but won't be able to focus resources within the next few months. It is, however, an item that is assigned to a team and we intend to get onto it once we wrap up our current initiatives.

I know this is not the news you want to hear, but very keen to avoid overpromising. That said, this will be worked on in the medium-term.

Kind regards,

Jehan

We would like this as well, please!

This is a bug, not a suggestion/feature!

IS there any update on this request? Can you add a step to the move issue wizard to allow the user to set the request type when remapping fields? 

Type should be Bug, not Suggestion.  Failing to update the Request Type manually (the only feasible way) after changing Issue Type, leads to a multitude of strange behavior.

By the way, If an issue is created outside the Portal (by API or by an Agent) without a Request Type, "Reply to Customer" will not send an e-mail to the customer! This can lead to some pretty disastrous customer interactions to say the least.

It is sad that I have to use legacy automation to accomplish this. All of the features of legacy should of been mirror with the new automation. The rationale for leaving this out I cannot think of any reason for it.

by the way, try to use the legacy automation on project level (not the new automation) to change the request type

+1

I dont understand why the missing of such important information while copying or changing issue type is not rated as a bug. 

by the way: when changing the issue type, the request type is NOT lost... the old request type remains but not visible.! clearly a bug!

Adding this feature would make my life incredibly easy. 

Hi Urmas,

We are facing same issue here with the request type being cleared when changing issue type.

I've tried your proposal with Jira automation, but unfortunately, it seems change of request type can not be automatized. through Jira automation.

The error below is in French, but says that there is no API in Jira Service Desk for changing Request Type.

Jira Team, please implement this change request, or fix the missing API.