-
Bug
-
Resolution: Unresolved
-
High
-
56
-
Severity 3 - Minor
-
79
-
Issue Summary
When a customer with the default language selected as Dutch (or anything other than what is default in the site) creates a request from the portal, the Automation rule is not able to translate Request Type and performs no action.
This happens even if the rule is running with the Automation user.
Steps to Reproduce
- Configure Request Types of a project with the language set to English.
- Translate the name of the Request Type to Dutch.
- Create an Automation rule with the condition in which the above Request Type is selected.
Expected Results
The Automation rule work successfully
Actual Results
When a customer creates a request from the portal of this Request Type, the Automation rule will fail
Workaround
- You need to use the automation condition as "Advance Compare Condition" instead of "Issue Fields Condition".
- Add "issue.Request Type.requestType.id" in First value and request type id in second value. You can refer to the below screenshot.
- To get the request type id go to Project settings >> Request type>> open the request type >> copy the last number shown in your URL.
- is duplicated by
-
AUTO-795 Automation should pass the condition(RequestType) if multiple languages is enabled for Specific JSM project.
- Closed
- is related to
-
-
- Closed
-
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
[JSDCLOUD-15087] (JSM) When a customer with the default language selected as anything other than English creates a request from the portal, the Automation rule is not able to translate Request Type and performs no action.
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
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}}
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.