Sub-tasks not transitioning to closed

[ME]

We have have a transition set up on the parent workflow to close all Sub-tasks when the parent issue closes. When the parent is transitioned to Closed, the Sub-tasks are supposed to transition from Ready for SQA to Closed (not a global transition) When we execute the transition, the history on the Sub-task says that the transition took place (see pic) but the status remains in Ready for SQA.

The following are the post functions on the parent's workflow:

Initially we used #4 but then added 2 and 6 per your recommendation.

Any ideas what could cause this?

[ME]

Just updated to 2.2.8

[Fidel Castro Armario]

Hi Moshe, I have some questions:

• Which version of JIRA are you using?
• Did the behavior correctly with a previous version of the plugin, and appeared when updating to version 2.2.8?
• Please, execute JIRA Integrity Checker, and let me know if you find something wrong? You can find it at Administration > System > Integrity checker.

[ME]

Hi Fidel,

1. We are using Jira v6.4.12.
2. Didn't work in the previous or the current version. I updated today to see if that's the issue.
3. There are 2 different errors.

We didn't have this issue up until a few days ago.

[Fidel Castro Armario]

Are BHJ-370 and BHJ-429 the subtasks you tried to move with the post-function?

Please, fix the errors and then execute the post-function again.

Let me know if it solves the problem. In case it doesn't, please, execute again the Integrity Checker, and let me know if the same errors appeared again.

[ME]

Yes those are the issues I was referring to.

Fixed the error and executed.

The problem persists and the error is back (only the second error).

[Fidel Castro Armario]

Moshe, I think that your 4th post-function "Transition 481 will be triggered..." (it belongs to another plugin) is trying to also execute a transition in subtasks. I'm afraid there is a conflict between both plugins.

Please, try removing your 4th post-function, and let me know if it solves the problem.

Previously, you should fix the error using the Integrity Checker.

[ME]

Removed the "4th post-function "Transition 481 will be triggered...". Problem and errors are still there.

[Fidel Castro Armario]

I have tried to reproduce the error using a similar configuration as you, with same versions of JIRA and JIRA Workflow Toolbox, and it's working correctly.

Moshe, you said that the problem also happened with previous version of the plugin, but on the other hand you said "We didn't have this issue up until a few days ago.". Are you saying that the post-function worked correctly in the past? In affirmative case, which version of the plugin were you using then? Did you make any change in the workflow, updated a plugin, or any did any other modification that could trigger the problem?

[ME]

Yes it worked in the past. We were using 2.2.1.

We modify the workflows and update plugins on a regular basis, but nothing comes to mind that could trigger the problem. We can't correlate a specific point where we modified/updated something and it stopped working.

We fixed the errors with the Integrity Checker and re-indexed.

Would it help to see the Sub-task workflow?

We have 2 transitions to Closed - one global and one from status Ready for SQA. The global one has validators (comment+resolution required). Could that be preventing the status change?

[Fidel Castro Armario]

Hi Moshe,

Please attach screenshots with the configurations of both transitions (conditions, validators and post-functions).

Is it possible that you set the logging level for package com.fca.jira.plugins.workflowToolbox to DEBUG? To do it you should navigate to Administration > System > Logging & Profiling > Configure logging level for another package. Then, try reproducing the problem, and then share with me your server's log file (or the part relative to the problem). You can send it to [e-mail].

[ME]

Hi Fidel,

Sent logs via email.

[Fidel Castro Armario]

Hi Moshe,

I copy and paste here part of the email you sent to [e-mail]:

After looking a bit more we figured out that a line of code in our custom script listener is causing the problem.

I've added below the logs and the script that's causing the issue. The issue goes away when I disable that function in the script listener.

Script:

if(issue.getIssueTypeObject().getName()!="Sub-task"){

  for (Issue subtask : issue.getSubTaskObjects()) {

    updateIssue(subtask);

}

  updateMobileField(issue);

}

