Cancel Sub-tasks when parent is canceled, revert to previous status if parent is reopened

[Krzysztof Kiser]

Hi guys,

I am not sure if that's even possible, but thought I'd ask.

I am looking for a way to cancel sub-tasks if a parent is canceled (only those that are to do or in progress) and if the parent is reopened, I would like to revert the sub-tasks to their previous statuses (the status from before the parent was canceled).

Is something like this possible with Automation for Jira?

[David Fischer · Accepted solution]

I'm not sure it's possible with Automation for Jira, but I know it's possible with other apps such as JMWE. It's actually easy on Jira Server/DC, but much more complicated (but doable) on Jira Cloud.

[Florian]

Hi the first thing (cancellation) can be done with automation for Jira.

See this example: https://community.atlassian.com/t5/Jira-Core-questions/automate-movement-on-subtasks/qaq-p/1028028 

The second thing (go to previous state) is not so easy. You need a custom field to store the previous state on every transition. Then I think Automation for Jira might be able to go to this state. It is basically the same idea. 

[David Fischer]

Automation cannot "go to a state", it can only "trigger a transition" that goes to the desired sate. The problem here is:

- you need to have transitions that go from "Canceled" to any of the possible previous statuses

- you need to trigger the right transition for each sub-tasks based on its previous status, and I'm not sure how you can do that with Automation

[Florian]

David is right. Of course your workflow need to provide the necessary transitions. But the you can actually name the target state itself. 

[Krzysztof Kiser]

Hi @David Fischer  thank you for recommending JMWE. I will be giving it a go today to see if it works for my needs. 

[Krzysztof Kiser]

@David Fischer 

I did just try the JMWE app and I partially accomplished what I needed, but have a few questions: 

1. How do I set the transition linked issues to only change status if the linked issue is still in to do or in progress state? If an linked issue has already been completed, I do not want to change that status.

2. How do I add a post function that would revert all linked issues to their previous statuses if the parent is reopened? I am not able to find this option anywhere.

Thanks in advance!

[Krzysztof Kiser]

I think I have the first question figured out, but it only works for some issues while not for others.

In the conditions, I added:

issue.getAsString("resolution") != "Done"

I have two workflows within a project. This did work for one workflow, but did not for the other. I had a completed sub-task, but it still changed its status to canceled.

Any idea what I might have set up wrong?

[David Fischer]

For the first requirement, you need to use a Transition Related Issues post-function, but the fact that you mentioned "transition linked issues" makes me wonder if you're on Jira Server or Jira Cloud. Can you confirm you're on Jira Server/DC and not Cloud? And which version of JMWE did you install?

Based on your answer, I'll then be able to guide you through the solution.

[Krzysztof Kiser]

@David Fischer  I am on Jira Server and the app version is 6.3.5. 

[Krzysztof Kiser]

@David Fischer  if it helps, below are the two workflows I am using within the project I want to apply this automation to.

The automation would be applied to the first workflow as it's used for tasks and sub tasks.
The other one (with payments) is used for sub tasks only.

Here's exactly what I want to achieve:

1. If an issue (parent) is transitioned to CANCELED, I want all sub-tasks to transition to CANCELED or NO PAYMENT REQUIRED (depending on which workflow the sub task is using). I want this done only for issues which had not been completed before this transition. If already completed (resolution = done), I want them to keep their status.

2. If I transition the parent issue from CANCELED to TO PLAN I need all of the sub tasks to revert to their previous status unless they previously had one of the completed statuses (COMPLETED/CANCELED or PAID/NO PAYMENT REQUIRED) or resolution = done. 

[David Fischer]

Thanks for the clarification.

For the first requirement, you can use a Transition Related Issues post-function configured as follows:

- Target issues: Sub-tasks of the current issue

- Transitions: add _both_ the name or ID of the transition to the Cancelled status _and_ the name or ID of the transition to the No Payment Required status (don't forget, they're _transitions_, not _statuses_)

- Conditional execution: if you only want to test the Resolution field, you can use this script:

relatedIssue.getAsString("resolution") != "Done"

(note that the variable used is "relatedIssue", not "issue", because you want to test the Resolution of the sub-tasks, not the main issue)

- you'll also need to add the Resolution field to the "Transition screen" section to set the Resolution field of the sub-tasks being closed

The second requirement is more complicated, because you need to identify which sub-tasks should be "reopened" and which sub-tasks should be left "closed". There are multiple approaches to that, but the easiest would be to decide based on the "Resolution" of the sub-task. If the "automatic" closure of sub-tasks (done by requirement 1) uses a _specific_ Resolution value (different from the Resolution values that are used when manually closing a sub-task), then you can use that Resolution value to decide whether to reopen each sub-task. Let me know if that works for you and I can give you more details.

[Krzysztof Kiser]

The first part works. I had the same setup before, but instead of using: 

relatedIssue.getAsString("resolution") != "Done"

I used:

