Multiple workflows for different content types

Do you mean moderation states?

If so, please move this to the Workbench Moderation queue.

+1.

I am upgrading from Drupal 6, where I used the Workflow module to keep track of workflow states that depended on the content type. My project, for instance, involves one type of content that must be approved by an administrator, and another that has its own workflow states but doesn't require administrator approval. Being able to set up separate workflows for separate content types would be extremely useful.

Aside from that, though, I like the look of this module and think, once needed features exist, it'll be a cleaner/prettier way to let users sift through and moderate their content.

+1.

We have also had a need for different content types to have different workflows. Some node types such as "events" for a calendar would have very little need to go through the extensive level of editorial approval of other node types such as "page".

I just marked another issue as a duplicate of this one.

#1092384: States and permissions per content type

subscribe

+1

+1

Subscribing.

Agree that this would really make sense. There should be another abstraction layer on top of states. Maybe "State type", that could be adressed to different content types or perhaps even to individual content items.

This would be great, we have some content types that only need to be approved by department heads and others that need to go through marketing.

+1

Tagging and relating to a higher level architecture issue: #1316314: Workflow Architecture for Workbench Moderation

In http://drupal.org/node/1092384 , Maintainer becw stated that there's a hidden variable to enable states and permissions per content type. Couldn't find it yet in the code, any hint on where to flip the switch to have this available?

In the workbench_moderation module, around the line 357, you have the explanation:

    // Per-node type permissions are very complex, and should only be used if
    // absolutely needed. For right now, this is hardcoded to OFF. To enable it,
    // Add this line to settings.php and then reset permissions.
    //   $conf['workbench_moderation_per_node_type'] = TRUE;

So, what you have to do is to put this line in your settings.php file:

$conf['workbench_moderation_per_node_type'] = TRUE;

and you'll get a lot of new permissions...

I also need this feature.

This is a big deal on my current project. @stevector I'm aware that you're working on the 2.x branch but would there be any approach you would preferred for how states for multiple content type work on the 1.x branch

I'm thinking.
My thinking is that a user needs to select a state group for a content type when they enabled moderation. Then once they select that state group they can select the default state. Uhm, I haven't thought about the rest of it yet.

vasi in #17 points out how per-content type permissions work in 1.x. Eric, is that what you need?

No per content type permissions I'm aware of.

I need entire different workflows per content types. This honestly can be pulled off with some alters but I think it would be nice to have this in the workbench_moderation module.

If I where to try to accomplish this without patching the module I'll need at least two more hooks. There's already issues for those other hooks.

Either way I rather do this right in workbench_moderation.

Is the 1.x version still receiving features? Because the 2.x version is something completely different.

Has there been any progress on this issue? I couldn't find updates elsewhere and this thread seems to have faded away...

Just to clear up any confusion, the 'workbench_moderation_per_node_type' setting seems to be available in the 1.x branch too. I've just tested it out, and basically, for every content type that has had 'enable moderation of revisions' set, all workbench_moderation state transitions will become available as separate permissions.

If you have a lot of transitions, content types and roles though, this could get quite difficult to maintain.

Does anyone know the status of the 2.x branch, since the dev release has been removed from the project page?

Hi,

+1 for this feature. "workbench_moderation_per_node_type" doesn't help much as it defines permissions per content type but not states and transitions per content type.

This is an important requirement for what I am currently work so I'll have to write some code for it. I'll post my findings here if they might be useful to others.

Subscribing

Updated issue summary.

I also need this feature.

Agreed, being able to have different workflows for different node types is important. For example blog posts, product pages and legal pages usually have different requirements.

However, there is also a need to have more than one workflow for the same node type. For example one for the creation of the original node and then one for translation into different languages.

Preferable it should be possible to make them work together. For example that the node can't be set to published until it is available in a number of specified languages. This is quite a common need for multilingual sites actually.

Actually this should already be possible on the latest 2.x-dev branch. *I Think* but I'm pretty sure it is.

@ericduran

When I player around with it yesterday I couldn't find any settings for specifying content type etc. What happened was when I set the context relationship to "Node edit form from node" for the workflow was that it appeared on both content types in the Standard profile. I wasn't able to find any settings for specifying what content types should have workflow or what workflow they should have.

If you know a way to do that I would be very grateful if you can provide some details about it.

We rewrote workbench_moderation to add support for entity translation, the first thing we did was writing a custom field to hold the state, so it can be attached to different node types and so it can be easily translated.

Using a field has to benefit of easy integration with views, rules, entity translation, ... and also allows us to have a published version in one language will the other languages are still in draft.

We started working on the 1.x branch, but hopefully I might upload a patch in a couple of weeks.

@attiks

If I understand it correct, entity translations will be working for the 1.x branch too then?

That would be great as it would not force us to use 2.x until it is ready and stable.

#31 You understand it correctly

Okay, I've spent too much time beating myself up over this, and I need some help. Our workflow currently consists of three states -- Draft, Needs Review, and Published.

We have two particular content (node) types on our site that, due to author request and the urgent nature of the particular types of information, need to have any author allowed to publish content of those specific types. I've enabled workbench_moderation_per_node_type as detailed above, and enabled authors to moderate those specific node types from Needs Review to Published (in addition to their default of having rights to move any node type from Draft to Needs Review).

Unfortunately, testing this with a user who needs it reveals that she can create an item of the given node types, can move it to Needs Review (as she could before), but still doesn't have a choice of Published on the Moderate tab. When I operate as this user using the Devel module's user switching, I get Published as an option, so this is particularly strange.

I've rebuilt content permissions multiple times, with no effect. I'm not entirely sure where to even begin to diagnose this problem. Any and all assistance or guidance would be appreciated.

So, I did a little more investigation, and I found out that it "sort of" works. Here's more details:

• We have three transitions defined: Draft --> Needs Review, Needs Review --> Published, and Needs Review --> Draft
• If a user that I believe I've given publishing capability to creates a new node of the particular type, and sets the initial state to Draft when saving it, they can transition it to Needs Review, but no further. They also cannot transition it back to Draft.
• If a user that I believe I've given publishing capability to creates a new node of the particular type, and sets the initial state to Needs Review when saving it, they can transition it in either direction, to Draft or Published.

I don't know if this helps in the diagnosis, but it's a workaround, of sorts, for now. Still looking for any insight into why this might be the case. Wondering -- do I need to have a transition of Draft --> Published, even if no one will ever use that specific flow, since that defines the "endpoints" of the flow? I'm headed for the end of my workday, so experimentation will wait until tomorrow.

Updated issue summary.

I'd like to refer you to my sandbox: https://drupal.org/sandbox/srjosh/2172925 for a module I call Workbench Moderation Profile, which allows you to define "profiles" of transitions, for different workflows. It also includes a sub-module that allows you to assign by content type, and another that does by organic group.

Compatible with Workbench Moderation 1.x

Try the new and shiny Workflow 7.x-2.x module. A workflow is now just an ordinary Field. (Shameless plug)

I like to be able to moderate blogs as well. However there is only option in the permission list. Does anyone know to add other content type?

Hello johnv,
I downloaded to test new workflow filed module provided as part of Workflow 7.x-2.x module and looks like way to go. Thanks for your brilliant module. Workflow field provides the similar functionality as workflow node, that ties a specific workflow to a content type(one to one).

Is there a way to make configurations for below use case.
For a single content type, content is provided by multiple departments, and each department would like to have their own workflow for the their provided content(nodes). How can this be achieved.

Any ideas are greatly appreciated.

@preddy, let's not high-jack this issue. CU @ #2229103: How to have parallel workflows on a node? :-)