if(issue.getIssueTypeObject().getName()=="Sub-task"){ //If Issue is created

  updateIssue(issue);

}



def updateIssue(Issue issue) {

  Issue parentIssue=issue.getParentObject();

  CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager();

  CustomField parentType = customFieldManager.getCustomFieldObjects(issue).find {it.name == 'Parent Type'}

  CustomField subTaskComponent = customFieldManager.getCustomFieldObjects(issue).find {it.name == 'Parent Component > Sub Component'}

  CustomField parentComponent = customFieldManager.getCustomFieldObjects(parentIssue).find {it.name == 'Component > Sub-Component'}



  Object value = parentIssue.getCustomFieldValue(parentComponent);

  HashMap<String, Option> hashMapEntries = (HashMap<String, Option>) value



  if (hashMapEntries != null) {

                Option parent = hashMapEntries.get(CascadingSelectCFType.PARENT_KEY)

                Option child = hashMapEntries.get(CascadingSelectCFType.CHILD_KEY)



                String parentComponentValue = ""+parent+" - "+child;



                def changeHolder2 = new DefaultIssueChangeHolder();

    subTaskComponent.updateValue(null, issue, new ModifiedValue("", parentComponentValue),changeHolder2);

  }



  FieldLayoutItem fieldLayoutItem = ComponentManager.getInstance().getFieldLayoutManager().getFieldLayout(issue).getFieldLayoutItem(parentType);

  Object oldValue = issue.getCustomFieldValue(parentType);

  def changeHolder = new DefaultIssueChangeHolder();

  parentType.updateValue(fieldLayoutItem, issue, new ModifiedValue(oldValue, parentIssue.getIssueTypeObject().getName()), changeHolder);



  ((MutableIssue)issue).setPriorityObject(parentIssue.getPriorityObject());

  issue.store();

  reindexIssue(issue);

}



def updateMobileField(Issue currentIssue) {



    CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager();



    CustomField loggedIn = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'How are you logged in?'}

    CustomField deviceExperience = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'Which devices are experiencing the issue?'}

    CustomField browserExperience = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'Which browsers are experiencing the issue?'}

    CustomField traffic = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'Traffic of affected area'}

    CustomField component = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'Which component of the site has the bug?'}

    CustomField poorUserExp = customFieldManager.getCustomFieldObjects(currentIssue).find {it.name == 'Does the bug cause poor User Experience?'}



    String mobileFieldValue = "";

    mobileFieldValue += loggedIn.toString() +": "+ currentIssue.getCustomFieldValue(loggedIn)+". \n";

    mobileFieldValue += deviceExperience.toString() +": "+ currentIssue.getCustomFieldValue(deviceExperience)+". \n";

    mobileFieldValue += browserExperience.toString() +": "+ currentIssue.getCustomFieldValue(browserExperience)+". \n";

    mobileFieldValue += traffic.toString() +": "+ currentIssue.getCustomFieldValue(traffic)+". \n";

    mobileFieldValue += component.toString() +": "+ currentIssue.getCustomFieldValue(component)+". \n";

    mobileFieldValue += poorUserExp.toString() +": "+ currentIssue.getCustomFieldValue(poorUserExp);



    for (Issue subtask : currentIssue.getSubTaskObjects()) {



        CustomField mobileField = customFieldManager.getCustomFieldObjects(subtask).find{it.name == 'Mobile Issue Details'};



                def changeHolder = new DefaultIssueChangeHolder();

                mobileField.updateValue(null, subtask, new ModifiedValue("", mobileFieldValue),changeHolder);

        subtask.store();

                }

}

Relevant part of the log file:

2016-03-11 11:32:01,968 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" IS AVAILABLE FOR ISSUE "BHJ-2629" FOR GOING FROM STATUS "Ready for SQA" TO STATUS "Closed".

