Default Moderation state of Published creates Drafts instead

I'm having the same problem. Subscribing.

My scenario is that I don't want too much moderation -- just want the option to make drafts of nodes occasionally. But we don't want to go through the whole draft process very often, so I want "published" to be the default state for all edits. Would love to figure this out because having all edits default to "draft" isn't going to be realistically usable for my case.

We have the same problem here. And I have the solution as well.

Workbench Moderation always puts "live" nodes (nodes that are saved and published) back to the Draft state when you start editing them. The problem though, is that it even puts the state back to Draft, even if the node is not saved yet (you are about to create it).

So we have to do the logical checks in a different order. The attached patch should correct this.

Same problem on my site. The patch does not help for me. Maybe two other interesing facts:
First, using the direct link under "My Workbench / Needs Review"

http://REMOVED/node/REMOVED/moderation/REMOVED/change-state/published?de...

works.

Second, as Administrator everything works perfect.

Re-rolled against latest dev.

#4: 1408858-workbench-moderation-default-state.patch queued for re-testing.

Let's try this?

#4: 1408858-workbench-moderation-default-state.patch queued for re-testing.

That worked better.

Sorry, but I can´t get this to work.

As seanmadsen explained in #1 we need all nodes and comments been published by default and only very nasty, illegal etc. nodes or comments should be unpublished from the Moderation Team. So the Team should see new unmoderated content, that is published by default, and unpublish them if needed.
But the patch seems not work at all.
Any idea how to get Workbench Moderation to act the way described?

I had a different take on this. If a live node is being edited (including new nodes) the comments say moderation state will revert back to the original node status. But it doesn't- it sets it to none (draft). This patch instead reverts the moderation state to the content type default (draft, published, whatever), with none (draft) as the fallback.

Not sure if #12 is the way to go but the patch does work.

This is a bug report, and a major one since it breaks a very common use case.

Subscribing.

This is a good solution.

Issue still exists with 7.12

The issue seems to be with line 834 of workbench_moderation.module

// We have a use case where a live node is being edited. This will always
 // revert back to the original node status.
 if ($moderation_state == workbench_moderation_state_published()) {
    $moderation_state = workbench_moderation_state_none();
 }

should change to:

// We have a use case where a live node is being edited. This will always
 // revert back to the original node status.
 if (isset($form['#node']->nid) && $moderation_state == workbench_moderation_state_published()) {
    $moderation_state = workbench_moderation_state_none();
 }

this means that anything with 'default moderation state' set to 'published' will, in the instance of the node being created - be published, but thereafter (when edited) fall into draft.

Think this is how it's meant to work, no?

Olly

Changing state.

None of the patches are suitable for roles that don't have access to move content to the "published" state. If you set the default to published via the method in #4, #12 or #18 the select list simply disappears for the aforementioned users.

I think we need a solution that checks if the user has access to the default state.

Better yet I think for better usability we should get rid of the select list altogether, as seen on #1727602: D8 backport: Move published status checkbox next to "Save".

mstrelan I think both of those issues are unrelated to this one. These three separate issues may need to chase head with their patches depending on which gets committed first, but should remain three separate issues/patches.

I independently discovered this issue and wrote to the same fix as the patch in #12 a few days ago, and then today found this issue while working on some other patches.

@baronmunchowsen: if #12 is broken, please create a patch that fixes the issue properly, or explains correctly what is wrong with it. Your explanation quotes the *old* code and doesn't include the change from the patch, and therefore doesnt make sense.

Also, I agree with #21, so pending a proper rewrite of #18, this is still RTBC on #12. The issues in #20 should stay separate.

Basicly what happens in #18, but afterwards, after other modules have had a chance to edit the possible "next states", we check if the default state is in the available states, if not, set state to none (draft)

Re #18 "this means that anything with 'default moderation state' set to 'published' will, in the instance of the node being created - be published, but thereafter (when edited) fall into draft.

Think this is how it's meant to work, no?"

This seems to be how it was meant to be but I find it very surprising. I totally expected the "Default moderation state" to only apply current nodes being edited. Since workbench_moderation leaves the default publishing options on the node type edit form, I assumed those settings would continue to apply to new nodes.

