nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

On the usage of JIRA workflow status and steps

David Toussaint [Communardo]

Hi,

today I got a bit confused on the usage and benefits of JIRA workflow steps compoared to status. While it is clear that I can only use steps in workflows I don't quite get why this is needed and, more important, how can I benefit from this. Even the DOC says it is best to name both elements identical, so where is the use of this?

I had a use case this week where I wanted to assign existing status with different values for the step. This works well, but I only later noticed that the view issue screen shows the global status and not the mapped step. The reason why I used different naming conventions was simply to not have too many statuses in my JIRA and therefore to not confuse users to not know which status should be used in several JQL queries. So in the end I want to keep my existing set of statuses whilst displaying the step name to the user.

So this makes two questions:

1) How can I (as a user/admin) really benefit from status vs. step?
2) How can I achiev the mentioned scenario?

Thanks and regards,

David

Accepted answers

Nic Brough -Adaptavist-

Think of the steps as a skeleton to hang the rest of the workflow on. Also, forget them, from the users point of view, they don't really see them, they see Status. That's a (Translatable) label you can apply to show the user what step they are on.

I know it would seem more intuitive to throw "step" away and just say "choose your list of status, then add transitions", but it's actually quite painful to work that way. Having steps and status separately gives you more flexibility (and hence, complexity, as there always has to be a down-side)

All comments

Nic Brough -Adaptavist-

David Toussaint [Communardo]

Hi Nick, thanks for your answer and sorry for the late reply.

While I agree with the idea to just "throw away" steps at all (but we cannot do that obviously) I now have to keep names of status and steps in sync in order to not create more confusion for our admins. Again this brings me back to my initial two questions:

1) How can I avoid having too many global status but still using compltely different "contexts" for my project (think of dev vs. administrativ vs projekt management vs HR...). They all need their own status (at least partly) and the issue navigator (and taskboar/RapidBoard in Greenhopper) is cramped up with all those different status which no one understands apart from me.

2) Where is the reason for still having steps? (I know this one should be rather directed at atlassian...)

Nic Brough -Adaptavist-

1) You can't. Get your users to shorten their list of status. In the issue navigator, that only lists status that are valid for the currently selected project.

2) Yes, that's for Atlassian. I've worked on other workflow engines though, and the ones that don't have a skeleton are an absolute nightmare to rename, edit, internationalise, and so-on. The editing looks easy, but it really is a pig.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

workflow

status