2016-03-11 11:32:01,972 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" ON ISSUE BHJ-2629 AT STATUS "Ready for SQA", CAN'T BE EXECUTED DUE TO CONDITION NOT SATISFIED. DETAILS: It seems that you have tried to perform a workflow operation (Auto-close) that is not valid for the current state of this issue (BHJ-2629). The likely cause is that somebody has changed the issue recently, please look at the issue history for details.

2016-03-11 11:32:01,977 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EVERY CONDITION IN TRANSITION "Close" FOR ISSUE BHJ-2629 IS SATISFIED. TRANSITION EXECUTION IS GOING TO BE ATTEMPTED.

2016-03-11 11:32:01,982 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EXECUTION OF TRANSITION "Close" ON ISSUE BHJ-2629 AT STATUS "Ready for SQA", HAS FAILED DUE TO A VALIDATOR NOT BEING SATISFIED.

2016-03-11 11:32:01,987 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EVERY CONDITION IN TRANSITION "Migration Notes" FOR ISSUE BHJ-2629 IS SATISFIED. TRANSITION EXECUTION IS GOING TO BE ATTEMPTED.

2016-03-11 11:32:02,290 ListenableFutureAdapter-thread-1136 ERROR shloimie 692x462585x2 4iieu 192.168.116.86 /rest/dev-status/1.0/issue/summary [provider.source.cache.CachingProviderDecorator] json for issue 11759 is too big its size is 67244

2016-03-11 11:32:02,739 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.listeners.EndOfTransitionEventListener] *** WORKFLOW EVENT INVOKED FOR ISSUE BHJ-2629

2016-03-11 11:32:02,740 ajp-bio-127.0.0.1-8009-exec-62 DEBUG mosheeh 692x462583x1 93ch96 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.listeners.EndOfTransitionEventListener] *** REINDEXER-WRITER LISTENER INVOKED BY EVENT Generic Event / ISSUE: BHJ-2629 / PARAMS: {eventsource=workflow, baseurl=http://jira-web.bnh.com}

[Fidel Castro Armario]

Hi Moshe,

Try the following modification:

Edit post-function 6 and select "Issue status (delayed writing)" at target field parameter.

Please, let me know if this modification solves the problem.

[ME]

Hi Fidel, That worked. Many thanks for your assistance.

[Fidel Castro Armario]

Great!

[ME]

Hi Fidel, We are having this again and we can't seem to figure it out. Up unitl a few days ago it worked fine with the above mentioned fix ["Issue status (delayed writing)"]. Integrity Checker shows an error and fix doesn't solve it. Please assist Thanks Much Moshe

[Fidel Castro Armario]

Can you please attach a screenshot of current post-function's tab configuration in the transition? I want to see all the post-function that are being executed.

[ME]

Here you go.

[Fidel Castro Armario]

Moshe, do the following changes:

1) Remove post-function number 2 (i.e., "Copy a parsed text to a field").

2) Move post-function number 4 (i.e., "Write field on linked issues or subtasks") to first position in execution order.

3) Edit post-function "Write field on linked issues or subtasks" (now in position 1) and do the following changes:

1. Select source value parsed text (basic mode)
2. Enter the following text in the value textbox:

Closed : {delay=3000}

We use delay parameter for setting the delay exact delay (in milliseconds) to be applied for status change once current transition has finished.

[ME]

Hi Fidel, Done, did not resolve the issue. Integrity Checker still shows the same error.

[Fidel Castro Armario]

I warn you that with current configuration you should wait for 3 seconds before checking whether the transition on subtasks has been executed.

Please, set logging level for package com.fca.jira.plugins.workflowToolbox to DEBUG. To do it you should navigate to Administration > System > Logging & Profiling > Configure logging level for another package. Then, try reproducing the problem, and then share with me your server's log file (or the part relative to the problem). You can send it to [e-mail].

[ME]

Sent the logs via email.

[Fidel Castro Armario]

Hi Moshe,

This time the problem is that conditions in transition "Auto-close" are not being satisfied, and validations in transition "Close" are not being satisfied.