Our desired work flow is to have an initial default state of "unpublished/draft", once the node is published and edited it should not revert to draft if your 'default moderation state' is set to 'published'. This is not intuitive for users who have permission to publish nodes. They edit the node, click save and wonder why the change didn't get made.

So I'm all for #12 as it feels much more intuitive - to me anyway :)

.

Pinkonomy: please try the patch in #23.

.

@Pinkonomy:
Did you configure the default state on the content type
Does the user have access to publish?

.

.

@pinkonomy: not sure, but it sounds like you *might* be running into exactly what comment #18 points out:

this means that anything with 'default moderation state' set to 'published' will, in the instance of the node being created - be published, but thereafter (when edited) fall into draft.

Think this is how it's meant to work, no?

If this is in-fact what's happening to you, and it is not what you're intending to happen... then maybe try out the patch in #12, and report back please.

In my case I had a different default state for certain content types, but the same issue where it would always set the state to draft instead of my default state. I think #12 resolves this particular issue, but I can see a use-case this could be separated as "default for new content" and a "default when editing existing content".

Confirming that #12 patch resolved the issue for me.

It seems there are different approaches and follow-ups needed for this issue.
I can confirm #12 fixes this issue, and only this issue. It sets the revision to the default state when a node is edited or created;
i rerolled #12 therefore. (offset)

Some approaches in this issue only set to default moderation state when creating a node (not when editing) this could be a valuable approach (or could need another extra setting). I suggest to discuss this in a follow-up issue.

I'm marking #34 as RTBC, it looks good and is just a re-roll of #12 which was already RTBC.

I also agree that there are other use-cases and approaches and those should be follow-up issues, since they would be new features, not part of this bug fix.

Unfortunately, patch #34 does not work under the following scenario (using Workbench Moderation defaults):

• A content type has a default moderation state "Published."
• A user has permission to edit a node. The user does not have "Bypass moderation restrictions" or permission to moderate content to the Published moderation state.
• The user edits a node that has a "Published" moderation state.

Instead of presenting the user with the Moderation State dropdown, the moderation state is inalterably set via the Form API its current state, "Published." This also allows a nonprivileged user to publish content without approval.

The following patch attempts to fix the default moderation settings.

The default moderation state is now only used to select the default form value for the Moderation State select box. Previously, if the current state was not defined, the default moderation state was used. This allowed unprivileged users to create content with "elevated" moderation states. For example, if a content type's default moderation state was "Needs Review" and a user that did not have permission to moderate content from "Draft" to "Needs Review" created content, it would inherently receive the "Needs Review" state. This patch's assumption is that all users with create or edit permissions for a node must start with the "Draft" state and build from there.

The Moderation State select box now sorts the states in the ordered returned by workbench_moderation_states(). Additionally, I have switched the current moderation state's label from "Current: {state}" to "{state} (Current)." I believe this helps identify the current state without confusing the state's term.

Along the lines of #34 and #35, the patch does not address any specific use case, like creating vs. editing a node.

The code looks good, and I like the logic. All I did was fix a comment and add another one to the last stanza.

Thanks for the "git am"-able patch, but it was missing the issue ID in the commit message. I didn't make this one "git am"-able because the credit should go to @jbylsma (not me).

Still needs testing. Please try it and report back.

Thank you for the cleanup and extension! I hadn't realized how poor that one comment was.

I've recently been reviewing Workbench Moderation again for potential use on a new site. For what it's worth, the patch still applies cleanly and works as anticipated.

Committed to dev. Please test that branch, and if there are any problems with this functionality, report them here. I'm trying to get the branch up-to-date quickly to prevent more uncommitted patches that conflict with each other, but also to give us something reasonably stable in dev. If there are no issues after a while, will cut a release.

Adding to the list of things to be ported to 2.x...

Does not apply to the 2.x branch, it uses State Machine / State Flow which does some of the form altering.

hi.. please just to know
has this been solved in 7.x-3.x-dev branch ?

Hi delacosta456 if you can update to 7.x-1.4. It has been solved there. See release note #22 https://www.drupal.org/project/workbench_moderation/releases/7.x-1.4