I just wanted to share some thoughts about possible implementations for workflow on d7.
Worklow states = a field
Basically I think workflow should work field-based, e.g. providing a workflow field, which can be attached to any entity. Thus the state transition settings would belong into the field settings, whereis the triggering part can be separated out and handled either by rules or trigger module.
For that the workflow module could introduce a simple "workflow state" field type, or just build upon the list of text fields and provide an option for those fields to enable state-transition-permissions? That could be easily integrated with a custom $field['settings']['allowed_values_function'], thus the major part would be still the UI...
Workflow states = Groups?
From looking at alfresco, the idea of using groups as workflow states came to my mind. Thus for each state one creates a group, e.g. "Editorial space", "Moderation", "Publicated",. When content is assigned to the group, it means the state is assigned. Therefore one can easily add members to a group, which should be able to control/edit content in this state and the group page can serve as starting point for the "editors" or "reviewers". With groups permission system, one could even easily implement state based permissions?
Then in alfresco one has to possible actions per group "Approve" and optionally "Reject". The actually applied state transition is invoked by rules, whereas this design even allows for content to be in multiple states at the same time.
Comments
Yes
Workflow states in a field? I completely agree. See my minipresentation from the 2010 dev summit. Workflow states as groups might work as secondary states, since with workflow-as-a-field you could assign as many workflows as you wanted to a content type.
Sounds good! I agree that the
Sounds good! I agree that the groups are a perfectly valid addition to an usual field. Thanks for sharing the slides, I've not seen those yet.
The UI part is probably the most tricky part, in particular in regard to permissions for state transitions. I'm not so sure about the buttons as for more complex workflows one would quickly get quite some buttons. But anyway, having it as field would make it easy to support different widgets... :)
A question and a sketch
I've been puzzling on some ways to have Rules do workflow-like tasks. Taken one step further you would get a solution that only depends on a "workflow state field" and some rules that follow well defined, eh, rules.
Before going into details I'd like to hear some clarifications about the "workflow states = groups" thingy. Why not use Drupal's regular access control (combined with granularity provided by Content Access)?
I presume that this has been considered (especially if you look at the module maintainer), but I'm curious to know more about the reasoning.
Here's a sketch for how to make Workflow field/widget + Rules + Content Access create flexible workflows.
The Content Access stuff
The node type with the workflow widget must have access set on a per-node level.
The workflow field/widget
The Rules stuff
These rules should be automatically created/updated when the workflow field is saved.
Some comments
What's good about this model? I think one main benefit is the high granularity. This means you have low risk of duplicating functions better available in other modules, you'll have an easier time integrating with other modules, and you'll get higher flexibility.
What's bad about it? Well, it is highly (but not completely) aimed at nodes. While this is a drawback, I have a hard time finding workflow needs for other entities than nodes. It would also take some efforts to conjure this magical workflow field.
Those are my five cents of thoughts!
Cheers,
//Johan Falk, NodeOne, Sweden
yep, that makes much sense.
yep, that makes much sense. Groups would be just fine as it could help managing different groups of people that have to care about content being in a special state. That way you can "route" the content through the hands of multiple groups of people being editors, reviewer, decision makers, whatever to approve the work and then move on.
Of course content access is nice for adjust access permission, but it doesn't manage the additional relation of associated people for you. Also in regard to access permissions usually you want to restrict access for certain state transitions to a certain group of people - that's not possible with content access though as it's just working on the node level.
@rule-set:
Why this rule-set? We could provide an extra event for the state transition of each workflow field instance.
Groups as in "Organic groups"?
I'm still a bit confused over the "groups" associated with the workflow.
@rule set:
It might seem an overkill to let Rules take care of things like changing access to nodes, but I think there are some points to it:
* If any actions are placed in rule sets called on state transitions, they can be customized within the Rules framework. (But I realize that these customizations otherwise could be done within the Workflow framework.)
* There will be a more natural way of extending actions to take on state transitions. (But I realize that these events can be extended within Rules anyway, as long as the event is exposed in a proper way.)
* If collecting actions in Rules, Workflow can focus on managing the transitions and who is entitled to do what transition. I think this is a clean way of managing functionality and lower the risk of feature duplication. (And this is probably my strongest point.)
I take back my previous suggestion that there should be a rule set for each workflow state – the natural unit is (as suggested) the transitions.
I hope to be back shortly with some clarifications,
//Johan Falk, NodeOne, Sweden
Proof of concept captured in a screencast!
I just did a proof of concept for workflow based on CCK, Rules and Content Access:
http://vimeo.com/12921305
My main argument for using Rules in the workflow is now that it makes sense to use an existing framework for customizing actions. While building the PoC i realized how easy and flexible it is to use Rules for just about anything you want to happen in the workflow transitions.
I captured most of the configuration in a feature downloadable at NodeOne's site, if anyone is interested.
Cheers,
//Johan Falk, NodeOne, Sweden
workflow states as a field FTW!
Maybe a workflow field that uses taxonomy, simular to content_taxonomy would be an option too? This way the access stuff could be easily handled with http://drupal.org/project/tac_lite. But probably a built in access solution simular to content_access would be better (one UI).
Another important feature would be the synchronisation with core node states (published...). I know this could be done with a rule, but maybe these rules should be prepackaged or built in in the UI. But there is the well known access problem for non-authors without administer nodes permissions. See http://drupal.org/project/module_grants.
BTW, taxonomy for workflow states, rules for actions, synchronisation and stuff, tac_lite for content access and module_grants for the core access quirks are doing a good job. Simple workflow transition access could be also done with rules forms or form_alter. But what's missing here is definitely a nice UI.
Well, you can build lots of
Well, you can build lots of stuff - what is missing is robust, but simple to use out-of-the box experience that fulfills the mostly needed requirements.
Workflow Template vs Workflow Instance
Maybe a slightly different Angle, bases no my experience with various workflow environments...
(I've tried to indicate a lot of detail)
We need the following entities...
1. WorkflowTemplate = Flow-Pachage, which defines the following
2. Process Template:
2.1 ProcessTemplate = Define a re-usable sequence of steps
2.2 Step = Executable action with inputs, action, outputs, config for internal use
Notes: In visual dersigners, these are the building blocks. Probably some other data neded also.
3. Workflow Instance = A unique instance of a Workflow-Template
Notes: Also need tracking info to detect execution depth, infinite loop, stalling.
4. Process-Instance
4.1 Process-Instance = An innstance of the process which is running; state maintained
4.2 Step-Instance = Executing step of a process; state not maintained
Notes: In visual dersigners, these are the building blocks
Notes:
As can be seen, different Content Types are needed, each with a set of fields.
The above model offers the following benefits:
Hope this provides a useful starting point.
Emile
http://Servelime.com
Emile Botha
Entrepreneurship is a journey to a fulfilled life - make it so.
Maestro Project update
Lots of good ideas being presented here and are some of these gaps are what we hope to address with our Maestro module for Drupal 7. Maestro brings a new approach with a visual workflow editor and flexible task types that are executed by a background workflow orchestrator or engine that processes the combination of interactive and batch tasks in a workflow. Workflows can be single path like publish article or have conditional branches using business logic that may have multiple paths executing tasks at the same time by multiple users to later be joined up.
We posted our proposal and ideas to the Contributed Modules Group a couple months ago and have made considerable progress on the module and should shortly have a alpha or beta available for review.
Using the example workflow that @fago described, I've put together a video that shows the current dev version of maestro executing the workflow for a 'publish article' involving three roles (submitter or initiator, editor and publisher) where the editor or publisher can reject the article and have the workflow backup. Once the publisher approves it, then the article is published.
Video Link
To implement this workflow, we did not need to create any new fields, triggers or actions - it's all managed by maestro.
Maestro will have a number of other components for reporting and workflow administration like monitoring outstanding tasks, re-assigning tasks, viewing workflow instance task history and exporting/importing workflow templates.
The maestro design will easily allow for custom new task types and is very extensible like CCK was in D6 so developers will be able to add new taskTypes. Existing taskTypes allow for site developers to easily add custom code either as an interactive task or batch task run automatically by the maestro engine.
Great! But still lacking one aspect?
Saw the video and must congratulate authors on a substantial piece of work. Look forward to the finished product!
The admin UI for workflow creation, while slick, at first feels a bit like a cockpit, somewhat intimidating, just as most other solutions out there in and outside of Drupalland. I guess if you require a workflow with lots of "red tape", branching and notification implemented , then you can't avoid a certain level of complexity.
The much simpler task-based UI for the participants (author, editor, publisher) in the workflow is much simpler -- very clean and intuitive. Really like it.
As with demos and tutorials on publication workflows, the excellent Maestro video and the also innovative solution by Itangolo earlier in this thread, come to a happy ending when the initial draft has been moderated and published.
To me this is only half of the story. In many real-world situations, content will be revised not only before publication, but also after publication. So, we need to allow authors and editors to work on subsequent drafts while the current revision remains visible to the public.
Will Maestro cover this business case?
For various tutorials and variations on this topic, using the Revisioning, Workflow, Rules and TAC-Lite modules, see the Revisioning project page, which has links to further documentation.
Rik
Just more options
Maestro does not remove or prevent you from using all the existing modules and features in Drupal to continue to manage the site content and state. In that demo, the final task was to move the article to published but there is nothing preventing someone with content edit writes and access to the publish state to change it during or after.
I found it surprising that you found adding a few visual task blocks, connecting the tasks and setting the task owners was more intimidating then walking through all the drupal content screens adding a CCK field, setting up new actions and triggers less intimidating. Still, this was a very quick overview and was not meant to be a how to tutorial. Maestro is also setup to be something that can create simple 3 step workflows or complex workflows involving 50+ tasks with different routing options, data access from external systems, and multiple content types. Examples: Online order processing or new hire process that may need to launch new workflows for procurement, network setup, application and security setup etc.
content moderation
@blainelang: I think you're misunderstanding RdeBoer's question. It's not about being able to change the state of a node after its been published. That's easy. It's about being able to to keep the published revision of a node published, while newer revisions of that same node go through a publication workflow. Drupal does not do this very well at the moment.
For instance, lets say I have four states in my workflow: Draft, Review, Approval Pending and Published. First I create a new draft node for the "About Us" page of my site (nid=6; vid=13; state=Draft). This node goes through all four states of my workflow—eventually getting published (nid=6; vid=27; state=Published)—and I launch my website for the world to see. Now lets say I need to make some changes to this page. I obviously can't take down the "About Us" page for any length of time, but I also can't publish my changes immediately. I need the changes to go through the same approval process that the original node went through. So when I edit that node, I need my workflow system to create a new revision in the draft state (nid=6; vid=28; state=Draft), while still keeping my previous revision in the Published state (nid=6; vid=27; state=Published). Eventually my changes will also make it through the workflow and a new revision will be approved for publication (nid=6; vid=32; state=Published), replacing the previously published revision as seen by the public.
Can Maestro do this? Does it recognize and work with revisions? The current Workflow module does not and that has been the source of some frustration.
Revisions are maintained if enabled
@jstoller: thanks for that clarification.
Maestro is utilizing the native Drupal Edit Content link when your clicking on the link in the interactive task. It was not showing the 'revisions' tab in the edit overlay and I'll look into why but if Revisions are enabled for that content type then the 'version comment' box will appear when editing and revisions are maintained. A new revision will be created every time a user in the workflow edits and saves the article. If the editor did not complete the task and decided to edit/save it more then once then multiple revisions are created. That I believe is the same as if a user with edit rights did multiple edit/saves without using Maestro.
Maestro is NOT restricting any of Drupal's functionality - atleast not by design or intent.
Update: If I execute the task 'edit/review article' as an admin, I see the Revisions tab in the Edit Overlay so it appears to be permissions related.
@blainelang: I think you're
@blainelang: I think you're still missing my point. It's not a question of Maestro letting you save new revisions. I assume that it does. My questions are:
1) Does Maestro associate workflow states with nodes (as the current workflow module does) or with node revisions? Can I have one revision in the "published" state and another revision of the same node in the "draft" state?
2) By default, Drupal assumes that the most recent revision of a node is the published revision. This makes it impossible to moderate previously published content. Can Maestro work around this limitation and allow an older revision to remain published while a newer revision of the same node moves through the workflow?
While Maestro's workflow designer looks very cool, if it doesn't allow me to attach states to revisions instead of nodes, it will be useless for 90% of what I need a workflow for. I must be able to run every change to a node through the same workflow before it is published, without ever un-publishing that node.
Look at this Drupal issue for some discussion of the problem.
Infrastructure needs to be built
Jeremy is exactly right.
The required infrastructure is missing from core (despite numerous efforts by Jeremy to get it into D7).
It's also missing from the Workflow module, as noticed by others, e.g. here: http://drupal.org/node/843568.
So the module (or another module) will have to supply it to support the business cases we're talking about.
Great writeup by lelizondob
That's a great writeup by lelizondob on the workflow with revisioning and I'd have to spend more time investigating the use-case and duplicating the recipe that he has nicely detailed. It depends on a number of modules like the revisions module that I've not worked with yet.
My initial thoughts are that Maestro should be able to help here but may not necessarily replace all of this initially. Maestro has a batchtask type that is user-defined function so a site developer would add any combination of PHP code they want so that part of the recipe that lelizondob documented can be accomplished. We are also talking about having the ability to just add inline PHP code as part of the Edit Task options for a BatchTask so that you don't have to edit/add a php file.
A workflow needs to have an End Point and we really don't want to have workflows running for all articles waiting for the state to change from published to revise but we do have a Trigger TaskType - still I don't think we want to have 100's of these workflows running in a state like that. A Maestro workflow can be triggered to start as an Action and that can leverage the existing ideas presented in this write-up.
Once we get Maestro released, we hope to get more input and testing by the community and we are very open to suggestions to improve it.
@blainelang, the video is
@blainelang, the video is awesome! This module is great!! A lot of workflow systems, like Bonita and other BPM systems, will be killed by such module available in the Drupal world.
You have a lot of tools trying to "be the one" with workflow, like Bonita, Alfresco, etc, but Drupal having this natively, together with custom Content Types, you can create great webapps in many contexts.
The video remember me a lot the workflow designer from Bonita. If you want to know a bit more about, yout can look at http://www.bonitasoft.com/products/Business_Process_Management_features.php
Congratulations!
Yep - thats the target market
Thanks for the feedback and that's our target market and want to help Drupal establish itself as a real competitor. I had not heard of Bonita but have to agree, from the limited information I could find on their site, there is a lot of similarity. Maestro is a re-engineered and total re-write of an application that we developed several years ago as part of another open source initiative.
You should also check out our other module called filedepot that we released a few months ago - a native document management solution. Our plan will be to enable workflow and DM like alfresco does but for the mere mortals.
Drupal <> Bonita Integration
Why not joining forces and have the best of both worlds, Drupal as one of the best CMS and Bonita the same in the BPM area.
Such approach will allow to have Bonita as a central piece of BPM orchestration for all the enterprise applications using a bpm engine.
Rules + Workflow widget: quick demo
Using some spare time during Christmas holidays, I did a mashup demonstrating how a CCK widget can tie in with Rules to allow flexible workflows. It is captured in two quick (really!) screencasts, which can be viewed at http://nodeone.se/blogg/workflow-field-proof-of-concept. Source code can be downloaded along with the screencasts, or checked out at Github: https://github.com/Itangalo/workflowfield
Please comment/discuss here rather than at nodeone.se.
Happy new year!
//Johan Falk, NodeOne, Sweden
Simple field-based rules-driven workflow module (D7)
Hej johan,
as I will need exactly this functionality in an upcoming project, I went ahead and tried to implement it by using (and learning) the new fieldapi in D7 :)
I think, I've gotten pretty close to what you outlined / showed in your screencast (named transitions, buttons in node edit forms etc.) by mashing up your workflowfield.module with the examples.module's field_example.module. It's very basic with rules - as it should - doing all the heavy lifting; code is currently on github: https://github.com/frega/wf_field - would love to get some feedback ...
Best, Fredrik
Screencast and install profile
Hi,
I posted a short screencast about a simple, field-based and rules-driven workflow module for D7 we've been working on (wf_field, s. above) here: http://goo.gl/nQOPr
The code is still experimental & on github but there's also a complete installation profile available, if you want to take a "preconfigured" example setup for a spin ...
Best, Fredrik
Really good stuff
@frega: This is really good stuff – it feels like I've wasted time not knowing about this module.
Really great work!
What do you think about the idea to ship it with 1–3 features, with pre-configured rules? That would make it easy to get going with the module, and to get examples on how to use it with access control modules.
Good stuff!
//Johan Falk, NodeOne, Sweden
feature with examples
hej johan,
happy you liked the module :)
i'd be glad to roll a few features focussing on some aspects of this - if you'd have a concrete "use case", all the better :) which particular control access module did you have in mind? last time i checked content_access' rules integration wasn't entirely there yet, i think (cf. http://drupal.org/node/690610 and http://drupal.org/node/1058526). But i'd be happy to give it a go!
best, fredrik
ps. was there any outcome on the BoF re: handling workflow states/assigments (e.g. w/ organic groups)?
Hej igen!
You're right – the Content Access module doesn't seem to have Rules integration yet. (I didn't notice when making a quick check on the module…) This means that it will be difficult to use it for an example use case of wf_field.
When there is Rules integration, though, the following use case would probably be a good start:
Setup
* A content type: Workflow article
* Two roles: writer and editor
* Three workflow states: private draft, in review and published
* Three workflow transitions: send to review (private draft -> in review), publish (in review -> published) and decline publishing (in review -> private draft)
* The send to review can only be used by writers. The other two can only be used by editors.
Default state
* The default state for new workflow articles are: (a) workflow state private draft, (b) not published, and (c) access to view and edit only for content owner.
Transition actions
* The send to review transition triggers a rule, adding permissions for editors to view and edit the content. Also, a message is displayed to the acting user saying that the content is placed in the approval queue.
* The publish transition triggers a rule removing permissions to edit own content. Also, an e-mail is sent to the node author.
* The decline publishing transition triggers a rule removing permissions for editors to view and edit any content. Also, an e-mail is sent to the node author.
If this is implemented as a feature, then we could/should also include a view where editors can see content in review.
I don't know enough about Organic groups for D7 yet to give an example of how it could be used in workflows – if anyone has an idea: please share!
What other access modules are there available for D7 that could be of interest?
//Johan Falk, NodeOne, Sweden
Want to learn more Rules? Check out my latest screen cast series!
PS! An example that really should be included is a simple workflow state just making use of the core published checkbox. Two states (published/unpublished), and two roles (writer/editor).
Oh, and the BoF!
I totally forgot your question about the BoF at DrupalCon.
The outcome of the BoF was basically this:
Worth noticing is that jvandyk, the original author of Workflow (and also Pro Drupal Development) was at the BoF – which was really good to get a better understanding of the Workflow module and difficulties with Workflow in general.
Another, unrelated, outcome of the BoF was that we started a (currently) four person strong team to help take care of support issues for Rules. I have yet to get this started, but hope to do so soon.
//Johan Falk
module zoo
Poject http://drupal.org/project/maestro now have a release for D7, no progress in http://drupal.org/node/723310 and http://drupal.org/node/732578
There's some work on drivenAPI project so it could be good to have this modules compatible
Workbench
I mentioned in my BoF notes that we should engage the Workbench folks.
I took a look at the short screencast, but haven't watched the video for the DrupalCon session yet.
Pretty slick module
The Workbench suite seems pretty slick, but from what I've seen so far it risks doing too much of its own – without integrating with other modules.
I think wf_field is a great example of how you can leverage functionality in existing frameworks (such as Fields API and Rules), and I think this is really the way to go. BUT! I also think that it makes sense to talk to Workbench people and hopefully integrate with the Workbench workflow – maybe we can have another example feature in wf_field that applies to the Workbench module.
//Johan Falk
Workflows vs. state changes
Hi,
interesting thread and I liked Johan's proof of concept. State changes are important to workflows, but are they really the same thing? When I book a flight online I follow a workflow (pick destination, pick flight, choose payment method, etc.) to make a reservation. The workflow is encapsulated in the wizard. The state changes are only transitory as the booking operation is really just one state change from 'not booked' to 'booked'.
Now compare that to a classic workflow à la Drupal: drafted, needs review, published, rejected. The time between state changes can be much longer with more people involved. (In fact the booking example above could be called a "real-time workflow".) Therefore the state must be preserved between sessions. However, when one revisits the session how does one know what direction the workflow is going in? In a complex workflow, are all transitions intuitive? Can there be more than one way to get an article published (e.g. a 'fast track' state)?
I guess what I am really getting at is that some form of progress indicator is needed. Maybe Content Complete can do this. Also, some indication of how many state changes have occurred, perhaps using Message.
But also important could be that one should be able to choose which path through a workflow one wishes to follow to get to a final state. Our perhaps this requires two separate workflows that the user chooses with help from Conditional field.
These may be just aesthetics best left to other modules or could they something that a real workflow framework should include?
Cheers,
Kevin
Workflow with Relation
I've been toying with the idea of creating a system in Drupal 7 using Workflow entities and the Relation module, and I thought it might interest people here. See this post for the discussion.
Calculate time between each state.
Is there a way that I might be able to create a calculated field for the time between each state change? I have looked at workflow extensions, but do not see a token that would indicate time between state changes and my knowledge of php and drupal module hacking is limited...
Workflow Field module
Fyi, the Workflow Field sandbox from @frega is here:
http://drupal.org/sandbox/frega/1109038
Contact: https://www.hook42.com/contact
Drupal 7 Multilingual Sites: http://www.kristen.org/book