How do I use the "Hide Transition" condition?

[supportap]

Example:

STatus one assigned to Joe

Joe has to click progress

Status two assigned to Joe

Joe has to click progress again

Status three assigned to Joe

Joe has to assign to Sally

Status 4 assigned to Sally

How do I use "Hide Transition" to programatically move from Status one all the way to Status three so Joe only has to click once instead of twice?

[C_ Faysal · Accepted solution]

hide won't do anything else but hiding. ther can be some additional conditions set. for automatical transitions you need to set up a listener an assign a status condition and the right action id to run preferred changes to the issue

[supportap]

Thank you. This sounds like what I'm looking for. now......... please.........:o) any links or pointers on where I can find good detailed information on how to set up all the right pieces for the automatic transitions? (I suspect I'll have to use a Generic Event since I'm using Jira5 OnDemand).

[C_ Faysal]

well your right nic. it started cunfusing me already. i start askin myself whats the use of workflow steps to be done automatically in that way. i know there are some workflow extensions in the market wich can check who last ran a transition or who was last assignee. there can be done some freaky stuff with these condition checker. also post functions. anyway a autotransition listener has to be set up matching all parameters. maybe jamies groovy script runner or a jellyscript is a good choice to find issues that match a advanced setup filter. then do action ID X i'm pretty sure there are some ways to reach the requested results. right now i cannot dive deep enough into the thread cause beside following this right here i have to DJ in a club haha. sorry if i missed any details that aleady been said

[Nic Brough -Adaptavist-]

It has to be an advanced script - the auto-transistion listener won't be able to know that Joe clicked the "bypass" button when it's trying to catch and move through the second and third transitions. Indeed, it won't even know that it was Joe pressing it in the first place.

I can't think of any good reason to force it through the three steps - the bypass transition solves the problem without code or confusion, it's completely clear what has happened to the issue.

[Nic Brough -Adaptavist-]

It's not exactly a "condition". Conditions in the workflow are simple boolean flags - they answer a question with either "true" or "false". If "true", then the transition is seen by the user. If false, then it is hidden from them.

I'm afraid I don't understand your example either - you say "status X assigned to Y", but you don't assign a status, you assign an issue. The issue's status is an indicator of where it is in the workflow.

I think what you want is an extra transition - from Status 1 to Status 4, and with a condition that somehow says "user must be Joe". You can actually do that (User is <person>), but I'd be a little more indirect and use a condition more like "user must be in group X" or "user must be in role Y", then put Joe in that group or role in the project

[supportap]

Correct it isn't. It is however an Option for setting up a "Condition" via the "View Condition" of a Transition. During a "transition" from one Status/Step to the next Status/Step, as a Post Function you can "Assign" a ticket/issue to an individual. Therefore when I say Status X assigned to Sally that's short hand for "the ticket/issue has been/or still is assigned to Individual as the result of a Post Function of the transistion from Status W to Status Y"

No, extra transitions with grouped Conditions are exactly what I don't want. I simply want to provide a way of Joe only having to click one time to advance a ticket thru multiple Statuses/Steps without having to click at every step along the way in a given situation. And no I can't eliminate the in between Statuses/Steps because there is a reason for them.

[Nic Brough -Adaptavist-]

Mmm, that's exactly why I asked - your posting was phrased in a way that was not making sense. I wasn't sure if it was the language used or just that you were leaving things out. It certainly didn't mention any form of assigning via post functions, and you didn't explain any of the "short hand".

