Hi everyone,

This is Gaurav from the JSM Automation team. Thank you for your patience as we progressed in fixing this bug. It has taken longer than expected. We are in the last leg of closing this issue. We will be rolling out the fix starting this week.

Best,

Gaurav Arora

Since now 3 years but no final solution You can do better atlassian, we know it.

That solution is not acceptable, if Atlassian provides multiple languages ​​in its system this must be supported by the ENTIRE system, the solution is either for the system to search in all installed languages ​​or for the selector to display the name, but uses the ID as value and therefore do what you have to do using the ID and this must be applied to the entire system.
This error is not is only in the request type; it is in all systems. In the workaround, explain how to select a request type, but this solution does not function when we have to edit a request, for example.

This is the workaround I need. IDs are always better than strings.

Yes, I'm affected as well. However the workaround provided by the support agent to work with request id's is a good solution.

I've also just encountered this bug and will need to apply the workaround for several automations in our project.

Any estimation for it's resolution?

Just as a closing note and to give some feedback, the amount of simple actions that require so much extra work due to bugs is insane, and most of them have been open for several years and are still on gathering interest or gathering impact.

Hey all,

if you need to evaluate more than one Request Type ID, you can't evaluate a comma separated list of ID's, in our case this did not work:

{{issue.Request Type.requestType.id}}

contains

25,26,28 

What you want to do is, evaluate a regular expression, that contains the values and are recognized as a whole, the following is working in our environment:

{{issue.Request Type.requestType.id}}

contains regular expression

\b(25|26|28|29|30|31|32|33|34|35|40|72|73|122)\b 

Cheers, Alex

Our team is awaiting you to fix this bug. High affect on us, because our processes is multi-language. Thanks

When can we expect the bug fix?

Any news about this bug? Any estimated date?

Hi everyone, 

We have a workaround solution for the Request type problem.

If you choose automation condition as "Advance Compare Condition"  instead of "Issue Fields Condition"- it is working properly.

The smart value notation:  

{{issue.Request Type.requestType.id}} 

Hi Team, is there any release date? 

The priority –> Low. Why?

This is serious customer satisfaction problem. 

Same here. Most of our clients are from Poland but they have customers from all over so this is a must for us. Otherwise, i would have to change my profile language and add 3 or more customer request translations to my automation rule.

I had the same issue reported here. My language is Spanish. so we created the request types in Spanish. The automation rule was succesfully created but failed in the first execution. To solve the problem, I changed the language to English and edit the rule. Thus, the automation started to work properly. Then I changed again my language to Spanish to continue working in my preferred language.

This is going to be hard to fix thanks to NextGen projects. 

Bit of history - due to Nextgen we no longer compare field values (e.g. Request Type values) by id but by name, due to the fact that NextGen creates multiple request types with the same name, but different ids in every project, which would break global/multi-project automation rules.

With this Bug in particular the root problem is that we store the field value name based on the language setting of the user configuring the rule. However we then get the field value name translated in whichever language of the user that triggered the webhook event.

The only way to fix this:

• Get Jira to provide an 'untranslatedName' for request types (both in REST responses and webhook bodies). We do this with issue types and other things like field names already
• Store the 'untranslatedName' in the rule config as the name.

Steps to reproduce or not correct btw.

1. Set the default language of the project to Dutch (or something else than English)
2. Translate a request type to English
3. Set your preferred language to English
4. Create an automation rule that has a condition based on the selected request type. The dropdown you'll see is presented in English (the config will store the 'name' as english)
5. Change your preferred language back to Dutch (or something else than English)
6. Create a request based on the type that should match the automation rule 
7. The automation rule will ignore the condition (In the webhook, the request type name comes through in Dutch)