changing status in a post function

[Paul Dillon]

I have many status's in my workflow and one status for 'On Hold' I use a hidden field to hold the name of the status that the issue was on before being put on hold. That way when I return from on hold I can send the issue back to the status it came from automatically. I copy the value form the hidden field into the Status and it goes to the right place in the workflow. The history does not reflect what has just happened. It seems like the history is written with the first function which assigns the target status to whatever the arrow points to on the workflow diagram. I can redirect it but the history doesn't seem to know. Any suggestions? I need to be able to do conditional routing. Thanks

[Paul Dillon · Accepted solution]

Sorted! although a bit complex. I created another status called Release from Hold and created a transition from Hold to Release From Hold. Then created transitions from Release from hold back to the original statuses. Now what happens is that if I am on, say for example Step 3, and put the item on hold: a hidden custom field called source screen is loaded with the text 'Step 3'. If I release it from Hold a post script does a fast track transition using the value in the hidden field to select which transition to use back to the original step, in this case "Step 3". the workflow diagram looks a bit messy but the user doesn't see the screen with all of the different return transitions coming out of it. The history now shows a complete and accurate view of where the issue has been, and for how long. Thanks for the advice anyway guys.

Comment · Moderate

[Stefan Mueller]

post script does a fast track transition 

where did you put the script and how does it look like?

[Nic Brough -Adaptavist-]

No!

You can NOT just set the status of an issue (except when creating them in code like the importers). You MUST go through a transition to change status. It doesn't matter what order you do the post-functions in, you will make a complete mess of your data.

There are ways to do this, but setting the status directly is not one of them.

From memory, the JJUPIN plugin has a neat trick which allows you to appear to be doing something like this, so it might be worth looking at that, but if you just want to use plain Jira to do it, you'll need to set up a transition into each possible status out of "On hold", and then look at using conditions (your stored field is very useful here - you need to say something like "only allow transition back to Open if the custom field says Open was the last status"

[Paul Dillon]

The fast transition doen't trigger a screen refresh in MS IE. I will eventually try some of the plugins suggested but right now I have no budget for buying anything. Item Closed. Thanks guys

[Paul Dillon]

see above

[Paul Dillon]

Sorted! although a bit complex. I created another status called Release from Hold and created a transition from Hold to Release From Hold. Then created transitions from Release from hold back to the original statuses. Now what happens is that if I am on, say for example Step 3, and put the item on hold: a hidden custom field called source screen is loaded with the text 'Step 3'. If I release it from Hold a post script does a fast track transition using the value in the hidden field to select which transition to use back to the original step, in this case "Step 3". the workflow diagram looks a bit messy but the user doesn't see the screen with all of the different return transitions coming out of it. The history now shows a complete and accurate view of where the issue has been, and for how long. Thanks for the advice anyway guys.

Comment · Moderate

[Paul Dillon]

orted! although a bit complex. I created another status called Release from Hold and created a transition from Hold to Release From Hold. Then created transitions from Release from hold back to the original statuses. Now what happens is that if I am on, say for example Step 3, and put the item on hold: a hidden custom field called source screen is loaded with the text 'Step 3'. If I release it from Hold a post script does a fast track transition using the value in the hidden field to select which transition to use back to the original step, in this case "Step 3". the workflow diagram looks a bit messy but the user doesn't see the screen with all of the different return transitions coming out of it. The history now shows a complete and accurate view of where the issue has been, and for how long. Thanks for the advice anyway guys.

[Paul Dillon]

Sorted! although a bit complex. I created another status called Release from Hold and created a transition from Hold to Release From Hold. Then created transitions from Release from hold back to the original statuses. Now what happens is that if I am on, say for example Step 3, and put the item on hold: a hidden custom field called source screen is loaded with the text 'Step 3'. If I release it from Hold a post script does a fast track transition using the value in the hidden field to select which transition to use back to the original step, in this case "Step 3". the workflow diagram looks a bit messy but the user doesn't see the screen with all of the different return transitions coming out of it. The history now shows a complete and accurate view of where the issue has been, and for how long. Thanks for the advice anyway guys.

[Paul Dillon]

there is a fast track transition in Groovy Scripts that has been recommended to me, I am trying that now. I take the point about trashing the data by changing the Status, so why does it appear on the list of things you can set, if you can't? Seems a bit odd. I shall report back on how i get on with this Groovy Script. And then move on to trying various plugins as recommended by the good folks on here.

[Udo Brand]

Another solution would Misc Workflow Extension Plugin. There you can define transitions to all previous status using the previous status condition. So you always end up in the correct status after the On Hold status.

[Udo Brand]

in what order are you using the postfunctions?

• set issue status to the linked status of the destination workflow step
• status will take the value of <your hidden field>
• update change history for an issue and store the issue in the database
• ...

maybe this order will help