Trigger other rules on issue move?

Niklas Malmberg February 16, 2024

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")?  

1 answer

0 votes
Valerie Knapp
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 16, 2024

Hi @Niklas Malmberg , thanks for your question.

Have you tested switching on this possibility on your rules?

image.png

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 February 16, 2024

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 16, 2024

Hi @Niklas Malmberg ,

I got this to work

image.png

Can you test / try something similar?

 

Like # people like this
Niklas Malmberg February 19, 2024

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 :(

Screenshot 2024-02-19_000027.png

Niklas Malmberg February 20, 2024

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
Screenshot 2024-02-20_000028.png

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 20, 2024

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

Like Niklas Malmberg likes this
Niklas Malmberg February 21, 2024

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. 
Screenshot 2024-02-21_000029.png

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 February 21, 2024

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.
Screenshot 2024-02-21_000031.png

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 21, 2024

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:

 

Niklas Malmberg February 23, 2024

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: 

Screenshot 2024-02-23_000048.png
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?
Screenshot 2024-02-23_000049.png

The audit log shows that my subtask "AVT-2579" triggered the rule and that it ran successfully.
Screenshot 2024-02-23_000050.png

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 23, 2024

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 February 26, 2024

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 

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events