I am trying to create a rue that will notify people when tickets are removed from certain epics (by key words in the parent Summary).
I have created a rule triggered by changes to the the Parent field, however I am having no luck using .from or .fromString on issue.parent.
I've lost could of the permutations I've tried, but they include:
{{issue.parent.summary.fromString}}
{{issue.parent.summary.from}}
{{issue.parent.from}}
{{#changelog.parent}}{{fromString}}{{/}}
I need to be able to get the Summary of the old parent as a smart value (or variable) so I can filter before sending comms, which will need to include the old and new parent's Summaries
Help
Hello @Dave Furlani
That does not work because it is the Parent field itself that is changing, not the parent's Summary field.
If your rule trigger is Field Value Changed and monitoring the Parent field then you can use the {{fieldChange}} smart value to get the before and after values of the field. The documentation for that smart value can be found here:
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--fieldChange--
However, that will be just the string value of the field, not a reference to the issue entity referenced by the field. You'll have to execute steps to actually get the previous Epic issue.
You might be able to use something like this to branch to the original parent epic issue and get the summary:
Note that if the content of your communications depends on both the original parent summary and the new parent summary, the steps related to examining those value and sending the message would need to occur within the branch. Branches and the steps within the branch run in parallel to steps that are at the same level where the branch split off, so steps added where the Add Component button is would be executing at the same time as the steps within the branch. Additionally a variable created within a branch will be unknown and undefined outside of that branch.
Alternately you might use the Lookup Issues action to retrieve the original parent Epic, and then reference the issue entity Summary using {{lookupIssues.first.Summary}}
I would recommend adding conditions also to ensure that the rule is triggered by a change on an issue type that may be a child of an Epic. The Parent field is also used in sub-tasks, and in Epics and issue hierarchy levels above Epic (if you have created those). So you can't assume that when this rule is triggered (as is) it was triggered by a change to a child of an Epic.
Let us know if you have additional questions.
Thank you @Trudy Claspill , that is a nicer way to get the from parent key than {{#changelog.epic link}}{{fromString}}{{/}}
The first step is a filter that rules out sub-tasks, and projects that aren't of interest to us:
key = {{issue.key}} AND issuetype in standardIssueTypes() AND category = "System Layer"
I'll now work through the lookup approach to find the parent's parent to focus the actions on the initiative of interest.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.