What does the OS_WFENTRY state=4 and state=3 mean?

I know that "normal" issues have state = 1,

State 0, are issues that had encountered error during transition. Efect is that they lost their workflow buttons (JRA-4685)

State=4 seems to be issue closed/not editable(property Issue Editable set to false), BUT I have some issues that are in this state but workflow indicate that issue isn't completed(property Issue Editable set to true). In this workflow there was event fired "work stopped on issue", and now there's no workflow buttons.

I have no clues on state=3, but now I'm most interested in state=4

3 answers

1 accepted

1 vote
Accepted answer

os_wfentry.state is relic from before year 2003, when jira had only one workflow.

0 means that there was an exception while processing step/creating issue. This could be easily fixed by atlassian integrity checker (though as said in JRA-4685) developers never managed to replicate it.

4 seems to mean that issue has been closed/finished. as in doc 2.1 stands "The issue is considered dead, the resolution is correct."

It's not quite clear to me why there's no workflow buttons, when issue has a state 4, nevertheless that wasn't merits of the case.

There's no clues about state 3, but it's something between nowadays open and closed.

Most cases state should be 1.

0 votes

You're not quite right on state=4 - it's not directly related to the editable property. I did look at this a very very long time ago, but I can't remember what the numbers mean.

What I can remember is that it's not worth worrying about in the real world - run the Integrity checker and it will correct the ones that are wrong.

Integrity checker does find only those with state 0. I can find them quicker and change their state. That's not a problem.

I have a problem in one project. The issues with status suspended lost their workflow buttons. The state 4 is not common, and might point to solution.

Have you checked through your workflow to make sure it's not the conditions on the transitions that are preventing them from being usable? Generally, you don't need to think about os_workflow - I've yet to find any issues where the os_workflow is causing a problem (other than the ones the integrity checker fixes). You might be looking at the wrong thing here.

By the way, remember that if you're writing to a Jira database to fix things, you MUST have Jira down, and you really do need to reindex it after you have finished.

I sure did checked the workflow conditions, validators etc. Everything seemed fine. None of the workflow condition prevented this step. I already fixed my issue: I changed EVENT after transition from 'close issue' to generic event - republished workflow and my problem perished. So I changed it again to 'close issue' but it didn't occurred again.

I think this relates to ISSUESTATUS.ID (I'm on 6.1).

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,690 views 18 21
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you