I'm trying to use Workflow-ng to set up the following scenario:
A node can have one of three states:
- Draft
- Needs Review
- Published
There are two types of authenticated users:
- Editor
- Publisher
The Editor role can create nodes and also edit nodes. The Editor can change the state of a node from Draft to Needs Review but cannot set it to Published. The Editor can no longer edit the node once it has been set to the Needs Review state.
The Publisher role can create, edit and set the node state to published. Once the node is set to Published the Editor role can no longer edit the node. The Publisher can also set the node state back to Needs Review or Draft.
As far as I can tell the only way to implement this in Workflow-ng is to create a text field for the node type called 'state' and add the three states as options. I don't understand how to limit access to one or other states depending on roles with this method.
I also can't figure out how to make a Workflow-ng action change the state from one to another, for instance to create a link that sets the node to the Published state.
Does anyone have a solution they can help me out with?
Comments
Workflow does it
The regular workflow module does that, but if you want ng, you might want to follow these threads:
http://code.google.com/p/google-highly-open-participation-drupal/issues/...
http://drupal.org/node/202842
the new states admin
the new states admin interface is already committed and is waiting for testers :) You can use this to create a state machine like "draft, needs review, published" for content and do the state transitions manually by workflow-ng actions, that react on what you desire. E.g. a CCK field.
check out the 2.x branch of workflow-ng.
indeed, you can even combine
indeed, you can even combine workflow and workflow-ng. E.g. with this token patch http://drupal.org/node/157188 for the workflow module you can detect workflow state changes and do "whatever you want".
Fantastic
Great! Thanks guys, I'll investigate the token patch further. I already had my eye on that GHOP task and I'm hoping it will solve my issues. In the meantime I'm experimenting with the original Workflow module. Thanks again for your quick responses.
Exposing Content Links to Views
So far my experiments are going very well. Once patched, the workflow module provides the functionality I need through the use of tokens. My next hurdle is providing an admin interface in the form of a View for publishers to 'promote' or 'demote' a node's workflow state. I was wondering if its possible to somehow expose the Content Links in workflow-ng to the views module? It would be great to be able to define any kind of action in workflow-ng, then create a link to trigger it and finally put that link in a views table. I guess the functionality would be similar to the views action links module.
If this doesn't seem possible, does anyone have a good idea of how to administer nodes using an overview of some sort where users can promote or demote nodes through the workflow without having to go into the node's edit mode?
as far as I can tell,
as far as I can tell, workflow-ng isn't actually about workflows -- it's more of a triggering system.
it's a ruled based system,
it's a ruled based system, that can be used for a lot of things. You can also build workflows with it.
Workflow interaction
Fago, do you have an example or can you explain a good way to use workflow-ng to build a workflow for content editing? I've looked at the documentation and handbook entry which suggests using a cck field as a 'state'. I think this is now outdated with the new states machine admin interface.
My main problem with implementing a good workflow is exposing the necessary controls to the end user. For instance I have an editor role and a publisher role. My editor creates the content and once ready submits it for review to the publisher user. How do I present the necessary control to the editor (in a view or on the edit page) to allow him to submit the content for review (move the state machine on to the next state). I can see that I can use a cclink to do this but there doesn't seem to be a way for it to happen in a tabular view. Because of this I can't create a custom admin interface for users to control workflow states, forcing them to use the edit page on individual nodes.
It'd be great to work on exposing cclinks in the views module or find some other way of displaying and interacting with the workflow-ng states machine. The admin interface is very nice and works as intended, I just think we need some way of interacting with the states in a user friendly method. Any ideas?
Yeah, I read the docs page
Yeah, I read the docs page that suggests using a CCK field to set workflow state. That feels like a pretty kludgy method to me.
For starters, CCK fields are for content, not meta-information.
Second, the regular workflow module provides a nice system to define states. Why not work with this?
No offence fago, but while your modules are hugely powerful, they tend to be too abstract, and for me that removes a lot of their usability :/
I think it would be really cool if workflow, actions, sched_act, and workflow-ng all worked together to provide workflows, user-driven actions, scheduled actions, and a triggering system for actions to run on given conditions. I gather some of the actions stuff is moving into Core for D6 -- let's see what that brings :)
Exactly
I completely endorse joachim point of view. Workflow-ng is a very useful module but why is it called «workflow»?
I can use a fork as a knife but that doesn't make it a knife. Workflow-ng can be used - in a somewhat complicated manner - to build a workflow. But it doesn't seem to be a real workflow module. A workflow is mainly a process that involves time lines, states, roles and actions and, actually ,there is a module for that already: http://drupal.org/project/workflow.
Workflow-ng is very useful to complement the real Workflow module (and many other modules), but it should have, in my opinion, a more appropriate name. The present name, in my opinion, is simply misleading.
Best regards
A roadmap for workflow-ng?
encarte, I think you have a valid point there. I guess I need to understand where fago wants to go with this module before judging on whether the name is misleading or not. For instance, there is now a 'states machine' interface, allowing admins to create states that nodes can move between, similar to the what the workflow module has.
If fago is intending to create or expand on the user interface to better interact with the states machine then I see this module as a replacement for workflow, in which case the name is fine. But for this to happen I would want to see a much better interface for users to trigger the actions required to move a node between machine states.
As I've mentioned before, I think better integration with the views module would help, so that users could trigger state machine changes from a views based table, allowing the site admin to create custom administration interfaces for the users.
So my question is: fago, do you have a roadmap for workflow-ng? Where are you hoping to take this module?
Tanc.
I'm afraid I have to agree
I'm afraid I have to agree with encarte. I'm still fairly new to drupal, but I had a lot of trouble choosing between workflow and workflow-ng. After perusing the modules list for a "workflow" type module (i simply needed to route nodes between states by roles) I easily found both workflow and workflow-ng. I read the docs for both and after having a great deal of trouble trying to determine the diffs and relative strengths and weaknesses between them, I went ahead and installed workflow-ng. Afterall, "next generation" implies to me the future--- why would I want to install the old version of workflow when a "next generation" was available (I assumed the original would eventually be abandoned or merged or deprecated).
After wasting an incredible amount of time trying to figure out how to make workflow-ng do "workflow" as I needed it, I ended up removing it and adding the workflow and actions modules which I had up and running within a day.
To me, it seems a bit like downloading something called "drupal v2" and getting just a LAMP stack (on a much simpler scale of course). Sure you use the LAMP stack to create drupal v2 yourself, but you thought you were getting a pre-created drupal v2.
I don't know if it's because I'm still new, but I find it relatively difficult to try and figure out 1) what modules actually do and 2) what modules do similar things. I was working with joomla for a while (disclaimer: i've actually come to almost detest joomla), which has many deficiencies, but I never had trouble searching for modules. Their categories are fairly fine grained and descriptive, so it's easy to narrow down the modules you need to test very quickly, and the names and descriptions of the modules are pretty accurate. I know nothing about joomla organization and governing, so I have no idea if it's because they review those things prior to allowing modules to be posted or not.
It would be really helpful it these modules were named and described with more details.
i agree
apparently workflow-ng is called Rules in D6 which is fantastic but my god ive been trying to figure this out for a long time and its very confusing. and with no examples, its impossible to figure out.
Fago seems like a supergenius but nothing he says translates down to the newer user.
if someone would just make a screencast or a doc that describes the differences with some use case scenarios, it would save us users probably 100,000 cumulative hours of time. seriously. I would do it myself but I'm still trying to figure it out.
Ryan Scott
CEO, Causecast.org
We are hiring LA based drupal wizards!
Hey, you don't have to choose!
I've built this. I'm in the final phases of cleaning up the code, but people are using it, and it is in production on some of my sites.
I've added workflow-ng configuration as an addon to workflow. Look in the contrib directory of the latest workflow release. Also,
http://drupal.org/project/workflow_owner
is out and needs a little more love, but is really close. This integrates both workflow and worfklow_ng with users so users can "own" states in the process, and get notifications from workflow_ng.
I'll be making a lengthy post about the whole setup on my blog (http://pajamadesign.com) in about a week.
Until then,
Jacob