This is a fragment of your log file:

/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" IS AVAILABLE FOR ISSUE "BHJ-2739" FOR GOING FROM STATUS "Ready for SQA" TO STATUS "Closed".

2016-04-21 17:40:33,429 ajp-bio-127.0.0.1-8009-exec-146 DEBUG mosheeh 1060x715488x1 k9ksee 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" ON ISSUE BHJ-2739 AT STATUS "Ready for SQA", CAN'T BE EXECUTED DUE TO CONDITION NOT SATISFIED. DETAILS: It seems that you have tried to perform a workflow operation (Auto-close) that is not valid for the current state of this issue (BHJ-2739). The likely cause is that somebody has changed the issue recently, please look at the issue history for details.

2016-04-21 17:40:33,437 ajp-bio-127.0.0.1-8009-exec-146 DEBUG mosheeh 1060x715488x1 k9ksee 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EVERY CONDITION IN TRANSITION "Close" FOR ISSUE BHJ-2739 IS SATISFIED. TRANSITION EXECUTION IS GOING TO BE ATTEMPTED.

2016-04-21 17:40:33,475 ajp-bio-127.0.0.1-8009-exec-146 DEBUG mosheeh 1060x715488x1 k9ksee 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EXECUTION OF TRANSITION "Close" ON ISSUE BHJ-2739 AT STATUS "Ready for SQA", HAS FAILED DUE TO A VALIDATOR NOT BEING SATISFIED.

Please, check the condition or validator in the transition you want to be executed, in order to guarantee that they are satisfied at the moment of transition execution.

[ME]

I realized that from the logs however I can't seem to figure which validator would cause this problem. See validators:

[Fidel Castro Armario]

The problem may be caused by validator 1, since when you execute the transition automatically a comment is never entered.

Please, replace that validator with "Boolean validator with math, date-time or text-string terms" using the following configuration:

Boolean expression is:

%{00127} != null OR isJwtTriggeredTransition()

Note that %{00127} is field code for "Transition's comment".

BTW, do you really have a resolution called "Please select..."? If you want to check whether there is a resolution selected, you usually should use the following boolean expression:

%{00028} != null

Being %{00028} field code for "Resolution".

You may also need to add function isJwtTriggeredTransition() to your second validator in order to allow execution of transition with empty resolution when transition is executed automatically. In that case you should use the following boolean expression:

%{00028} != null OR isJwtTriggeredTransition()

[Fidel Castro Armario]

Hi Moshe, any news about this issue?

[ME]

Hi Fidel, I'm out of work this week and won't be able to try it until I get back. Will post back then. Best regards

[ME]

Hi Fidel, I don't want the default to be one of our resolutions, I want to force the user to choose one. In that case are you saying I would need to do this?

%{00127} != null AND %{00028} != null OR isJwtTriggeredTransition()

[Fidel Castro Armario]

I recommend you to use two different validations, that way you can show the user specific error messages when a validation fails. You should replace your first 2 validations with two "Boolean validator with math, date-time or text-string terms" with the following configurations:

1) Validation on resolution:

%{00028} != null OR isJwtTriggeredTransition()

Error message: Please, select a resolution..

2) Validation on comment:

%{00127} != null OR isJwtTriggeredTransition()

Error message: Please, enter a comment..

A pair of questions:

1. Do you have a resolution called "Please select..."? I imagine you don't, but want a confirmation.

2. If you expect the user to enter manually the resolution in parent's "Close Issue" transition screen, what happens when transition is triggered automatically when the last subtask is closed?

We can define a set of rules based on subtasks' resolutions for auto-setting parent's resolution. For example:

• If at least a subtask is closed as resolved, then parent issue is closed as resolved.
• If there isn't any subtask closed as resolved, then use the resolution of the last closed subtask.

We can use "Set a field as a function of other fields" post-function for implementing those rules.

[ME]

