Subtask error Jira 7

[Rob Schalken]

When I do a parent update (issue status) from a subtask I get the following error: "org.ofbiz.core.entity.GenericTransactionException: Commit failed, rollback previo"usly requested by nested transaction"

Conform the 2.2.10 this should be solved (https://bitbucket.org/fcarmario/jira-workflow-toolbox/issues/302/generictransactionexception-commit-failed), but I still got the error.

Hope you can help me soon (beta version is also an option off course)

Version Jira 7.1.4 Version Workflow toolbox 2.2.10

Rob

[Fidel Castro Armario]

Please, attach the following screenshots:

• Post-function tab of subtask's transition.
• Conditions and validations tab of parent's transition you are trying to execute.

If possible, please send your server's log file for [e-mail].

[Rob Schalken]

Normally (Jira version 6.3.8) it wasn't a problem that the parent was blocked by the parent is validations. But now it seems like a problem.

[Fidel Castro Armario]

This is caused by an unfortunate API modification done by Atlassian on JIRA 7.0.

Recent versions of the plugin implement certain modifications in order to minimize the impact of this change in the JIRA API. I wish Atlassian changes its mind on this, but it seems highly improbable.

Anyway, there is simple solution: just select "Parent's issue status (delayed writing)" as target field in "Copy a parsed text to a field" post-function of JIRA Workflow Toolbox 2.2.10 or higher.

[Fidel Castro Armario]

Hi Rob, did the solution I gave you work?

[Rob Schalken]

Sorry for my late reaction, yes this does do the trick.

[Fidel Castro Armario]

Ok, thanks for the feedback.

[Rob Schalken]

Hello,

The "Parent's issue status (delayed writing)" gives some problems. My parent is responding different on the subtask transition. Could you explaing the difference between (delayed writing) and the normal writing so that I can adapt conditions/validations?

Hope you can help me.

Rob

[Rob Schalken]

Still not working, added a question 3 days ago

[Fidel Castro Armario]

Hi Rob,

I'm Sorry, not realizing that you put a question. The fact that the issue was closed didn't help to see it.

The difference between "Issue status" and "Issues status (delayed writing)" virtual fields is explained in section "Some preliminary explanations" of this "Make Linked Issues and Subtasks Progress through its Workflows".

You need to know that since JIRA 7 a change in JIRA API has forced to do some modifications in the plugin in order to avoid "GenericTransactionException: Commit failed, rollback previously requested by nested transaction"" error.

This modification consists in executing the transition in a separate thread, but this solution has an undesired effect: it won't show the information related with the auto-transitioned issue just after return of the interactive transition execution, i.e., you will need to refresh your browser in order to see the changes on the auto-transitioned issue.

Anyway, there is a solution to have the exact same behavior as before, i.e., avoiding the issue that forces to refresh the browser in order to get updated the information related with the auto-transitioned issue. The solution consist on:

1. Use "Parent's issue status" instead of "Parent's issue status (delayed writing)" as target field.
2. Use parameter "Conditional execution" in "Copy a parsed text to a field" post-function for ordering parent issue transition execution only when we are sure that all the conditions and validations are going to be satisfied. To do it we should input a boolean expression that checks the same validations and conditions we have implemented in transition "Close" in parent's workflow. In your particular case the boolean expression to be used is:

count(filterByPredicate(siblingSubtasks(), ^%{00014} != "Sub-task" OR ^%{00016} != "Closed")) = 0

We don't need to implement the only condition you have in parent's workflow in the boolean expression, since it's always satisfied when transition is triggered by a subtask (due to the term {Number of subtasks} > 0).

[Rob Schalken]

It is almost working, but the transition to review (all subtask must be "Review - Test" or "Closed") I still get an error, I tried somewhat everything, but nothing does do the trick and gives an error: "org.ofbiz.core.entity.GenericTransactionException: Commit failed, rollback previously requested by nested transaction."

The condition which I am now using is (which is incorrect): count(filterByPredicate(siblingSubtasks(), ^%{00014} != "Sub-task" OR ^%{00016} = "Open" OR ^%{00016} = "In progress")) = 0

Any suggestions?

[Fidel Castro Armario]

You should write the names of the statuses exactly as they are, and I think that your are writing mistakenly "In progress" instead of "In Progress".

Anyway, you can try this boolean expression:

count(filterByPredicate(siblingSubtasks(), ^%{00014} != "Sub-task" OR ^%{00016} not in ["Closed", "Review - Test"])) = 0

[Rob Schalken]

You where correct on this. Now I have the last problem. I use the checklist plugin for my acceptance criteria. How can I verify if all items from my checklist are checked (this is a parent validator).

[Fidel Castro Armario]

Rob, Is that verification related with the original problem of this issue? I negative case, please, create a new issue. Thanks.

[Rob Schalken]

It is related, because in Jira version 6 the validation was blocking the parent and now we get an error.

[Fidel Castro Armario]

Rob, can we have a screen-share through Skype and talk about the problem? My Skype user is fidel100r. I will be available until 13:00 UTC.

[Rob Schalken]

Then I will call you around 12:00 UTC because I am now going in a meeting.

[Fidel Castro Armario]

Ok.

[Fidel Castro Armario]

Rob, it's 12:21 UTC. Will you be able to have the screen-share with me?

[Fidel Castro Armario]

Hi Rob,

Try using version 2.2.12_beta_4 with the following boolean expression in Conditional execution parameter:

count(filterByPredicate(siblingSubtasks(), ^%{00014} != "Sub-task" OR ^%{00016} != "Closed") AND numberOfSelectedItems(%{aaaaa}) = numberOfAvailableItems(%{aaaaa})) = 0

replacing aaaaa with field code of your Check List custom field in parent issue.

[Fidel Castro Armario]

Rob,

Please, do the following:

1. Set logging level for package com.fca.jira.plugins.workflowToolbox to DEBUG. You can do it at Administration > Logging and profiling > Configure logging level for another package

2. Reproduce the failure using "Parent's issue status (delayed writing)" at target status, and with parameter Conditional execution empty.

3. Share with me your log file, please.

Thank you.

[Rob Schalken]

Hello Fidel,

Hereby the requested log, I hope this solves our problems.

Rob

[Fidel Castro Armario]

Thank you Rob for the log file.

Can you, please, attach the XML files of both workflows: parent's and subtask?

[Rob Schalken]

And the workflows

[Fidel Castro Armario]

Hi Rob,

Try this change:

Exchange execution order of post-function "Copy a parsed text to a field" and "Fire a Issue Closed event that can be processed by the listeners." post-functions at "Close" transition in subtasks workflow. Like in the screenshot:

Indeed, I always recommend to insert your custom post-functions BEFORE all the default post-functions present in any JIRA workflow transition:

[Rob Schalken]

this indeed does the trick. this issue can be closed. Thank you for your great support.

[Fidel Castro Armario]

Great!

By the way, I also solved the problem with the API for Checklist, so as a side effect, next version plugin will have support for reading Checklist for JIRA custom fields.