Automation rule apparently not finding child issues of Epic

Tobias Lorenz February 9, 2024

I want to clone an Epic with all children and have set up an automation rule.

The rule clones the Epic first, but fails to find all children of the Epic to cloning them as well.

I probably have a misunderstanding of the rules that I use.

 

Here is the Epic that I would like to clone:

xPQFFrg1XC.png

 

Here is the ruleset:

chrome_u9R56i7vKw.png

 

And here is my automation log:

chrome_BIMcqvWNb2.png

I also tried using various JQL queries, but this was not successful either.

Using JQL in the UI to search for children of this Epic works perfectly, 

 

Any advice is very welcome.

3 answers

1 accepted

0 votes
Answer accepted
Tobias Lorenz February 29, 2024

My research revealed, that the culprit here was the configured Issue Security schema on the Project.

Not only does the Project Role (atlassian-addons-project-access) need access to the project permissions. There also needs to be an Issue Security Level with this Project Role assigned, if Issue Level Security is used on a project.

chrome_UbsxjMrGwb.png

0 votes
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 9, 2024

Hi @Tobias Lorenz -- Welcome to the Atlassian Community!

Please try changing the branch type, from "Children" to "Stories (or other issues in Epic)"

Kind regards,
Bill

Tobias Lorenz February 9, 2024

Hi @Bill Sheboy, thanks for your suggestion.

I already tried this branch type, but the result is/was the same. No child issues were cloned.

I then changed the branch type to "children", as recommended by the automation UI.

chrome_ex6KIJxscu.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 9, 2024

Thanks for the reminder, as I ignored the Parent change for a moment.  The Child branch type should have worked...

This seems to indicate the Parent field is not found correctly for those issues.  Let's test that hypothesis:

Change the branch to JQL, with this:

parent = {{triggerIssue.key}} AND issueType != Epic

 

Also, what type of project is this: company-managed or team-managed?

Like Tobias Lorenz likes this
Tobias Lorenz February 9, 2024

It's a company-managed project.

Unfortunately, even if I change the branch to JQL with your suggested query, the automation still fails to find children of the Epic to clone.

If I use this very JQL to filter issues in the issues screen, the JQL works as expected. All 8 children are found. In the automation, they are not.

TfUYG9XGtA.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 9, 2024

Would you please post an image of your complete current rule, in one image?  Perhaps I am missing something we can see in the full context.

And, please check your custom fields to determine if there are multiple fields named Parent. You can ignore the one named "Parent Link" if you see it; we are checking for "Parent".  I believe the built-in one will not display in the list of custom fields, and so if you see a field there may be a duplicate field causing problems.

 

One more thing to try: rules can get "glitched" from too many edit / publish cycles.  I have no idea why this happens.  To check if this is the problem, try...

  • Disable your rule, wait a minute, re-enable it, and re-test.  If that does not help...
  • Disable your rule, re-create it from scratch, and re-test.
Like Tobias Lorenz likes this
Tobias Lorenz February 9, 2024

There is no other parent field that we added to our instance.

ScBPBWP4lM.png

 

Here is a full screenshot of the automation

chrome_rzsDMx7hTp.png

As far as I understand it, my setup is not very complex, and so isn't the automation. There is no apparent reason for it not to work as expected, yet it doesn't.

Disabling and re-enabling it didn't help.

I will re-create the automation and try again my tomorrow.

Thank you so much @Bill Sheboy for taking the time to investigate.

Tobias Lorenz February 9, 2024

For a quick verification I created a new very simple automation to just clone this precise Epic's children.

The JQL verification in the automation creation UI says there are 8 issues.

chrome_2nMILY7bUk.png

 

Yet, the automation does not find them

chrome_ciaPFpoNO9.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 9, 2024

Ah...Has the actor for the rule been changed from default, Automation for Jira?

When you tested that JQL in the branch, it is definitely uses the permissions of the person editing the rule.  When it runs, it uses the actor.

If you change the rule actor back to Automation for Jira and re-test, what do you see?

Like Tobias Lorenz likes this
Tobias Lorenz February 10, 2024

The rule actor had not been changed away from "Automation for Jira".

But we are onto something.

I changed the rule actor temporarily to myself, and voilà - the automation was executed correctly. All child tasks were cloned as expected.

So the next thing to solve is:

Why does the "Automation for Jira" actor not have sufficient rights, and what is needed to get it there?

I checked the permission scheme for the project, and the Project Role (atlassian-addons-project-access) does have every Permission on the project.

Tobias Lorenz February 10, 2024

I found the solution. See my answer.

Thank you @Bill Sheboy for your time and help.

Like Bill Sheboy likes this
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 10, 2024

Well done!

This is one of the challenges of the highly-configurable permission features for Jira: the out-of-the-box permissions for automation work because they are elevated...but, if the project's lower-level permissions have been altered curious side-effects occur.  And as we observed in this case, the app is "working as designed" and so there are no errors to indicate the root cause.

I am smelling a new feature idea, similar to the automated guides for "where's my field": perhaps automation rules also need to programmatically detect why a field or issue is not visible to a rule.

Unfortunately...I can no longer create suggestions in the public backlog as I am on a free license.

0 votes
K Vivek Rao February 9, 2024

Hello @Tobias Lorenz Is it a full screen shot of the automation you configured? Automation works when you ask to perform action depending on triger.

Could you please share your requirement in detail?

Tobias Lorenz February 9, 2024

Thanks for asking.

Yes, this is the full automation for now. I plan to extend it later.

I want the automation to clone an Epic, including all children of the Epic.

The automation is triggered manually.

As you can see in the automation log, it runs, but doesn't find very well existing children of the automation.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events