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

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 Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,076 views 13 18
Join discussion

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot