Why won't fast track transition back to Open?

[Kyle Moseley _blueridge_cx_]

We've got an intricate workflow for requesting a due date change. It works fine in most scenarios, unless the status is originally in Open or Reopened. It will make its way through the post functions but not qualify for the fast track. Is there some kind of event that fires that prevents this? Or could transitioning back to a Open/Reopened new status somehow fudge the transition?

fast track2.PNG

fast track.PNG

fast track2.PNG

fast track.PNG

[JamieA]

Can you check the logs... the most important thing is that the condition for all the fast-track transitions are mutually exclusive. If it didn't work, either the condition didn't match, the transition wasn't applicable, or the transition failed - the last two of those will log something.

[Kyle Moseley _blueridge_cx_]

I haven't had a chance to check the logs, but there's no reason it shouldn't work. There are multiple fast-tracks for different statuses and all work -- except for the two that revert it back to Open or Reopened status. I wondered if there was a permission issue, but it doesn't seem so. Now I wonder if it's something I have never encountered. It fast tracks to In Progress, Awaiting Response, On Hold, but not those two blue/new statuses. The custom field that the summary value is assigned to checks out -- I watch it through the entire process. The post functions prior to the fast track work, as well.

[JamieA]

Well, the logs are the first thing to check really.

[Trevor Hunt]

Jamie, each post function fast track is looking at a hidden field where I store the name of the original status... Based on that, it executes one of the 5 post functions that match. Each fast track condition looks like this (just with a different status): cfValues['hidden readonly workflow field 1'] == 'Work Halted'

[JamieA]

OK, that makes sense.

[Trevor Hunt]

Here's the piece of the workflow we're having trouble with: Date Change in Review >> Programmed Status >> Multiple Back To "Original Status" transitions. Once a due date is approved it hits a programmed status off of which the transitions returning to all other statuses. Based on the condition for the fast-track on the approval transition, one of the 5 transitions back are executed. These transitions have zero conditions... it's almost as if the index hasn't finished updating to reflect the move to the programmed status where the return transitions exist. We get the following error message in the logs intermittently..: Error Messages: [It seems that you have tried to perform a workflow operation (Back to Open) that is not valid for the current state of this issue (TESDD-3). The likely cause is that somebody has changed the issue recently, please look at the issue history for details.]

[Kyle Moseley _blueridge_cx_]

We ran some more tests and it looks like Trevor's hypothesis was right. The two fast tracks just after the index and event would not fire -- however the second one would occasionally work (which I now am guessing was depending on server load at the moment). So now I'm going to look into using thread.sleep to delay the fast tracks and hopefully bide them enough time.

[Sven Peters]

I have a similar issue: Multiple Fast Track entries as post-function (last entries). Some of them (particular the later ones) seem to work correctly, the first post-function always seems to fail. So I tend to think this might be a timing issue here too. But I can't see any entries in the logfile. Any suggestions on how to debug / fix?

[Sven Peters]

Did some more debug on the first fast-transition entry: - Condition returns true: Condition: cfValues['On-Hold Reason']?.get(null).getValue().equals('TPG') returned: true (false on the following entries) - It transitions through the expected WF transition: Transitioned issue TTSCA-187 through action "711"(Transition 711 is: Hold - TPG (711) >> ON HOLD - TPG) - BUT then the next log entry returns the old status: Final status: On-Hold (10000) (SHOULD be "ON HOLD - TPG" status) So it seems like somehow the store / save seem not to succeed?

[Sven Peters]

Is this related to https://jamieechlin.atlassian.net/browse/GRV-110 ?!