Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Automation: Transitioning a subtask when another subtask under the same parent transition

Davide Orbitello September 28, 2024

Hello,

I'm trying to build an automation that should make transitioning a subtask from one status to another when another subtask under the same parent makes a transition.

So with my automation I'm  trying to check if the two summaries match, and if so make the older ticket transition to the same status "DONE" as the last created one.
Checking the audit log, the problem looks to be that the automation cannot target the old subtask, but try to get the parent or the trigger issue. I was wondering if the problem could be that the "ADJUSTMENT NEEDED" status is a green status and maybe the automation cannot handle it.

Can you please help?

Screenshot 2024-09-28 at 11.06.39.pngScreenshot 2024-09-27 at 15.31.29.png

1 answer

1 accepted

4 votes
Answer accepted
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 28, 2024

Hi @Davide Orbitello,

Trying to take this step by step. Have a good look at my assumptions along the way to make sure I understand correctly what you are trying to do.

So with my automation I'm  trying to check if the two summaries match, and if so make the older ticket transition to the same status "DONE" as the last created one.

If I get this right and look at your screenshot, DR-1430 is your trigger issue that has just transitioned to DONE and you are trying to automatically transition DR-1429 to DONE as well as it is the subtask of the same parent and has the same summary?

In your FOR JQL branch, I would try to get to the exact issue(s) you want to modify first of all in one go. Although I have some doubts I'll come back to, you could try to modify your JQL to something like this:

parent = {{triggerIssue.parent.key}} AND summary ~{{triggerIssue.summary}}
AND issueType = Subtask and key != triggerIssue.key

That would immediately exclude your triggering issue from the result set and allow you to eliminate the first condition in your branch.

I suppose that your second condition is there to make sure the summary of the issue(s) returned by your JQL query is exactly the same as that of your trigger issue. However, I don't see where you initiated {{lookupIssues}} anywhere in your rule. I would think the following comparison should work instead:

{{triggerIssue.summary}} equals {{issue.summary}}

As a last step on your immediate topic: to be able to transition the issue to done, your workflow must provide a valid transition from the issue's current status into Done. That the current issue has a green status is definitely not a suspected reason why the issue can't transition. Either a missing transition or additional custom conditions or workflow properties you or your admin built in yourself may have an impact.

I think you're just not getting to the correct issue to transition, in summary.

Apart from that, and on a separate note. I can't quite wrap my head around how you end up with duplicate subtasks under the same parent. Since you want to close them automatically, I am assuming (and I may be wrong there), that these are actually identical items.

If that is true and I was in control of the process, I would try to resolve the problem earlier on and not at the time of closing an issue. Using much of the logic you already have in place, you could

  • consider closing the newly created issue immediately when it appears to be an exact copy of one that already exists;
  • send a notification to the user who just created an issue that seems very much the same as one that is already there and ask them to review immediately;
  • create a link between the same issues, so you can then use that link to easily manipulate related issues instead of working from the summary

Hope this helps!

 

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.
September 28, 2024

Hi @Davide Orbitello 

Yes, and...to Walter's suggestions:

Are you trying to find an exact match of the summary of the two subtasks?  If so, why are there two subtasks with the same summary as that would imply they are the same work item?

Regardless of the answer to that, let's slightly adjust the JQL with the CONTAINS ~ operator to perform an "exact phrase" match:

summary ~ "\"{{triggerIssue.summary}}\""

This will only match if the summary of the issue contains at least the full, exact text of the trigger issue's summary.  It could be an exact match, or have a prefix or suffix and still match.

Kind regards,
Bill

Davide Orbitello September 29, 2024

Hello  @Walter Buggenhout @Bill Sheboy ,  
 
First of all, thank you for the extended explanation and reply, I appreciate it.
Your assumptions are correct, but to add some info, the workflow I'm trying to follow here is this one, and yes, I didn't provide enough details to think about another solution, sorry for that.
So the parent Ticket that I have, is triggering the creation of the subtask when transitioning from one status to another, specifically from 'IN REVIEW' TO 'TESTING ENV'.
As soon as the ticket is in the latter status, it triggers the creation of one subtask called "check data quality - prices".
The thing is, when the assignee of this last ticket found any errors, he or she needed to transition the child subtask to "ADJUSTMENT NEEDED", when this happens, the parent ticket went back to progress. So the assignee of the parent ticket can make the fixes, then send it back to in review and consequently to "in testing env".
At this point, this triggers the automation of creating a new subtask with the same summary, so another child subtask is created and the assignee can do the quality check again.
Another thing important to mention is that there are 3 types of quality check subtask tickets. I am saying this because I was thinking that maybe the best way is to send back the ticket with the status "ADJUSTMENT NEEDED" back to "in progress" when the parent transitions to "In testing env"
I think this should be easier to manage, or do you have better ideas?
 

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.
September 29, 2024

Are you trying to have one Subtask with a Summary of "check data quality - prices" or multiple Subtasks with that Summary (with one for each attempt to perform the check)?

 

When a Subtask moves to the status "ADJUSTMENT NEEDED", what happens to that subtask next:

  • is it considered "completed" or
  • does it move back to some waiting status, until the parent once again returns to "TESTING ENV"?

 

I recommend pausing to fully define your scenario, including the different test cases.  You could create those with a state diagram or in GIVEN WHEN THEN format to help both write the rule and perform validation testing.

For some examples:

GIVEN a Story is in the "IN REVIEW" status
AND the Story does not have an incomplete Subtask with a Summary of "check data quality - prices"
WHEN the Story transitions to the "TESTING ENV" status
THEN create a Subtask with the Summary of "check data quality - prices" for that Story
AND ???

GIVEN a Subtask with the Summary "check data quality - prices"
WHEN the Subtask transitions to the "ADJUSTMENT NEEDED" status
THEN transition the parent Story of the Subtask to "IN PROGRESS"
AND do ??? to the Subtask

and so on...

 

 

Suggest an answer

Log in or Sign up to answer