Using If-else logic to update status of a parent based on specific sub-tasks in status Ready

[Artur Balyan _ Immedis]

My Goal:

I want our devs and testers to use only the sub-tasks to update the status of their work. I.e. each Story has specific sub-tasks created for each person - backend, frontend, and QA - each with a corresponding [BE], [FE] and [QA] placed in the summary of the sub-tasks. Sometimes it could be multiple people of the same type working on the Story and sometimes it's just a combination of [BE] + [QA] or [FE] + [QA]. Every Story has to have an assigned QA in order to test.

How I think it will work:

I want the status of the Story to update only when the statuses of all the BE and FE sub-tasks are Ready.

I've been trying to use the If-else approach which seems the most comprehensive one.

My test:

I have a Story with each one of the sub-tasks - one of BE, FE and QA. So first I switch the status of the BE task to Ready (1), then switch the status of the FE task to Ready (2) and I expect the Status of the Story to switch to Dev Completed. There is already a workflow link from In development to that status.

This is my automation

I get very weird errors and the actions are not performed.
here is the result from (1) - which seems to not do anything (And that's OK, as I don't expect anything to be changed), but the error is kind of weird. 

I expect that when (2) is run then the story will be moved to state Ready.

It says that the issue did not match the condition when in reality it is matching! Here is what the "i" icon is relating to. 

The issue:

There is a Task with BE in the summary which is in the state Ready (I did this in (1)), but Audit shows that The conditions don't match and therefore the Story status does not change to Dev Completed.

Can someone shed some light on this? Thank you for taking the time.

Kind regards,

Artur.

[Artur Balyan _ Immedis · Accepted solution]

With help from a colleague, I managed to find a solution to this issue. Clarification: [ETL] is considered another type of development task. This was done a while back, but I thought I'd share the resolution here.

Thanks to anyone who took the time to read through.

[Bill Sheboy]

Hi @Artur Balyan _ Immedis 

First, some tips...

When posting an automation question for a longer rule, please try using a screen capture or browser addon so the entire rule is in one image.  That will help ensure the context is shown relative to the audit log.  (Posting multiple images makes it more difficult to follow.)

Next, your solution is using the Summary field for multiple purposes, and that is often problematic and brittle.  A simple typo or edit can lead to mismatches.  Instead consider using an explicit indicator for your work-item types of BE, FE, and QA, such as a multiple-selection custom field or labels, independent of the summary field.

Next, I have not seen consistent results when using the related-issues, rule condition with JQL...particularly with the CONTAINS ~ operator, which is known to have defects all by itself.  I recommend removing all of those.  Instead try a single, lookup issues action to gather the issues (i.e., subtasks) and then use list filtering and advanced compare conditions to test.

Back to your question...

What you do not show in your scenario testing is what were the status and summary values of the other issues when you exercised your cases #1, 2, and 3.  As a result it can be difficult to diagnose what is happening, or to even compare to the audit logs shown.

My suggestions are...

• Experiment with this rule in a test project, and not in your team's "production" Jira project
• Map out your test cases, simplest first, along with your expected results
• Create your test data's issues for the scenarios in a spreadsheet, allowing you to rapidly import and get to known starting conditions, repeatedly as needed
• As your test on the parent issue's status is common to all paths, pull that earlier in the rule to one single, condition test
• As your test on the trigger issue's status is common to all paths, pull that earlier in the rule to one single, condition test
• Build this incrementally: add logic to support one test case, get that working, and repeat until done

Kind regards,
Bill

[Artur Balyan _ Immedis]

Hello Bill,

Thank you for taking the time to look through my problem.

I was trying to get the entire page with the "GoFullPage" plug-in, but it didn't catch the entire logic. So apologies for making this hard to read. 

I've tested extensively and didn't have any issues with other rules pertaining to the ~ operator and the related-issues block. There is very little room for error when using them because the Tasks are created with a manual trigger. When using a simpler solution I can get the status to switch, however, with more than one dev-type task (i.e. FE and BE) I can't get it to work. That's why I updated the logic to an if-else solution.

"What you do not show in your scenario testing is what were the status and summary values of the other issues when you exercised your cases #1, 2, and 3.  As a result it can be difficult to diagnose what is happening, or to even compare to the audit logs shown."

The Summary for the Tasks doesn't change, ever. The previous status of the FE and BE tasks is For Review. 

I've been following all the things you suggested until I reached that blocker. I was hoping to get feedback on the type of error (or the lack of error) that I am getting. IMO the simplest approach is the best one. So what remains is to try a different approach - like with the lookup action you suggested.

Kind regards,

Artur