Problem/Motivation

I was exploring a new use case, which involves nodes/entities with state changes. The current website contains a Node type with a simple listfield, which contains all possible states. Using Editablefields, I was able to show the widget on a node view page, or in a Views display.

The Workflow module has nice features, and fullfills most needs. Above all, it restricts some transitions to certain roles.
I also considered more complete packages like Support, Case tracker and the Commerce order entity and Workbench.

Proposed resolution

IMO a 'true' workflow field would make this module more in-line with other Field UI module. It may then be used as an 'engine' in aforementioned or new modules.
It will also be an answer to some feature requests (in some issue) like "can I have 2 workflows on one node?". The answer was: "We'd need a rewrite to accomplish that." Using Fields, this request is feasible.
It gives also more flexibility on the use of the widget. The same field mat have the complete Form (including comment and schedule) on the node page, and only the select list, in a Views display, which allows the user to quickly change states.
For other developers, it would be easier to create new widgets using Field API.
(I am aware of the Workflow Extensions module, but that seems to go another direction. OTOH, this proposal might be part of that module, as well.)

Since #723310: Break workflow into smaller modules is now in place, the Field would ideally use the Workflow API.

Remaining tasks

I propose to add a Workflow Field submodule (I do NOT mean the abandoned Workflow Fields module)
It would contain widgets and formatters.
The Field points to a Workflow. The State-change UI and the Access UI would remain the same.
Also the storage can stay the same. (A composed field would be the D7-way, but that probably requires more work and an upgrade path, or be stuck with two storage methods. But it might be a good D8-initiative , too)

API changes

Ideally, Workflow Field can use Workflow API. More likely, some adaptations are needed.

#723310: Break workflow into smaller modules
#1781308: Improve UI: turn workflow fieldset in node form to a vertical tab

This initiative would be a solution for the following feature requests:
#1891460: Multiple workflows on a node
#1988990: Is it possible to have a workflow on a per entity translation basis?
#1877070: Workflow to field collection itmes
#711066: Vertical tabs support using field_group
#843568: Workflow states against revisions rather than nodes
#1202274: Work flow with multilanguage
#409764: Allow views integration to also show nodes that have no workflow associated with them
#1870928: Add workflow states for custom entity

The following might also be possible using a 'true' field:
#1974068: Workflow on webforms
#1623282: Integration with revisioning
#537790: Workflow and revisions (diff module compatibility)
#372724: Workflow integration with revisions - states for revisions
#475712: Allow per-node workflows when having 2 workflows on one node type, and only displaying one at a time (eg, using custom code or Conditional Fields)

Comments

Issue summary:View changes

.

Sounds intriguing, are you planning on doing a patch?

Issue summary:View changes

Add D8 suggestion.

I'll try to post a starting patch the next weeks.
I've been through the issue queue, and marked some issues as relevant. See the 'related issues' in the summary.

Yes, I saw that. Feel free to mark them as duplicates.

I just wanted to share my first results of turning Workflow into Field API.
I attached a zip file, not a patch. (for some reason the new files are not in a patch file.)
You'll find lots of todo's in the code.

The Field:
In the current version you can add 1 or more workflow fields to an entity. You need to enable a node type for Sorkflow berforehand, but then you can add the fields, allowing form more then one workflow per entity. You can change the states, but the are not recorded in the history yet.
The widget:
The normal core selectlist/checkboxes are used. The workflow form not yet. This means: you cannot schedule a state change, you cannot create comment.
The history:
I thought I recorded the history, but no history is recorded yet.
Comments:
You cannot add the field to Comment yet, since there is the link with the node is not there yet.

I may have some requests for the Workflow API.
- separate the API functions from the hook_node* functions into 2 different files. This way we can figure out a way toenable the field, and disable the hook_node functions.
- in hook_node_insert, the code to determine the first viable may be in separate function. I created a workflow_first_state($node).

Next steps:
- add comment link
- change $choices = workflow_field_choices($node, $force, $workflow, $current_sid); so the function works for every field.
- add history logging.

Please find attached the latest status in 2 patches.
1. the modules.patch file contains changes/additions to the api:
- function workflow_node_tab_access() is adapted to work with the Field.
- function workflow_node_load() has 20 lines moved ito a new function workflow_first_state(), so that part can be reused.
- function workflow_node_update is adapted to work with the Field.
- function workflow_field_choices() is adapted to work with the Field. It's interface is 'overloaded' to accomplish this.
- function workflow_first_state() is a new function. this was part of workflow_node_load().

2. the file workflowfield.zip.txt must be renamed to .zip, extracted and placed in the main workflow module.
- It contains all data for the new field type.

Current functionality:
- a new field type 'Workflow' with select list and checkboxes widgets
- you can set the status of the field from the node and from the comment. The workflow history is updated, too.
- I'v made some changes in the workflow.module, so now the field works, even if you do NOT assign a workflow to a node type.
- prepared for not-node entities.
- no support for scheduling, workflow comment, yet

Todo:
- add scheduling, workflow comment.
- cleaning up.
- testing (e.g., initial values are not always correct.)
- move workflowfield.module to workflow.field.inc
- it would be nice to separate workflow.module into workflow.api.inc and workflow.node.inc. This file should then be optional

Thanks, John. I'd like several sets of eyes on this.