Hi Fidel, I just replaced the first validator with you recommendation [%{00127} != null OR isJwtTriggeredTransition()]. However it did not solve the issue. Integrity Checker still shows the error, however, the logs don't.

2016-05-02 14:44:58,506 Timer-108 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.DelayedReindexerManager] *** REINDEXING [BHJ-2739]
2016-05-02 14:44:58,540 Timer-108 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.tasks.ReindexerTask] *** FIRST REINDEXATION EXECUTED FOR 1 ISSUES.
2016-05-02 14:44:58,577 Timer-109 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.DelayedReindexerManager] *** REINDEXING [BHJ-2739]
2016-05-02 14:44:58,613 Timer-109 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.tasks.ReindexerTask] *** FIRST REINDEXATION EXECUTED FOR 1 ISSUES.
2016-05-02 14:45:03,541 Timer-108 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.DelayedReindexerManager] *** REINDEXING [BHJ-2739]
2016-05-02 14:45:03,580 Timer-108 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.tasks.ReindexerTask] *** SECOND REINDEXATION EXECUTED FOR 1 ISSUES.
2016-05-02 14:45:03,614 Timer-109 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.DelayedReindexerManager] *** REINDEXING [BHJ-2739]
2016-05-02 14:45:03,647 Timer-109 DEBUG mosheeh 884x1182307x1 2n9pll 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.tasks.ReindexerTask] *** SECOND REINDEXATION EXECUTED FOR 1 ISSUES.

Thanks for your assistance on the matter.

[Fidel Castro Armario]

Hi Moshe,

It seems that you have a problem with your workflow, may be related with an import operation, or with a migration of issues from a workflow to another one. I don't think it has anything to do with the plugin.

Please, try to close manually the parent issue and check whether the integrity problem appears.

Please, also send me the whole log file to [e-mail].

[ME]

Sent via email. Waiting to hear from you. Thansk

[Fidel Castro Armario]

Hi Moshe,

The log file you sent me shows that transition "Auto-close" has been executed successfully on issue BHJ-2739:

2016-05-03 11:43:15,356 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" IS AVAILABLE FOR ISSUE "BHJ-2739" FOR GOING FROM STATUS "Ready for SQA" TO STATUS "Closed".

2016-05-03 11:43:15,363 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** EVERY CONDITION IN TRANSITION "Auto-close" FOR ISSUE BHJ-2739 IS SATISFIED. TRANSITION EXECUTION IS GOING TO BE ATTEMPTED.

2016-05-03 11:43:15,381 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.listeners.EndOfTransitionEventListener] *** WORKFLOW EVENT INVOKED FOR ISSUE BHJ-2739

2016-05-03 11:43:15,381 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.listeners.EndOfTransitionEventListener] *** REINDEXER-WRITER LISTENER INVOKED BY EVENT Generic Event / ISSUE: BHJ-2739 / PARAMS: {eventsource=workflow, baseurl=http://jira-web.bnh.com}

2016-05-03 11:43:15,381 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** OPERATION: PROCESS; MODE: PEEK BHJ-2739; INITIAL SIZE: 1; FINAL SIZE: 1; RETURNED: null

2016-05-03 11:43:15,382 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.DelayedReindexerManager] *** REINDEXING [BHJ-2739]

2016-05-03 11:43:15,447 ajp-bio-127.0.0.1-8009-exec-187 DEBUG mosheeh 703x1426027x1 a39w2z 192.168.119.157 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.IssueTransitionManager] *** TRANSITION "Auto-close" ON ISSUE BHJ-2739 HAS BEEN EXECUTED SUCCESSFULLY.

I think that it's possible that you are expecting that the browser will show the new status immediately in the parent's detail page, but it's not being shown due to a delay in the execution of transition on subtasks.

Please, try refreshing your browser after closing parent issue, and then check whether subtasks have been automatically closed.

[ME]

