Rule based on epic info not being applied

[Jeremy Stafford]

Starting a new post re: Solved: When and How (for automations): Epic link will be ... (atlassian.com)

I'm trying to create a rule where on create or edit (maybe two rules), if the issue was added to an epic whose name contains 'unplanned work', the issue's priority should be updated to 'highest'. 

I can see in the audit log that the triggers are firing but no rules are being applied due to no match. I've tried a couple field conditions with no success:

• Epic name contains 'unplanned work'
• Epic description contains 'unplanned work'
• Epic/Theme -- didn't get anywhere with this because it makes me pick values from a dropdown, and I don't know where those values are coming from.

It is a company-managed project, and all issues being targeted are in this project.

[Jeremy Stafford · Accepted solution]

Turns out I had to use smart values and targeted {{ issue.parent.summary }} and also changed "contains unplanned work" to "contains Unplanned Work" since this component is case sensitive.

The documentation is unclear. It says there are only 3 properties in issue.parent but clearly that isn't true.

[Kalyan Sattaluri]

@Jeremy Stafford I am not familiar with Company managed projects etc. so Bill / Trudy or others are maybe more familiar. I am in Data center and we have Feature Link and Feature Names, just confusing all around. In general I would think Epic Name or Feature Name should return you the data. 

While we wait, my backup plan suggestion would be to do a look up of the epic itself for the given issue so you know which field you are referencing, to do this I would:

• log in to Jira,
• go to an existing issue which has Epic linked to it,
• note down the issue key,
• then open a new tab in your browser and
• place below URL (updating bold parts with your instance and the issue you went to) and hit enter.
• https://yourdomain.net/rest/api/2/issue/ABCD-101?expand=names
• Then review the JSON response to know if {{Epic Link}} stores your Epic Key or is it {{Parent Link}} or {{Feature Link}} etc.

Once you know which field holds the epic key from above step, you can do a lookup of the epic using the key's smart value and get your field (epic summary or epic name or which ever field you are wanting to check).

Then you do a If condition with smart values to check if that string exists.

I am def over complicating this but something to try while others clarify.

[Jeremy Stafford]

It's a good idea. I'll hit the API from Postman and see what I can find.

[Jeremy Stafford]

The epic name that I would use appears only in one place in the JSON payload: `fields.parent.fields.summary`. Unfortunately 'parent' is not field I can choose in the UI. I'm looking at smart values now but it doesn't look like the json payload from the rest api matches what automation is working with? I'm not sure what the smart path would be for what I described above. I tried {{ issue.parent.summary }} and {{ issue.parent.epic.summary }} but that didn't work. According to the docs there is only this:

Available properties:

• {{ issue.parent.key }} - Returns the issue key of the subtask's parent issue.

• {{ issue.parent.priority.name }} - Returns the priority of the subtasks's parent issue.

• {{issue.parent.epic.summary}} - Returns the summary of the parent issue's epic.

[Kalyan Sattaluri]

Couple of points:

I just reread your first post, if your starting trigger is that an epic is added to a story, then maybe you need to do a refetch to get the latest state of the issue before you do your If condition. I have seen this kind of race condition in some other posts before where rule is triggered prior to commits being made.. So please try that with your current set up and verify..

Regarding your review of JSON, your response should show Epic Key, not the name. Thats what you are looking for. As I said, use an issue which has Epic linked to it, note down the "Epic Key" and search for it in the payload. Easy way to know this field.

Also, you can directly use Edge browser once you log into Jira to make that API call, this way you dont have to worry about passing credentials in your postman. Just FYI. Edge cause it renders JSON properly formatted, Chrome has no formatting.

[Jeremy Stafford]

Dang that didn't work either. I re-fetched but the smart value still didn't match. Is there a way to see what the smart values component is getting?

[Jeremy Stafford]

actually I was able to log {{ issue.parent.summary }} and it has the right value, it's just not matching. Missed your other point that this component is actually case sensitive.

It's working now! If only i could make it case insensitive. Thanks for the help!

update: turns out the re-fetch isn't necessary

[Kalyan Sattaluri]

Phew. I am still not clear on Parent vs Epic etc but glad you got it figured out!

Now that I look back, what I was actually suggesting was overkill and since your Epic and story were in the same project, you could reference the Epic's summary the way you did simply.

Please post your answer in new post and mark it accepted so others can reference.

[Bill Sheboy]

Hi @Jeremy Stafford 

The Epic Name field has essentially been sunset, and now the issue's Summary should be used.

Are you trying to find any matches to "unplanned work" in either the Summary or Description fields when the issue type is an Epic?

Does the case matter, as I believe that comparison type is case-sensitive for the condition.

Kind regards,
Bill

[Jeremy Stafford]

> now the issue's Summary should be used

Which issue?  I'm trying to check the epic that the triggering issue is part of, not the issue itself. I'm not seeing any option for parent issue.

[Bill Sheboy]

As you saw in my response, the smart value you needed is {{issue.parent.summary}} rather than the fields you were using, and the values are case-sensitive.

Checking case-sensitive values can be a brittle solution in rules as it relies on people not making mistakes.  Instead consider using a Smart Values condition instead and forcing the text to a known case, such as with toLowerCase() https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#toLowerCase--

The condition could be:

• first value: {{issue.parent.summary.toLowerCase()}}
• condition: contains
• second value: unplanned work

For future rule writing, please note: when checking fields / smart values in {{issue.parent}} only some of them are available when the issue loads into a rule, such as Summary.  Other fields in the parent of an issue may need to load the parent first, such as with Lookup Issues or a branch, before then can be used in a rule.

Regarding your comment about the documentation, it rarely catches up with the code changes...although sometimes it contains features not released yet!  This is one of the reasons successful rule usage requires learning and experimentation.  There are ways to discover which smart values are available for issues in a rule, and their structure; perhaps investigate those to learn more.

[Jeremy Stafford]

Thanks for the toLowerCase() function tip, I was unaware that these existed. I know there are almost always ways to 'discover' how it all works, I'm just at ground zero here so I'm still discovering how to discover :).

For anyone else that might come across this in the same situation, I was able to discover the field by adding a logging action and tossing random values out to see what came back. Luckily, the needed field was located exactly where you would expect it to be; it just wasn't matching due to case. Hitting the API first does help a little even though the payloads look completely different, I just wish there was an easier way to discover the object that the rule components are working with.

The underlying object model is smart but in a deceptively unintuitive way -- I was not able to simply log out an object to observe it because it would only log out the top-most representation of any given property. For example, if I logged {{issue.parent}} I was hoping to see the full structure of the parent, but instead it just logged the parent issue number which made me think it was just a string, but then I remembered how object stores tend to work so I threw a hail mary and found that {{issue.parent.summary}} logged the actual summary so I used that.

[Bill Sheboy]

To find the fields and smart values supported by rules, please try...

Smart values are name, spacing, and case-sensitive.  And often the smart value does not match the displayed field name on the issue views.  The steps below helps to identify the correct smart value (and custom field id) for fields and their structure within the issue.

• identify an issue which has your field(s)
• call a REST API function with a browser to search for your issue:

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

• search on the page for your field, such as with CTRL-F
  • if you find the field, you will also find the smart value, custom field id, and structure / attributes it has
  • if you do not find the field, it may not be supported by automation rules

[Jeremy Stafford]

Yes, that is what I did (please see other answer by Kalyan). As mentioned, the json payload that is returned does not match the same pathing structure as the smart values. Some additional inference is needed.