Hard coded 'Draft' status in .module

This seems to make sense. Can you update the patch to work with the latest dev branch? I'm getting an error when trying to apply it there. Also I don't think this patch needs to touch the .info file.

The patch I'm working on in #1160478: Machine names for states overlaps with this; I think both are important, though this issue is perhaps more immediate.

I found this coming from #1185678: cannot transition from 'published' to another state and went ahead and updated this patch.

however, I disagree with the philosophy of always reverting back to the original state:

@@ -755,7 +755,7 @@ function workbench_moderation_form_alter(&$form, $form_state, $form_id) {
   // We have a use case where a live node is being edited. This will always
   // revert back to the original node status.

As mentioned in the other issue, there's a need for an 'obsolete' type of unpublished state that may make sense to put here. Maybe making the default unpublished state an option might fulfill this need?

I understand the need to unpublish to a state other than Draft. I think that should follow the machine name patch. #1160478: Machine names for states

Cbiggins, please test that one if you have time.

@cbiggins, @stevector: there is a discussion and patch for unpublishing to states other than draft here: #1185678: cannot transition from 'published' to another state

The hard-coded draft state in workbench_moderation_state_none() is still a problem, though. This function should probably not ever be used directly--when looking for a default moderation state, workbench_moderation should first check for the default variable:

variable_get('workbench_moderation_default_state_' . $node->type, workbench_moderation_state_none())

... and then use workbench_moderation_state_none() to find the universal default. Luckily, I think this is mainly how it is used. Since 'draft' is deletable, maybe it should return the first moderation state according to the moderation state weights.

subscribing

this is a bug really.. considering that you can freely remove the "draft" state from the selection.. and then you run into all sorts of troubles. If anything, it should be at the very least impossible to delete the draft state, then it could be called a task I suppose :x

Any news on this?
6 months with no progress on this issue is very concerning :S

Just to add to Shnapoo's comment - you also need to edit

admin/structure/views/view/workbench_moderation/edit/needs_review_page

to get the Needs Review tab to show the content. And in point of fact, unless I'm misunderstanding the use case, you can get much the same effect just by showing both Drafts and Needs Review in the view.

I just gave in and made the view change ergophobe describes in #13.

Is anyone still working on this? Would someone else pitching in be welcome? It would be great if there were some fix for this issue committed before another 31 months passes! :-)

My patch is not a total solution to this issue, but provides developers a way to at least override the hard coded 'draft' and 'published' states by passing it through variable_get.

Would appreciate it if this could be reviewed / committed while a better solution is in the making!

Only changed the patch name of #15 to reflect the project name correctly.

If deleting the draft state breaks the module, why does the module allow the draft state to be deleted? I deleted the draft state and made another to match the name of the default state for a client so that the machine name and the display/organisation names matched to prevent development problems down the line, and it has rendered the whole workbench module non-functional. Thanks for the patches, but shouldn't we fix the actual module so that it can't be broken so easily..?

#16 patch. The variable below doesn't exist. Did it exist 2 years ago when the patch was created? Or are we supposed to create it in the database outside of Drupal? What am I missing?

$state_none = variable_get('workbench_moderation_state_none', 'draft');

Hiding patch #15 and #16 for now.

*

#8 comment. There are several places in the .module file where workbench_moderation_state_none() is called directly. Agree that when looking for a default moderation state, workbench_moderation should first check for the default variable:

variable_get('workbench_moderation_default_state_' . $node->type, workbench_moderation_state_none())

*

#5 patch. This patch is 5 years old, but I do like the approach. The variable is checked in the workbench_moderation_state_none() function and returns either the default state for the node type or 'Draft'. The calls to the function would of course have to be changed though for the default state to be returned. Didn't try this because patch was created using an old release.

workbench_moderation_state_none($node = FALSE, $node_type = FALSE)

Just 5 minutes ago.

1. Downloaded and enabled workbench moderation
2. Don't need draft, so removed it from states
3. Opss nodes being created with blank state?!, db query still shows 'draft' state in nodes...
4. Found this thread :(, last post 21 hours ago, back 2 years, 3 years... no fix :( :(
5. Looking at code TODO still there from 5 years ago!!!
6. Need some fresh air... TODO: burn Drupal server :)

Per Drupal docs, the draft state is required. In that case, the hard-coded Draft status in the code is not a problem?