Automation: Checking if there are unresolved clones

[Luka Delić]

HI!

I am making an automation which should resolve the original issue once clone is resolved, but only if there are no other unresolved clones of the original issue.

Example:

I have issue A and i cloned it to issue B and C( in different project). I want automation triggered when issue B is resolved. It should transition A to resolved but only if C is resolved as well. If it isn't it should leave A as it is. Once C transitions to resolved, rule will be triggered again and A will be resolved. There can be many clones of A, i just gave an example with two.

[Trudy Claspill · Accepted solution]

Hello @Luka Delić 

Welcome to the Atlassian community.

Have you tried to construct this rule on your own? Please show us what you have so far and tell us the part with which you are struggling.

Because you want this rule triggered by issues in different projects and you want to make a change to an issue in a different project from the trigger issue, you will need to have a Global or Multiple Project scoped rule. Those can be created only by Jira/Product Administrators. Do you have that level of access?

How do you keep track of the fact that the issue is a clone, and the issue from which it was cloned? Do have the two issues linked with the Cloners relationship?

[Luka Delić]

Hi, I have tried countless edits to this rule, none of them work. I find the original issue  to which the triggering issue is linked, but i have trouble finding a way to check status of other clones of the original issue. Clones are linked to the original issue, but not linked with each other.

[Trudy Claspill]

Hello @Luka Delić 

Let me confirm I understand your scenario.

You have issue A-1.

You clone it to create issues B-1 and C-1.

B-1 has its status changed to a status that indicates it is resolved.

You want to change the status of the issue from which it was cloned (A-1) to to the same status, but only if

- A-1 is in the status "u obradi" (in processing)

- all issues created by cloning A-1 (i.e. B-1 and C-1) in statuses that indicate they are resolved.

Have I understood your requirements correctly?

If so, then a rule like this will work for you:

1. Rule is triggered when the status of B-1 is changed. I use "Done" as the status that indicates the issue is resolved.
2. Check if the trigger issue is a Clone of another issue.
3. If the trigger issue is a clone of another issue, use a Lookup Issue action to find that issue, also ensuring that it gets the issue only if the source issue is in the specified status. In your rule you have a later condition to make sure the source issue is in the status "u obradi".
4. Check that the Lookup found exactly 1 issue. If the source issue is not in the specified status ("u obradi" in your case, "In Progress" in my example), then the Lookup will retrieve zero issues and the rule will stop processing.
5. If the Lookup found exactly one issue, log the issue key of that issue in the rule execution log.
6. Create a variable to store the issue key of the source issue (A-1). Here is the detail of the action.
   
7. Branch to the specific issue found by the Lookup. Use a JQL branch instead of a Related/Linked Issues branch.
8. This is logging the issue key of the issue to which we have branched to the rule execution audit log. This should be the source issue key again (A-1).
9. Use a Lookup Issues action to check for any issues that are cloned from the source issue where those issues are in an unresolved status.
10. Log to the rule execution log the number of issue found by the Lookup,
11. Check that the Lookup found exactly 0 issues. If the Lookup finds any issues, that means an issue cloned from A-1 is in an unresolved status, and you want the rule to stop processing.
12. The source issue (A-1) has no clones that are unresolved, and we previously confirmed that it is in the status we want (i.e. "u obradi"), so transition A-1 to the same status as the issue that triggered the rule.

You will have to make this rule a Global rule, or a Multiple Project scoped rule identifying all the projects that might be involved in the scope, in order for the actions to be able to find the linked issues in other projects.

[Luka Delić]

Thank you very much! I have managed to automate it using your instructions and some modifications such as is cloned by/ clones, deleting [0] etc.

Thanks again!

[Simon König]

Hi @Luka Delić and welcome,

I am not sure of your usecase. Could you clarify what your goal is? Do you just want all clones to be resolved? Can you specify how "C" could be mapped? Is it necessary to do those things in order?

Maybe if possible try a rule for yourself and send a screenshot or just try to reformulate the steps so I can try myself.

There are some limitations to automation rules regarding depth of if/else and branches and even on sequentiell execution of them.

Kind regards

[Marc - Devoteam]

HI @Luka Delić 

Could you also specify your rule in detail and what you have tried, also include audit log info and screenshots.

This will help community members to see your way of thinking.

We want to help people with requests, but not give them bite-size solutions.

We want people to try and if they get stuck, help them out. But then people will learn and understand the logic, instead of providing a solution that they don't understand.

[Luka Delić]

Hi, I have tried countless edits to this rule, none of them work. I find the original issue  to which the triggering issue is linked, but i have trouble finding a way to check status of other clones of the original issue.