There is no way to make one click perform three transitions directly, you'll need code. Either a coded listener that picks up whatever Joe clicks (which you can't install on OnDemand), or a coded action which fakes the historical trail through the three transitions (which you can't install on OnDemand), or an external action done via http scripting or REST (which you can do on OnDemand, but has to run on a remote machine)

The closest you can get without code is what I've already described - a transition that is only available to Joe which bypasses the others.

I'm struggling to think of a situation where you actually need to do this as well - surely your process can work fine with saying "Joe used the bypass, so you can assume it went through the intermediate steps in zero time"? Whatever the intermediate steps are doing, you can put them into Joe's bypass transition?

[supportap]

lets say we have a bug ticket and we have various project roles. Tech works ticket > clicks Move to QA server (post function assigns the ticket to the project role "file mover") >ticket advances to Status Awaiting Move to QA server > File mover, moves the files to the QA server > clicks "On QA server" (post function assigns the ticket to the project role "Lead") > ticket advances to Status Awaiting Initial QA Assignment.

Now lets say that we have a lot of multi-tasking going on by a very few people. So let's say that for this example the Tech, the file mover and the Lead are all the same person. No reason why that person should have to click at each point. Removing the statuses is not an option and for simplicity and ease of maintenance a way of advancing thru all those statuses with only one click is preferred.

If I was writing asp I would say something like

If Tech = Joe AND file mover = Joe AND Lead = Joe THEN

Do while flag < 3

Status = array[1] (Move to QA server, On QA server, Awaiting Initial QA Assignment)

tmpstring = status & status

increment flag

loop

ElseIF Tech= Fred AND file mover = Joe THEN

Status = Move to QA server

End if

Here's what the Hide Transition says - Condition to hide a transition from the user (the transition can be triggered only programmatically or from a workflow function).

I can't even find an example. If I could then I could "work it out".

[Nic Brough -Adaptavist-]

Ok, that's a very clear write up of what you're trying to do (and it certainly explains why you asked the original question), but it still doesn't really answer my business process question - why do you think "Removing the statuses is not an option"? There's no reason to have any of the intermediate status logged in any way. You know that person X bypassed them because they clicked "bypass". Why is there a reason for them to go through the status they you want them to effectively skip?

I'm really sorry, but I'm completely stumped on your definition of "hide transition", I'm not sure you are grasping what I'm trying to say, and I am sure that I am not grasping what you are saying. To try to simplify it - ALL the conditions could "hide a transition". They all say "if X, show transition to user, else hide it" I'm not sure I can say it any other way.

[supportap]

The question never had anything to do with whether anyone thought it should be done or not. The question was how could it be done and a set of parameters given. Much like you would see on a test for a Bonus Question, where the example was a Baseball field and the "Runner" MUST TOUCH EVERY BASE (or Status) in order to have their "Run" counted. Some may only hit a "Single" and advance from one Base to the next (or Status), while some may hit a "Double"or even a "Triple". Once in awhile someone gets to hit a "Homerun". But they must still go to every Base and touch it (transition thru each status) if they try to "Bypass" the bases then their "Run" is not valid and they are thrown out.

Here's what my answer was -

Create a "Sub-Task" called "I Hit a Homerun"

Associate it with a Workflow called "Homerun"

The workflow only needs two Status/Steps "Create" and "Open" Or in this case "Create" and "Homerun"

There is a "transition" between them named "OUT OF THE PARK"

There are a series of Post Function "Transition Parent Issue"

First one transitions the Parent Issue from Homeplate to First Base (status)

Second from First Base (status) to Second Base (status)

Third from Second Base (status) to Third Base (status)

Fourth from Third Base (status) to Homeplate (status) with an additional Post Function, Increment Field Value "Runs" by 1.

[Nic Brough -Adaptavist-]

Nica analogy, but still really doesn't answer what use this would be in the real world. Baseball is baseball. Jira is an issue tracker. Jumping through a string of utterly pointless transitions is complex and unnecessary when it's a) very hard to code for and b) easy to set up in a single transition.

[supportap]

While I respect both your opinions and they both have valid points, the question is not whether it should be done in a specific manner, but how does one set up a transition to be programatically triggered. The example was just that, an example, which does have real world application.

Consider this - you have a parent issue with a workflow of Support > Applications > QA > Documentation > Production. You have 4 sub-tasks. Those sub-tasks each have their own specific workflows. As the last step of a sub-task is completed the Parent workflow is transitioned programatically from Support to Applications, so on and so forth. Those in Support/Applications/QA/Documentation never need touch the parent issue, because the Parent issue is programatically advanced thru the Statuses/Steps, which is triggered by the last transition of the sub-tasks.

The Bypass is not a valid option in the first example since it does not maintain the path desired but takes the user around the statuses/steps and clearly would not work for the second example. If your system does not know which username/project role is clicking an Action Button, then you haven't set up your system to do so.

C.Faysal actually provided the clue to how to achieve what I was looking for. Thank you sir.

[Nic Brough -Adaptavist-]

Nope, still don't get it - there is still no reason here to explain why a bypass is invalid. All the points about parent/child interaction can all be addressed by the same methods you use on each individual transition.

The answer here is that you're making a lot of work for yourself because you'll need to code a whole string of stuff that will give you absolutely no benefits and tell you nothing about your processes that you couldn't do with a single step.

Unless I'm completely missing something. I really cannot see the point from what you've written here.