is it possible to change a status only after two parallel transitions?
An article can only get published on the website after a.) the head of marketing and b.) the head of distribution sayed okay:
|--------------------------> Check by marketing ------|
ARTICLE |---------> Ready for publishing
|--------------------------> Check by distribution -----|
It's not impossible, but it's tricky. You could do it by having the parallel transitions each refer back to the starting status, and also set a custom field to flag which check was performed. You'd use a condition so each transition is hidden if the check has already been done (check the value of the custom field as the condition), and then either use "Fast track Workflow Transition" in a post-function to transition to "ready for publishing" if the other one is met (as in, if the check for marketing transition is followed and "checked by distribution" custom field is set, transition to ready), or else have two more conditional transitions, as follows:
ARTICLE ---- Check by marketing ---> ARTICLE (condition, "checked by distribution" is not set, set "checked by marketing")
ARTICLE ---- Check by distribution ---> ARTICLE (condition, "checked by marketing" is not set, set "checked by distribution)
ARTICLE ---- Check by marketing ---> Ready for publishing (condition, "checked by distribution" is set)
ARTICLE ---- Check by distribution ---> Ready for publishing (condition, "checked by marketing" is set)
For those last two, you may still want to set the relevant checks, even though they are no longer necessary, or else unset the checked flags as a 'clean up'.
The "Fast Track" method would be:
ARTICLE ---- Check by marketing ---> ARTICLE (set "checked by marketing" in post-function, fast track transition to "Ready for Publishing" if both are now set.)
ARTICLE ---- Check by distribution ---> ARTICLE (set "checked by distribution" in post-function, fast track transition to "Ready for Publishing" if both are now set.)
The "Fast Track" post function has been known to cause issues, however, in that performing a transition within a transition seems to be buggy. Though the fast track method is easier to model in the workflow, I recommend using conditional transitions instead. They can be highly flexible; for example, I have different "Close" transitions, one per issue type (conditional on the IssueType field so only one appears at a time) which allows me to focus any validators and restrict the resolutions available using workflow properties.
Actually, there's a minor issue with conditional transitions; to make them appear as the same transition, you have to use workflow properties to change the label, because they can't have the same "name" if they are on the same source. Or, actually, maybe it's same source/destination; my conditional transitions are all X->Closed, etc, so they match perfectly, and I used the transition properties "jira.i18n.submit" and "jira.i18n.title" to make them all show as "Close Issue" (even though I have "Close Bug", "Close Improvement", etc).
The point is, "Close Issue" has a built-in key for i18n conversion, so I just copied the existing value from "Close Issue". Your "Check by marketing" transition would likely need to be added somewhere to take advantage of that methodology. The workaround would be to make them slightly different... say, "Check by marketing", "Check by distribution", "Check by Marketing", "Check by Distribution" (I don't know that they are case sensitive when checking for duplication, but you get the idea. Even an extra space would be sufficient).
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs