Uploaded image for project: 'Automation for Cloud'
  1. Automation for Cloud
  2. AUTO-307

Issue field compare condition should use the ID of Request Types

XMLWordPrintable

    • 0

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Problem Definition

      Currently, the Issue field compare condition uses the Request Type name to compare its value against the one the ticket is using. This causes issues when comparing Request Types that have translations. More information can be found on (AUT-1869)

      Suggested Solution

      The full proof solution is to compare the request types with Id instead of name.

      Workaround

      Option 1: Compare the ID of the Request Type using the advanced compare condition against the following smart value: {{Request Type.requestType.id}} (or {{Customer Request Type.requestType.id}} for older instances). The Request Type Id can be obtained at the end of the URL when editing a Request Type.

      For example: https://<instance>.atlassian.net/jira/servicedesk/projects/<project_key>/settings/request-types/request-type/*<request_type_id>*

      Option 2: Use the advanced compare condition in combination with exactly matches regular expression to match the Request Type names using a regex like (value1|value2|value3|...|valueX).

        1. image-2021-09-29-09-57-21-763.png
          image-2021-09-29-09-57-21-763.png
          50 kB
        2. Screenshot_081332.png
          Screenshot_081332.png
          46 kB

            [AUTO-307] Issue field compare condition should use the ID of Request Types

            david.poulin added a comment -

            From my point of view, comparaison to value coming from a dropdown field should never be to the value depending on translation.

             

            The id workaround should be the normal behavior as we expect that when a issue is created, the value keeped is the value id no matter the language...For us it could be a risk based on the fact that somebody can change translation without knowing there is some automation based on that....

            david.poulin added a comment - From my point of view, comparaison to value coming from a dropdown field should never be to the value depending on translation.   The id workaround should be the normal behavior as we expect that when a issue is created, the value keeped is the value id no matter the language...For us it could be a risk based on the fact that somebody can change translation without knowing there is some automation based on that....

              Unassigned Unassigned
              bd0e47de2684 Yuri Moura (Inactive)
              Votes:
              6 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: