Workflow triggers Workflow

Answered

I am currently evaluating the use of Youtrack for our company. We have a sample project with multiple levels of sub-tasks. We added a field called "Remaining Effort" to the project. The structure is as following:

 

Master

  -Parent

    -Sub-Task

 

I have created two workflows. The first one works as I imagine it should. Whenever the Effort of a sub-task is updated. The workflow calculates the Effort for the parent:

 

rule Calculate Remaining effort for parent task upon change
 
when Remaining Effort.changed && issue.subtask of.isNotEmpty {
  for each parent in issue.subtask of {
    var effnew = issue.getPeriodFieldValueInMinutes("Remaining effort");
    var effold = issue.getPeriodFieldOldValueInMinutes("Remaining effort");
    var pareff = parent.getPeriodFieldValueInMinutes("Remaining effort");
    parent.setPeriodFieldValueInMinutes("Remaining effort", pareff + (effnew - effold));
  }
}

 

When the Parent is updated the script is triggered again and updates the effort of the master.

 

I wrote another workflow that is supposed to react on adding a subtask. It updates the value of the Parent. However this workflow does not trigger the first script and therefore the effort in the master is not updated.

 

rule Increase Remaining effort if sub-task is added
 
when parent for.added.first != null {
  var childeff = parent for.added.first.getPeriodFieldOldValueInMinutes("Remaining effort");
   
  var pareff = issue.getPeriodFieldValueInMinutes("Remaining effort");
   
  issue.setPeriodFieldValueInMinutes("Remaining effort", pareff + childeff);
}

 

What is the expected behaviour for workflows triggering other workflows?

Why does it work in one case but not in the other?

Is there another way to create a field with similar behaviour as Estimate or Spent Time?

 

1 comment
Comment actions Permalink
Official comment

Hello David, thank you for reaching out!
1) The order of stateless rules is not fixed, so you can't actually expect one rule to be triggered before or after another.
2) It's safer to make a separate workflow rule for each separate case, so that in each case you trigger only one rule.
So in the first rule you need to check that subtask's time is updated (according to the type or to the lack of further subtasks), update its parent and then update their master. And in the second rule you'll react to adding a new subtask, and manually add delta time to the upper nodes of your tree.

Here are some insights on how our workflows work. They don't trigger each other directly, they use the following logic:

1) A user changes something.
2) Each change happens in some transaction. Before the set of changes from a transaction is transferred to the database, stateless rules are triggered.
3) For each separate task is in a transaction all rules attached to this task's project are triggered one after another. The order of these rules is not determinated.
4) If after triggering of all rules for all tasks in the transaction the set of changes differs from the initial one, step 3 is repeated, but this time only those rules are triggered that weren't triggered on the previous step.
5) Step 3 repeats up to 10 times.

 

I hope this clarifies things a bit. Please don't hesitate to ask if you have any further questions. Thank you.

Please sign in to leave a comment.