StatusFileSize
new28 KB

updated version, all-in-one patch.

Are you doing any OOP stuff? I'd like to move more that way eventually.

no OOP. I've been using that in other languages. Haven't done that in PHP yet. It might be a good idea for a D8 version.

I have encountered some sandboxes that have tried a Field API approach. Apparently none of them succeeded. Have you tried them out /cooperated in the past?

No, I haven't. But on the same site where I needed Workflow, I have to deal with a lot of fields in custom code. I am still struggling with them.

No, i havn't. I remember reading about it somewhere. I think we complement: my goal is to replace the hook_node api with a hook_field api, leaving the workflow itself intouched.
I do want to extend the workflow history table with all the field properties like language, vid, etc.
But i am not that far yet. Next three weeks are holidays!

Over the weekend, I wrote a module that is creating a new entity type. Now I need to work on a field to add to it.

Issue summary:View changes

Added more related issues

Please see newest -dev version, which contains a Workflow Field (still without comment and scheduling options.)
It is committed here.

Issue summary:View changes

Added #1870928

I added #475712: Allow per-node workflows to the list of use cases in the summary.

A small helper function is added in this commit

Title:Factor out the Workflow Form into Field API Widget and FormatterCreate separate classes for Workflow Widget, Formatter, Fieldtype and Workflow, WorkflowState

New classes have been added in this commit.

For Field: WorkflowDefaultWidget, WorkflowItem (the field type)
These classes are already D8-style. They have D7 wrapperfunctions in workflowfield.widget.inc and workflowfield.field.inc
Although the classes are defined in the Workflow module, they are activated in the Workflow_Field module. See README.txt for some details.

For Workflow API: Workflow, WorkflowState
These two classes may become real Entities in the future. ATM, no CRUD is provided, since that is still in Workflow Admin UI.

The code is mainly copied from the Workflow core module.

For more info on D8-ifying, classifying this module, follow #1938222: Re-architect Workflow module for 8.x .... or not ?

"Updated Workflow classes to show Workflow Form also on Node View page." is committed here.

"Fixed some issues in workflow.module file when using WorkflowField submodule" is committed here.

"Changed workflow_field submodule to support Workflow Form on Node view page" is committed here.

"Moved Node specific function workflow_forms() from workflow.module to workflow.node.inc" is committed here.

"Added new WorkflowTransition class (as superclass of WorkflowScheduledTransition)." is committed here.
"Moved Workflow Form processing code from workflow.module into new WorkflowTransition class." is committed here.
"Replaced all functional calls to Workflow object by OOP Methods of Workflow class" is committed here and here.

Issue summary:View changes

adding https://drupal.org/node/475712 as a use case

Title:Create separate classes for Workflow Widget, Formatter, Fieldtype and Workflow, WorkflowStateCreate a 'Workflow Field' with Widget, Formatter, Fieldtype
Version:7.x-1.x-dev» 7.x-2.x-dev
Issue summary:View changes

A new version 7.x-2.x is created with a 'Workflow field' submodule.
The current way-of-working is separated in a new submodule 'Workflow Node', which is automatically enabled upon upgrade.

There is continuous maintenance to enable Workflow Field and the other submodules for other entities like 'user, 'term', etc.
There is continuous maintenance to centralize cone into the new lazy-loaded classes Workflow, WorkflowState, WorkflowTransition.

Hi, using the latest build -dev version. Activated only submodule Node, but add node form show these error message:

    Notice: Undefined index: name_as_title in WorkflowDefaultWidget->formElement() (line 81 of C:\xampp\htdocs\workflow\sites\all\modules\workflow\includes\Field\WorkflowDefaultWidget.php).
    Notice: Undefined index: schedule in WorkflowDefaultWidget->formElement() (line 83 of C:\xampp\htdocs\workflow\sites\all\modules\workflow\includes\Field\WorkflowDefaultWidget.php).
    Notice: Undefined index: schedule_timezone in WorkflowDefaultWidget->formElement() (line 84 of C:\xampp\htdocs\workflow\sites\all\modules\workflow\includes\Field\WorkflowDefaultWidget.php).
    Strict warning: Only variables should be passed by reference in WorkflowDefaultWidget->formElement() (line 167 of C:\xampp\htdocs\workflow\sites\all\modules\workflow\includes\Field\WorkflowDefaultWidget.php).

Node can create without any problem.

Thanks, this is committed here.
The last notice is still there.

Status:Active» Fixed

I think this is now sufficiently fleshed out, to declare it Fixed.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

  • Commit 34bdfa2 on 7.x-2.x by johnv: Issue #2019345 by johnv: Added parameter 'transition' to hook_workflow...

  • Commit 9637d8f on 7.x-2.x by johnv: Issue #2019345 by johnv: Added error message when setting state on non-...

  • Commit 05f66bd on 7.x-2.x by johnv: Issue #2019345 by johnv: Added token 'workflow-state-age' from...
  • Commit b835146 on 7.x-2.x by johnv: Issue #2019345 by johnv: Added error message when used workflow is...

  • Commit 1e4918b on 7.x-2.x by johnv: Issue #2019345 by johnv: Removed workflownode.inc into workflownode....

  • Commit 767b93a on 7.x-2.x by johnv: Issue #2019345 by johnv: Added method getWorkflow() to...