workflow for blocking estimation updates

  • 11
  • 33

Hi,

I have created a few workflows, their a bit of a higgledy piggledy to write - mostly because the ide is a PITA that is trying to hard to control (cannot even copy all and paste! oh la la)

However, i have one specific problem with trying to add a workflow that would block modifications to the Estimation for a Parent task.

We have a Parent task for most projects, and it has dependent subtasks or relations. We like the fact the parent task Estimation is automatically calculated from the Children - However, if someone accidentally touches the estimation field on the parent it disables the functionality and we have found no way to restore it.

Thus, i wanted to create a workflow that would block changes to Estimation field when the issue has children, or if it had a tag we created called "ProjectParent".

The workflow kind of works, but when you want to edit the estimation for any subtask it is also being caught, i can only imagine because the youtrack is raising up the event to the parent which is the one that triggers the condition to be met and blocks the change. The lack of documentation and not being able to find any other workflows with similar behavior leads me to this forum.

Example of my problem workflow is here -> http://screencast.com/t/01sFTnsb & here http://screencast.com/t/EYNTQX0rZnF

Many thanks in advance for your support!!!
Try to join these cases into the one:
rule estimations 
 
when Estimation.changed { 
  assert parent for.isEmpty && !hasTag("ProjectParent"): "Cannot change the 'Estimation' for a parent issue."; 
}


Is it suitable for you?

I am using the above rule (with and without the && !hasTag), but it always prevents editing of the field. What am I missing?

Screenshot from 2014-10-28 11:27:26.png (122KB)

So I have used both of 'parent for.isEmpty' and 'parent for.isNotEmpty' and both trigger the alert.

But 'assert Assignee == Assignee' and 'Assignee != Assignee' work as expected. So clearly something strange is going on with 'parent for'.

'parent for.isEmpty == true' and 'parent for.isEmpty == false' both trigger the assertion.

I added a 'message(parent for.isEmpty + "") and that showed a message of 'True'.

Ok, I see what is happening. Because the estimations are rolled up from subtask to parent this rule fires due to the rollup setting the parent's Estimation.

So I guess there is no way to prevent a user from editing this field on non leaf issue.

No, that's not it. Going to file an issue for this...

Thank you for your response.

In theory, it would be suitable. The only issue is that, if you add subtasks, it is also blocking adding estimations for the subtasks. Probably because another default workflow tries to carry the adjustment up to the parent - which is what we want - we like it automatically calculating the parent tickets total estimation as a sum of all childrens.

however, in this scenario we cannot add/modify estimates for any ticket that is a subtask, which is not the desired outcome, only to block modifying the estimation on the parent itself?

I just not sure where else in youtrack this runs, and also if its possible to handle the rule in such a way to say "only do this when modifying the parent directly".

Any further support would be hugely appreciated!

According this rule it's only restricted to the parent task 'Estimation' field to be changed.

All workflows are under your control on the project > 'workflows' tab.

Note, the 'period' field that is attached as 'Spent time' field on "Time tracking" project's tab automatically collects subtasks 'spent times' and it's unmodifiable for parent task.

Please check that 'Estimation field' isn't chosen as 'Spent time' field.

We have checked, and no the estimation and spent time fields are separate and this is not related to that issue.

The problem remains that the Estimation field is type time, and is editable in the parent, although it does calculate automatically also unlike the spent time field it is not protected - and if someone accidentally touches it on the parent it destroys the automatic calculation - hence my wish to block edits of that field for parent tickets.

The described above rule should prevent parent task from the 'Estimation' field modifications.

Please detach all other workflows to check if it works as expected.
How did you implement 'Estimation' in parent? Unfortunately the feature JT-18128 isn't implemented yet.

If problem remains please post all related workflows here.