Trigger other rules on issue move?

[Niklas Malmberg]

We have some rules helping us calculate the scope of epics, stories and tasks, based on the scope (story points) of subtasks. Have managed to create rules that trigger on create, resizing and status transitions just fine, my "recalculation-of-scope rule" fires as expected.
But I've failed to find a good solution when a subtask is simple reassigned (moved) to another parent Story/Task. (Here, firing of "recalculation-of-scope rule" is wanted)

Is there a way to use the one trigger I have discovered for this (Issue Update) to fire another, already existing, rule?
Or perhaps from within one rule to fire another trigger (which I already catches in the "recalculation-of-scope rule")?  

[Valerie Knapp]

Hi @Niklas Malmberg , thanks for your question.

Have you tested switching on this possibility on your rules?

So this ^ setting would allow for the rules to 'hear' and be called by triggers from other rules. Please give this a go and share your feedback.

Cheers

[Niklas Malmberg]

Hi @Valerie Knapp ,
yes I have that activated already.
However, my "recalculation-of-scope rule" uses the trigger "issue field / value change" on field StoryPoint, which is not triggered on subtask changing parent. 
What trigger catches 'subtask parent change'? 

[Valerie Knapp]

Hi @Niklas Malmberg ,

I got this to work

Can you test / try something similar?

[Niklas Malmberg]

Hi @Valerie Knapp,
I just tried to create a rule like that, and then simply moved a subtask from one story to another. But the new rule was not triggered at all :(

[Niklas Malmberg]

I did a test, tried to follow the suggestion found here: https://confluence.atlassian.com/jirakb/how-to-run-an-automation-for-jira-rule-when-a-sub-tasks-parent-changes-moved-1123194416.html 

Unsure about different Jira version so not everything was 100%, my rule looked like this


However, for me this rule did not trigger at all on a Subtask move (=change parent) between two Stories in the same project

Does anyone have another suggestion how to detect such an event? 

[Bill Sheboy]

Hi @Niklas Malmberg 

That post is for Jira Server / Data Center, which has different fields in some cases...like for parent apparently.

The suggestion made earlier by @Valerie Knapp definitely works:

• trigger: field change for Parent
• condition: issue type is one of Sub-task (This condition type of "is one of" will help confirm you are checking the correct issue type.)
• action: do something, such as logging or sending your message:

parent changed for {{issue.key}} from {{#changelog.parent}}{{fromString}}{{/}} to {{#changelog.parent}}{{toString}}{{/}}

When using the Field Changed for Parent as the trigger, there is no need for the Smart Values Condition to check the change log values: the rule would not have run otherwise.

If that does not work, please post an image of your audit log details showing the rule execution.  That may provide some context for the community to offer additional suggestions.  Thanks!

Kind regards,
Bill

[Niklas Malmberg]

Hi @Bill 

progress ! 
First off, the reason my rule did not trigger at all before was starring in my face, and it's even visible in the first screenshot I posted - the rule was Disabled (*sheep*)
(and the reason for that was malformed smart values in my message part. Once corrected I did get the rule to fire as I wanted)

So Yes, trigger suggestion from @Valerie Knapp is working just fine, Value change for the parent. 
Furthermore, both" equals" and "is one of" both work for me when comparing with Subtasks. 


On the issue that is triggered, new parent information is available, great.
I can retrieve {{issue.parent.key}} and {{issue.parent.Summary}} for example 

However, I still have problems accessing the changelog to retrieve the previous parent information, and that is needed for my solution. (I will need to recalculate the scope for both the new parent (which got an additional subtask into scope) as well as for the old parent who lost that subtask)

When reading up on this smart value on https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/, I noticed that a hash sign # is used in some of the examples - what's its meaning? 

Anyway, my rule engine accepts
{{#changelog.parent}} {{fromString}}{ {/}}
but not 
{{changelog.parent}} {{fromString}} {{/}}

However, nothing at all is outputted into my comment/message as a result :( 

Is there perhaps a difference between the parent-relationsship that has existed for a long time on Jira, where Subtasks always have a Story (or Task) as a parent (as found in issue.parent), and the newly introduced Parent relation which replaces epic link? 
And what does the changelog give access to? 
I see some discussion on that topic here https://community.atlassian.com/t5/Jira-Software-questions/Automation-How-to-access-new-parent-field-in-changelog/qaq-p/2547249 




 

[Niklas Malmberg]

As a test, I tried these variants and the results was [nothing at all]
Parent link: {{#changelog.parent link}}{{fromString}}{{/}}
Parent: {{#changelog.parent}}{{fromString}}{{/}}
Epic link: {{#changelog.epic link}}{{fromString}}{{/}}

What I can see in Jira is that the History of the issue logs the change of parenthood, I'm just not able to access this yet.

[Bill Sheboy]

Again, I recommend sticking with the parent field for this scenario.

Please try creating a test rule with just what I provided to learn if that works as expected.  It is possible the rule got "glitched", which can happen from too many edit / publish cycles, and so a new test rule may help to diagnose this.

While using the test rule, I suggest disabling your current rule (again ;^) to avoid too many moving parts at once.

Regarding that pound sign # -- this is used in the context of the changelog to set the scope for anything inside the expression, versus referencing only one smart value.  For example:

parent changed for {{issue.key}} {{#changelog.parent}}from {{fromString}} to {{toString}}{{/}}

Here the scope inside is {{changelog.parent}} allowing access to multiple things.

That symbol is similarly used for iterators, math expressions, and logical / conditional ones:

• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#Combined-function-examples
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/

[Niklas Malmberg]

Hi @Bill Sheboy 
I created a fresh copy of the rule, stripping out everything extra (and turned off the old rule). Now the new rule is just this: 


Still, I get output from {{issue.key}} only, no output from changelog-statements, 
Is that some feature that needs to be enabled per project perhaps?


The audit log shows that my subtask "AVT-2579" triggered the rule and that it ran successfully.

[Bill Sheboy]

Ah...are you using a Company-managed or a Team-managed project?  You may find that information at the bottom of the left-side screen expanding area.

If this is Team-managed...

It appears the changelog does not work for that field.  (Seems like a defect to me.)  The closest I was able to get was using {{fieldChange}} and that only provided the issue id, and not the key:

parent changed for {{issue.key}} from {{fieldChange.fromString}} to {{fieldChange.toString}}

But...we can use that to find the actual key with a lookup issues action:

• action: lookup issues, with JQL of
  • id = {{fieldChange.fromString}}
• action: log the change, with
  • parent changed for {{issue.key}} from {{lookupIssues.first.key}} to {{issue.parent.key}}

[Niklas Malmberg]

Good guess - Yes, I'm running Team-managed in this project. 

It works well with fieldChange, so now I have access to both previous and current parent keys, GREAT!
(Remains to sort out how to incorporate them in my calculations, but now I have a good chance to solve out the task I wanted to solve in the first place)

Thanks for the help @Bill Sheboy