Hi everyone,

Thank you again for your feedback. We have now fixed this issue, and will be closing this bug.

As the original Request Type is still stored on the Issue (despite the Issue Type and Request Type not matching), we have changed the behaviour so that the original Request Type will now show on the Issue View (as it does in Filters & Queues).

On Issue View, we have highlighted that the Request Type is Invalid so that users can select a valid Request Type for that Issue Type - this will then update the Request Type value on the Issue, and the new value will show in all views (Queues, Issue View, etc).

We have identified that the Move Issue/Change Issue Type experiences are the most common cause for Issues ending up in this state, and are looking into this as a separate item of work. Please follow Update request type upon issue type change for further updates.

Thank you,

Rachel Crossman

Senior Product Manager - Jira Service Management

Hi everyone,

This is Rachel Crossman from the Jira Service Management Product Management team. Thank you for your patience as we've looked into this bug. 

On further investigation, we have found that the original Request Type is still associated with the Issue (in the database), but that the Issue Type & Request Type are not connected in that project, and are an "invalid" pairing. Because they are an invalid pairing, it is causing some inconsistencies in what is shown across different product experiences (Issue View & Portal; vs Issue Navigator and Queues). 

To resolve this inconsistency, we will be updating the Issue View and Portal Views to show the original Request Type, so it will match what is shown in the Issue Navigator, Queues and other JQL-based experiences. We will be including some UI prompts on Issue View to indicate that the Request Type is Invalid and that it needs to be updated. We have decided to do this, rather than hide the Request Type in the JQL-based experiences as suggested on this bug, as it is true to the real state of the database. 

I will provide an update here again soon, with a timeline for the resolution. 

We are looking now into solutions to the root cause of this problem, and how we can better prevent this Invalid state from occurring, as well as more ways to alert and surface any Issues that are in this state. 

If you have any questions, comments, or feedback about this issue and our proposed solution, please do reach out here and I'd be happy to book in time to chat!

Kind regards,

Rachel

Hi everyone,

This is Rachel Crossman from the Jira Service Management Product Management team. Thank you for your patience as we work on investigating this bug.

Looking into this, we've identified complexity in the potential solutions, as there could be unintended flow-on impacts to other areas of the product experience related to request types. We're continuing to investigate safe resolutions, and we will update here again in the new year as we dive deeper into the options.

Thank you again for your patience!

Rachel 

Hi all,

Sorry for the delay here, we are reviewing top priorities for our team and will see when we can fix this bug. Apologies for the inconvenience, I know this is a pain for you all and hope to fix this as soon as we are able to.

Best regards,

Jehan Gonsalkorale

Product manager, Jira Service Management

Hi all, thank you for your interest here. We are reviewing this bug and are looking to see when we can implement a fix. We are very much aware that this is a blocker for many of you, particularly those who have issues with JQL and automation. We will provide an update in the next few weeks on this once we have have understood the work involved and what the impacts are.

Thanks for your patience and sorry for the inconvenience,

Jehan

@Yuri - You'll need to make a small correction. See below:

 
{ "fields":

}

Hey folks!

For all of you that are being affected by this, here it goes a possible workaround:

1. Create a new automation rule (not legacy automation)
2. The best trigger for this is the Field value changed:
   • Fields to monitor for changes: Issue Type
   • For: Edit Issue (Transition issue can be added here too)
3. For action, pick Edit Issue action
   • Select More Options and paste the JSON below:

{
    "fields": {
        "Request Type": null
    }
}

That's it! This should be enough to free you from this bug.

Here are a few considerations:

1. This rule can be created under the Scope of Single Project
2. In some sites, this field is called Customer Request Type instead of Request Type, this should reflect in the JSON too.

My team is also impacted by this bug. We'd like to get it resolved to get our validators working properly.

Hi, the corresponding issue on JSDSERVER seems to be this one : JSDSERVER-6395

The Request Type management when editing IssueType or moving ticket leads to a bunch of issues and is one of the most serious problems with JSD. 

This is causing problems with our JQL queries and automations.