Chaining status changes

[akunnari]

Hello,

I am building a workflow for my interface. This means that each status needs to be able to jump to each other status, since such transitions are not restricted beyond Jira in our house own ERP-System.

I could have just made every status accessible from every status, which might be the better solution now that I am writing it down... But nontheless I did not do that.

My solution for this problem is at this moment a "transition" status which lies between the other statuses. So every status can jump into the "transition" status and then jump from there to anything else (Except "open").

Our customers have the possibility to trigger transitions from the customer portal, when they give feedback to their software-tests.

I don't really want to add a transition to my workflow which would allow the customer to just transfer from the status "in testing" to "test successfull". Rather I'd like for the customer to see the words "Test successfull" and "Test unsuccessfull" which would trigger the transition "In testingt" --> "transition" --> "Test un-/successfull".

Is there a way to add a followup function to a transition, which triggers a second transition?

In Automation I am only able to set the When status of "on status change" which doesn't help me here, since I only want this to happen on a certain status.

I also have JSU Automation Suite for Jira Workflows - Server Version but it diens't seem to help here either, since the only follow-up function which seems to have an effect is the "Follow up transition (JSU)" but its condition is the user triggering the transition and thats not really an option for me, since I can't define which one of the mutiple possible transitions from the "transition" status is to be triggered after the transition...

I know I can just rethink my workflow in general, which is propably what I am going to do anyways after writing this thing down, but I'd still be interested in a possibility of triggering a status change after a certain different statuschange to a certain status.

If anyone has any ideas I#d love to hear them ! :)

[akunnari · Accepted solution]

Woops I'm in the wrong sections as it seems!

MY bad!

[Iago Docando]

Quick suggestion for what you might be trying to achieve, as far as I've understood (of course you'll have to use your actual statuses).

The blue transitions must have a condition that users in the group customers (for example) can't execute them. The red transitions mus have a condition that ONLY the users in that group can execute them.

I hope it helps.

[akunnari]

This is pretty much what I want, but the problem is, that our workers could transition from "in progress" to "working fine" inside our own ERP System. What the interface would have to do then is to know hwo these 2 status are connected, execute the statuschange from "in progress" to "testing" to "done" to "wokring fine" but there is already a catch. It would be a hella much work to define every possible transition chain we have in our company (we have like 25 internal staus' a ticket can have) and thats why I tried to create this solution.

What the customer should be able to do is to activate the transition "in testing" --> "Good/bad" which would internally go from "in testing" to "transition" to "good/bad" without the customer even noticing, that the ticket was ever in the "transition" state

[Iago Docando]

I believe you're overthinking it a bit :)

Instead of complicated automated routes A-B-C-D or A-B-C-E just create as many A-D or A-E transitions as you need, of course propprerly configuring any condition or postfunction.

I might be missing something from your explanation but in general I would advise you to not to create any status if your process doesn't take into account moving the issue to that status. I mean, either tell the user that he must update the status to "testing" when he's about to start testing or remove the status entirely and go directly from "in progress" to "working fine" once he's done testing (just an example, do what you  think suit best you actual process). In this second case you could use something like a custom screen to promt the user for info like testing start date / end date / actual time spent in testing between those dates... everything goes.

Of course jira (or whatever other tool) is just used to document and trace the processes we've previously designed, they aren't the processes themselves. 

[Thorsten Letschert _Decadis AG_]

Hi @akunnari ,

While I'm having a solution in mind, I don't quite get, what the actual difference between those two scenarios should do:

1. Have direct transitions to the target statuses 'test successful' and 'test not successful' vs.
2. Have indirect transitions to the target status 'transition' that then automatically (and that's my twist) transition to the target statuses from 1.

Could you please clarify?

Cheers
Thorsten

[akunnari]

Hi @Thorsten Letschert _Decadis AG_ ,

so there is no real difference between these 2 scenarios except for a unified workflow.

Since we can transition between any status in our own System we want that to be possible in jira as well. So that we dont have to hardcode specific transition chains into the inferface. Like when our own ticket goes from "in development" to "done" the interface should just be able to transition from the one status in jira to the other, without having to first go through the entire workflow (in development" "internal testing" ... "in shipping" ... "done" ) in jira. Thats the reason of the "transition" status.

We will save the IDs for the transitions from the "transition" status to every other status in our erp system, same with the one transitionID from every status to "transition". Now if I would make extra transitions like the ones in Sceanario 1 following problem would occure:

1. I cannot create a transition from "in testing" to "un-/successfull" if both are accessible from every status ("there is already a transition between these status'" error occures)

2. To overcome this problem I would have to delete the possibility to transfer into these ("un-/successfull") from every other status.

3.This would lead to the nessecity to create transitions from every OTHER status to "successfull" and "unsuccessfull" which would lead to a million different transistion IDs. (Eg. "from in development to unsuccessfull" "from being analyzed to successfull")

Our workflow is defined, but our workers are not forbidden from doing "unusual transitions" since every transition might someday have a use-case. We don't usually make such transitions, but since we are using an interface between these two systems, we have to make it as robust as possible. It needs to know how to handel these situations without having a table inside a database with a million different combinations for transitions. Thats the reason I would like to only have this central "hub" of transitions, since it would limit the amount of data we need to store.