Issue state

[Higashi]

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

[Higashi · Accepted solution]

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.

[JozsefK]

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

[Nic Brough -Adaptavist-]

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.

[Higashi]

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.

[Nic Brough -Adaptavist-]

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.

[Higashi]

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.