Editing a live node

One possibility is to do the following:

* setup a tranistion from Draft --> Published (go to admin/config/workbench/moderation/transitions)
* assign the permission Moderate all content from Draft to Published to the appropriate user role (go to admin/people/permissions%23module-workbench_moderation)
* assign that user role to people who have the privilege may edit a live node

This is the safest way to control who may edit a live node.

If you want to live on the edge you, another approach would be to assign the Bypass moderation restrictions to a special user role. It will allow a user to move a node from any state to any other state without following the transitions defined.

In either case, when editing the node, the user can then set the State to Published. A new revision is created and it is immediately published.

Hi,

Our problem is very similar. We have a site with journalists writing articles, and there is a workflow for having an initial idea, which other people approve etc. This works just fine with this module.

However, the problem is, that once the article is published, we want to give the journalists full edit rights to that, without any workflow anymore. We definitely wouldn't want to make them go through the approval process, just because of correcting some minor mistakes, correcting typos or maybe adding a new related video.

Is there any possibility for this kind of behavior? The options provided above disregard the need for the workflow when creating new articles.

Same use case as #2. I'm using the workbench moderation for the initial creation of content. Once it's published the persons with the correct role should just be able to edit it without editorial workflow.

Currently only workbench_moderation_node_type_moderated() is used to see if something is under moderation or not. If we could have more specific function (eg. one that acts on nodes) and that is alterable that would solve my problem.

There is a patch in the works that would allow this sort of change in moderation workflow using a hook: #1108502: Allow modules to alter the list of possible next states

I took the time to open up a new issue over here: #1599012: Editing published content, but now I'm pretty sure that my issue was simply a duplicate of this one. What I want is the ability to bypass moderation on edits once a node is already marked as published. If I'm understanding everyone else in this issue queue correctly, that seems to be what others want also. It would be sufficient for my purposes if published content would simply default to a "Published" moderation state when a user edits an already published node. The current behavior is for all published content to default to a "Draft" moderation state when a user tries to edit it.

It was suggested in comment #5 that a new api hook would allow for the functionality requested in this issue. After taking a look at api function in question, hook_workbench_moderation_states_next_alter(), I'm convinced that it won't really do the trick (unless I'm missing something, of course). That hook simply gives other modules the ability to alter the states available to the user when editing a node. The example in the API function itself demonstrates how to restrict someone from publishing content that they have authored (forcing the content to be peer-reviewed). That's a nice feature, but it's not what we need.

One way to do it might be to create a setting within the workbench_moderation module that is unique to the "Published" state. Currently, when configuring a content type you must select the default moderation state for new nodes. Why not add a similar setting on that same page called "Default moderation state for published content".

What do you think?

I would suggest to introduce a hook in workbench_moderation_node_type_moderated() that allows to alter the conditions whether a nodetype is under moderation. So you could check if your node has been published before and if so disable moderation for this node.

This would also have the benefit that you could make moderation dependent on other conditions like for example a flag that only an admin could set.

I will give this a shot if I get enough time for it.