Hi,

I would like to apply for full project status for the sandbox project wf_field: http://drupal.org/sandbox/frega/1109038

wf_field is a set of modules (D7-only) that leverages rules2- and field-API to provide generic workflow functionality with minimal assumptions about the type of workflow. Starting point for this module was the tutorial "Rules + CCK for Publication Workflow" for D6 (http://drupal.org/node/550716) and a screencast by Johan Falk (http://nodeone.se/blogg/proof-of-concept-workflow-built-on-cck-rules-and...). We (re-)implemented these features with D7's new apis/functionality and have extended on them field formatters, views integration, entity api, transition-log-entry entity, node_access-overrides).

Obviously, the module has some overlap with other workflow-related projects for D7 like maestro (http://drupal.org/project/maestro) or workbench (http://drupal.org/project/workbench); the main differentiator is that wf_field focusses on leveraging the rules and the fields APIs. To some extent wf_field can actually be complementary to these other workflow modules: currently it's possible (and could be even be meaningful) to run e.g. workbench and wf_field-workflows in parallel - without adjustments to either module (basic testing :).

Maestro provides a fully-fledged custom workflow engine that AFAIK focuses on providing enterprise business process (visual) modelling. Wf_field has no visual GUI worth mentioning and relies on the rules.module as its "engine"; wf_field focusses on simpler workflows and on providing workflow functionality more generically to any fieldable entity.[1]

We have two screencasts (incl. a slidesets and an install profile) covering the basic functionality as well as an example how use extended permissions:
http://flink-solutions.de/blog/content/granular-content-permissions-work...
http://flink-solutions.de/blog/workflow-field-wf-field-workflow-function...

The code is "coder reviewed", but in particular the initial core code (wf_field.module/wf_field.inc) is a still a little touch-and-go (our first stabs at entity, field, rules2, views3 APIs) and - shame upon me: there are no tests, so far.

If you have any questions, please do not hesitate to contact me :)

Best, Fredrik

[1] This includes e.g. multiple "concurrent" workflow fields per entity; we did some explorative stuff w/ "workflowed" user and taxonomy terms, but currently only nodes have been properly implemented. In an upcoming project we hope to be able to do some work on media module related workflows (i.e. file_entity).

Comments

odegard’s picture

odegard commented

I've obtained the latest version from the author and plan to use this module in a project. I've tested it for a couple of days now and it works really well. It's genious in that it builds upon existing tools without reinventing the wheel.

I've only found a few smallish bugs and having a project page for wf_field with all the infrastructure that entails would be of great help moving this project forward!

This module will solve a lot of use cases for those wishing to use some kind of workflow management in Drupal 7 where Maestro or workbench is not an option.

I'm not a reviewer, this is but a recommendation from an early adopter!

frega’s picture

frega commented
Priority: Normal » Critical

As advised in #drupal-contribute i'm bumping this to critical.

archnode’s picture

archnode commented

I really like the workflows you describe in your screencast, but wouldn't be most of this possible with just a text field, rules and the rules_link module (which offers an even more generic approach to triggering rules attached to content)?

Rules_link still lacks a few important features, but maybe it would make sense to join forces?

frega’s picture

frega commented

Hi archnode,

thanks for you comment! There indeed are several ways to implement this functionality (even without code); this module was inspired by this tutorial (originally for D6): http://drupal.org/node/1027546 :) - wf_field is just a "glorified" options field (a "state flag").

Whilst there is some a functional overlap (e.g. both modules offer links to trigger "actions"), the way wf_field works is to provide links to directly change a single-field value which then again triggers rules; rules_link on the other hand (AFAIK) would trigger a rule to change a single-field value. Moreover, in rules_link "links are usually displayed using views" (s. project page), whilst the links displayed w/ this module are rendered by field formatters.

The trigger link is also just a small part (the "field formatter") of wf_field, and I think that some of the functionality could be rather complicated to do directly in rules - e.g. wouldn't there be at least one rule for every possible transition? - but that's where my knowledge of rules_link breaks down. I'll definitely have a closer look at it!

Best, Fredrik

archnode’s picture

archnode commented

I agree that rules_link is a little bit more complex (and cluttered, because of the many rulesets it generates).

The great thing about wf_field is that it could provide a field that could show not only a link but also feedback about the current status of the workflow or change the available action in the wf_field based on certain conditions.

Example: Normally you get an "Apply for review"-link, but if your user subscription runs out, you could get a "Your subscription ran out" message in the wf_field and a "Renew subscription"-link. Rules would be a great framework to provide such complex logic.

But I completely understand if thats not in the scope of this module! Thanks for the answer!

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Priority: Critical » Normal
Status: Needs review » Needs work
  • git release branch missing, see http://drupal.org/node/1015226
  • lines in README.txt should not exceed 80 characters
  • Remove all old CVS $Id tags from all files, not needed anymore
  • only list files in the info file that contain classes or interfaces
  • wf_field_field_info(): why are you calling the entity_metadata functions there? Please add a comment why or remove them.
  • All hooks need to have the hook doc block, wf_field_form_field_ui_field_edit_form_alter() has none
  • Comment lines should not exceed 80 characters.
  • "@param array $form" don't add those paramters to the doc block as they are the same for every hook implementation. And "@param" without a description does not make much sense either.
  • "null" should be "NULL", please run coder to check your code style http://drupal.org/project/coder
misc’s picture

misc commented

@frega has been contacted to ask if the application is abandoned.

After ten weeks with a status of needs work: the applicant may be contacted by a reviewer to determine whether the application was indeed abandoned. The action taken by the reviewer should be documented in the project application issue.

http://drupal.org/node/894256

misc’s picture

misc commented
Status: Needs work » Closed (won't fix)

The application has been closed. If you would like to reopen it, you are free to do so.
See http://drupal.org/node/894256#abandonedtwoweekscontact