Hi Fidel, I have been that the whole time and now again. No changes. I'm just as suprised as you pointed out the logs show that everything has been executed as it should be. Any other thoughts? If you would like to, we can do a webex so you can have a closer look. Thanks

[Fidel Castro Armario]

Hi Moshe, I will be available for a Webex at 20:15 UTC. Is that time ok for you?

[ME]

Hi Fidel, Yes that should be fine. Please give me email where to send webex invitation. Please let me know if you want to be on the phone as well. Thanks

[Fidel Castro Armario]

Sorry, Moshe I haven't realized you had confirmed the time. Can we, please, set a new time for the video-conference 21:30 UTC? Please, confirm as soon as possible since I have to move to different building to have the meeting.

[ME]

21:30 UTC is fine if we can do it quickly as I will need to leave at UTC 22:00.

I can only do screen share at this time. Do you want to be on the phone at the same time?

Please confirm.

[Fidel Castro Armario]

Can we have the video-conference just now? I want to use the mic of my computer. My email is [e-mail].

[Fidel Castro Armario]

Moshe, I'm ready for the video-conference.

[ME]

I' ready now. Need an email address to WebEx invite?

[Fidel Castro Armario]

[e-mail]

[Fidel Castro Armario]

I can't invite you to Webex since I don't have the service. I though you were going to invite me. I can use Skype if you prefer it. My user is fidel100r.

[Fidel Castro Armario]

After a video-conference with your partner we find out that the problem happens when a script listener triggered by Generic Event is enabled. I'm attaching the script to the issue.

The interaction of the listener with JIRA Workflow Toolbox is causing an inconsistency between the status of the subtask and the step in the workflow: the step is changing but the status is resting unchanged.

[Fidel Castro Armario]

Please, try version 2.2.11_beta_4 keeping your listener enabled.

Don't forget to pass the integrity checker after the test.

[Fidel Castro Armario]

Fixed in just released version 2.2.11.

[ME]

Hi Fidel, Good to hear that you guys where able to figure it out. I seems to have solved the issue and the found no errors. The issue we have that wasn't there in the past, bulk update wont work and gives the validator comment needed error. Seems like the validator on the subtask workflow is causing it based on the error message.

Thanks again for your continued assistance

[Fidel Castro Armario]

I'm not sure what you mean by "bulk update", but the transition to be executed on subtask's workflow by the post-function in parent's workflow is "Auto-close". But I think that the transition with those 2 validators is the global transition "Close", which is reserved to interactive users, not to automatic executions.

This problem didn't happen when I was testing the workflows with your partner.

Anyway, try replacing your current boolean expression with:

%{00127} != null OR isJwtTriggeredTransition()

[ME]

Let me clarify: When I bulk close the subtasks it will give me an error asking for a comment. This happens when I bulk close multiple subtask directly or by bulk closing multiple parent issues. The common denominator, they both are the same error being caused by the subtask validator.

I went ahead and updated the validator as per your recommendation. I did NOT solve the issue.

[Fidel Castro Armario]

Are you using "Modify Multiple Issues" feature of JIRA for doing the bulk close of subtask or parent issues?

[ME]

Yes (sorry for not emphasizing that).

[Fidel Castro Armario]

JIRA Workflow Toolbox currently doesn't have a function for detecting bulk operations, that you could use like this:

%{00127} != null OR isBulkTriggeredTransition()

I will try to include it in next version of the plugin. Meanwhile, I recommend you to replace boolean validator with the validator you were using previously for requiring a comment from the user.

I suppose it's provided by another plugin.

[Fidel Castro Armario]

I have implemented function isBulkTriggeredTransition() in version 2.2.12_beta_1. Using this version you can solve your problem simply using the following boolean expression:

%{00127} != null OR isBulkTriggeredTransition()

You can use the beta version in production environment with confidence, since it only differs from version 2.2.11 in that new function.

[ME]

Oh great. Thanks so much. Will try on Monday and report back then.

[ME]

Works (when added to the parent and the subtask workflows). Thanks again for the Help.