Issue Status out of sync when transitioning subtask through Issue Detail

[David Kaplan]

Hi,

After setting up a typical transition parent Story when all subtasks are marked as Done, I am seeing that if I used the Issue Detail screen for the story and transitioned the children sub-tasks using the '...' dropdown per subtask, then the status of the parent isn't being updated as expected.

For example, two subtasks, transitioning to Completed and expecting the Parent Story to transition to Completed.

But after transitioning the subtasks to Completed, if I exit the screen, navigate to the project and then back into the same Story, the status is then updated to what I hoped it would be - in this case 'Completed'

Is this a deficiency with JIRA, indexing, caching? I tried to make sure re-indexing in the post-functions was near the bottom in ordering. The post-functions for the sub-tasks use the Delayed Writing

thanks, David

[Fidel Castro Armario]

Yes, @davidkaplan177, that's the expected behavior when using delayed writing feature, due to an unfortunate modification in JIRA API since version JIRA 7.0.

Anyway, we can always use the non-delayed feature to avoid this inconvenience, but it requires to apply a boolean expression in the conditional execution parameter in order to evaluate the status of sibling sub-tasks in order to decide whether the parent issue will be actually transitioned or not.

Please, attach the following screenshots:

• Post-function's tab of the transition you are using in sub-task's workflow in order to transition parent story.
• Condition or validators tab of the transition you are automatically executing in stories workflow through a post-function in sub-task's workflow. I'm assuming that you are using a condition or validation to block that transition until all the sub-tasks are closed.

[David Kaplan]

When I changed the writing of the status to be non-delayed, I get the following error...In a screenshot and from the atlassian-log

    at java.lang.Thread.run(Thread.java:745)

2017-05-18 12:57:04,710 http-nio-8080-exec-42 ERROR kapland 777x1080038x2 1ugis72 172.21.12.103 /secure/WorkflowUIDispatcher.jspa [c.a.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 71 from workflow 100582 on issue 'TAERO3-3' com.atlassian.jira.transaction.TransactionRuntimeException: org.ofbiz.core.entity.GenericTransactionException: Commit failed, rollback previously requested by nested transaction. at com.atlassian.jira.transaction.TransactionSupportImpl$TransactionImpl.commit(TransactionSupportImpl.java:80) at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:833) at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:786)

I am not seeing the error message from the validators and I had effectively removed them in one test, so its not the validators of the parent (Story) workflow issue.

If I comment out the #2 from Post-functions, then the overall activity doesnt error. When I enable it, the non-delayed technique, I get the error, which can be seen in the screenshot and snippet of the log Also, the part about checking siblingsubtasks, what if I want to also perform the, transition Epic when all stories are complete. If the writing of the status to the Parent Epic is non-delayed, then it needs a conditional expression like subtasks-stories. But it wouldnt be checking siblingSubtasks, as these are Stories of Epics

[David Kaplan]

attached screenshots referenced in other comment

[Fidel Castro Armario]

Hi @davidkaplan177,

The problem is already known, and appeared after a modification made in the behavior of JIRA API since version 7.0. Here is a list of issues related: #248, #302, #310, #354, #408 and #479.

In order to overcome the problem, a modification was made in the behavior of the plugin, but that resulted in the problem with the screen refresh that you noticed.

Anyway, we can ALWAYS solve the problem by the usage of conditional execution and the addition of a term with function isJwtTriggeredTransition() in your validators. It can also be applied to Epic/Story and any other kind of issue link relation. I will explain you exactly how to it.

Let's begin with subtasks. Do the following 2 changes:

1) Add the following boolean expression to parameter Conditional execution in post-function "Copy a parsed text to a field" at transition Close Issue in your sub-tasks workflow:

count(siblingSubtasks()) = count(filterByStatus(siblingSubtasks(), "Completed"))

2) Use the following boolean expression as blocking validator in parent stories instead of the one you are currently using:

(!isJwtTriggeredTransition() AND %{00014} = "Story") IMPLIES count(filterByStatus(subtasks(), "Completed")) = count(subtasks())

[David Kaplan]

Ok,

I didn't think it would have mattered but that seemed to fix the workflow error I only say that because I did have the conditional siblings task in there for the attempt to write a Completed to the Parent Story status and had taken off all the validations for the attempted Parent Status change. But I think its the isJWTTriggeredTransition that prevents the validation from firing if the attempted transition was becase of JWT post-functions.

Okay, so you alluded to the notion that the conditional execution at the child could be more than just subtasks which would be needed for cases where all stories have to be complete before an attempt to mark the Epic as complete. Can you elaborate please

[David Kaplan]

btw, what did that IMPLIES part mean to the boolean expression in #2 above - thanks

[Fidel Castro Armario]

Please, let me use a bit of mathematical terminology. You are using in your validations expressions with the form A and B or !A, so that B is required when A. That can be written more simply as !A or B, which is absolutely equivalent to A and B or !A.

JWT also implements logical connective IMPLIES, which allows to write this kind of expressions more intuitively: !A or B can be written like A implies B, i.e. if A then B.

[David Kaplan]

ok, thanks for the logic explanation. pretty powerful symantics built in so I think the open item is how to similarly have a conditional execution statement for something other than stories and sub-tasks, Epics and children stories or any generic hierarchy (for example Features to children Epics)

thank you

[Fidel Castro Armario]

For a relation Epic / Story you should use the following configurations:

1) Add the following boolean expression to parameter Conditional execution in post-function "Copy a parsed text to a field" at transition Close Issue in your Stories workflow:

count(filterByIssueType(linkedIssues("is Epic of", linkedIssues("has Epic")), "Story")) - 1 <= count(filterByStatus(filterByIssueType(linkedIssues("is Epic of", linkedIssues("has Epic")), "Story"), "Completed, Accepted"))

Here I'm considering that current Story is not yet closed, that's why 1 is subtracted from the total number of Stories.

2) Use the following boolean expression as blocking validator in Epic'w workflow instead of the one you are currently using:

(!isJwtTriggeredTransition() AND %{00014} = "Epic") IMPLIES (count(filterByIssueType(linkedIssues("is Epic of"), "Story")) = count(filterByStatus(filterByIssueType(linkedIssues("is Epic of"), "Story"), "Completed, Accepted")))