Putting field value instead of ID in Automation Rule JSON

[David Maurel]

Hi,

I have a question regarding the automation rule JSON Export. Here's the context : I migrated from JIRA Server, then created a bunch of automation rules in my new Cloud site. I had to clean the site to import from Server a second time, but I didn't want to lose my rules, so I exported them all in a JSON file before cleaning the site.

After importing the JSON, I encountered a small, but annoying problem : when it came to conditions with issue types, all the values were IDs instead of text values. So my automation rule condition ended up like this

Field : issue type

Condition : Equals

Value : 10086, instead of "Incident", with a nice red "value not found" beside the number...

I found the part in the JSON file where the issue types conditions are defined :

My question is : why is an issuetype coded with the ID of its value instead of the text label of its value, and can I safely import after changing the code this way :

"selectedFieldType": "issuetype",
"comparison": "EQUALS",
"compareValue": {
    "type": "NAME",
    "modifier": null,
    "value": "Incident",
    "multiValue": false,
    "source": null
}

instead of what i got in the JSON export :

"selectedFieldType": "issuetype",
"comparison": "EQUALS",
"compareValue": {
    "type": "ID",
    "modifier": null,
    "value": "10086",
    "multiValue": false,
    "source": null
}

[Bill Sheboy · Accepted solution]

Hi @David Maurel 

With Jira Cloud, there are company-managed and team-managed projects.  And as the name implies, team-managed support project-level configuration of issue types, custom fields, etc.  If you use just the name for a type there could be a mismatch for rules which span multiple projects.  This same configuration feature also causes challenges for saved filters, dashboard gadgets, and potentially addon report tools.

Perhaps try creating a test project in your new Cloud instance and import the rules to check for possible impacts for types, status values, etc.

Kind regards,
Bill

[David Maurel]

It makes sense... I'll do some tests to see if it works.

Thanks for your answer, Bill.

Best regards,

David

[David Maurel]

OK, I did the test, aaaaand it's not working... 😢

The component tree on the left shows the value of the "NAME" I specified (in the above example, "Incident"), but the Value field on the right doesn't display the value in the drop-down list, it definitely needs the ID to find it. After that it displays an error saying the value is missing.

[Bill Sheboy]

That is interesting...I would expect that when importing a rule from one Jira version (or site) to another that the id values might be different for types, even when the names are the same.

And so the symptom you are seeing is the rule JSON has a name for display purpose, but it cannot match to a type by id...leading to the error about not finding the type value.

I can suggest two more things to try, brute force and throw-it-over-the-wall:

• brute force: After you export your rules from the source instance, go and find the id values for the respective types in the destination instance.  Then using a search/replace editor with regex capabilities, change the source id values to the destination ones, and then import the rules.
• throw-it-over-the-wall: This absolutely cannot be an unknown migration issue to Atlassian.  As you appear to be the site admin for a paid Jira license, submit a ticket to their support here to see what they suggest: https://support.atlassian.com/contact/#/

If they suggest something clever to solve this, please post back here to help the community.  Thanks!