issue.getAsString("resolution") != "Done"

I've amended it and it now works very well. 

 
The automatic closure of sub tasks would actually use the same resolution as manual closure. I wanted to stick to one resolution within the project (Done). 
Would this still be possible to do without a different resolution?
If not, I would be willing to make some changes around the resolution to make this automation possible.

[David Fischer]

Well, again, the problem is knowing which sub-task to reopen when you reopen the parent issue. You need to know which ones were automatically closed, since you don't want to reopen sub-tasks that were manually closed. I can think of multiple options:

- use a different Resolution

- use a hidden custom field to "remember" that the sub-task was automatically closed (but don't forget to reset the field when you reopen the sub-task, be it automatically or manually)

- use a specific "run as user" to automatically close sub-tasks, so that you can later only reopen sub-tasks that were closed by that user (although that's a little more complicated)

Whatever approach you use, you'll use that in the "conditional execution" script of the Transition Related Issues you'll put on the "reopen" transition of the main issue. The problem is then to send each eligible sub-task back to their _previous_ status. For that, the easiest is to:

- create an "Auto-reopen" transition for all sub-tasks

- hide the transition from users using a "Hide transition from users (JMWE app)" Condition

- on that transition, add a "Return to Previous Status (JMWE app)" post-function to that transition

- and on the Transition Related Issues of the Reopen transition of the main issue, trigger that "Auto-reopen" transition on sub-tasks (and use Conditional execution to filter the sub-task you do want to reopen, based on above).

Using a "Return Related Issues to Previous Status (JMWE app)" post-function would be easier but it doesn't yet exist (it will be coming in a future version of JMWE)

[Krzysztof Kiser]

This seems very complicated to do to be honest. I thought there would be an option that is a little less complex.
I might give it a try over the weekend as it might take a couple of hours to implement. If I decide and manage to do this, I will let you know if it worked.

You mentioned that Return Related Issues to Previous Status (JMWE app) is coming to the app. Any idea on when can this be approximately released? If in more less near future, I might just wait for this feature to be released.

[Krzysztof Kiser]

@David Fischer  I've tried to set it up, but I must have made a miatake somewhere.
I went with the hidden custom field option. I set it to update to "Yes" when the parent issue is canceled.

Here's the setup:

Reopening of sub tasks only works on the payments workflow (I currently have it set to static status change to TO PAY). It seems the Auto-Reopen transition does not work.

Here's the setup of the CANCELED > TO PLAN transition:

And here's the setup of the Auto-Reopen hidden transition:

Is there anything that I would need to change? I might have gotten a little lost in all of the steps and transitions.

[David Fischer]

Did you notice the messages on the red background? You need to move the post-functions down on the list, until the messages disappear. This is especially important for the Return to previous status post-function.

David

[Krzysztof Kiser]

@David Fischer  I don't know how I could have missed it to be honest. I've fixed it now, but still, it only works on the payments workflow. It doesn't work on the Travel workflow.

[Krzysztof Kiser]

@David Fischer  I just tried to set it to a manual status change in the Travel workflow and it did transition just fine.
The problem must be in the Return to previous status post function, but I don't quite know what the issue is. I don't see anything wrong with it.

[David Fischer]

You might want to try to make the "Auto-reopen" transition visible on the Travel workflow, and then trigger it manually on a Cancelled sub-task, to see if the sub-task returns to the previous status.

[Krzysztof Kiser]

@David Fischer  I just tried that and when manually triggered from the sub task it work. I also tried to manually trigger it from the parent task and it did return the sub task to their previous statuses. I am really confused now that it works when triggered manually, but not when set to be triggered in the post function.

[David Fischer]

I'm confused now - what do you mean by " I also tried to manually trigger it from the parent task and it did return the sub task to their previous statuses" and "it works when triggered manually, but not when set to be triggered in the post function"?

Anyway, if the "Auto-reopen" transition works on sub-tasks that follow the Travel workflow, then the problem must be with the Transition Related Issues post-function. Can you try without the Conditional Execution script?

[Krzysztof Kiser]

@David Fischer  I hid the Auto-Reopen transition again and it now works fine.
Not sure if this could have been the reason, but I might have chosen Hide transition from user instead of Hide transition (JMWE app).
When intially setting this up, I didn't notice there were two options, I only noticed it now and I think I might have chosen the wrong one before.

Anyway, it works now. It did require a few workarounds, but it works. 
I will be applying an Auto-Reopen transition to the payments workflow tomorrow. Hopefully I won't make any more mistakes.

Thank you very much for the help.

[David Fischer]

Yes, it does make a difference - the built-in Hide transition from user Condition hides the transition from... everything, including post-functions (unless you select the Skip workflow conditions option on the Transition Related Issues post-function)

I'm glad it now works. And yes, it's fairly complicated, but that's because of how Jira workflows work, they're not really designed for your particular requirement.

David

[Mashiur Rahman]