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.
Related Issues
#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: Ability to add a Workflow to Field Collection items
#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)
Comment | File | Size | Author |
---|---|---|---|
#6 | workflow_2019345_6_field.zip.txt | 4.5 KB | johnv |
Comments
Comment #0.0
johnv.
Comment #1
NancyDruSounds intriguing, are you planning on doing a patch?
Comment #1.0
NancyDruAdd D8 suggestion.
Comment #2
johnvI'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.
Comment #3
NancyDruYes, I saw that. Feel free to mark them as duplicates.
Comment #4
NancyDruHere's another one: #1559680: Make Transitions fieldable entities
Comment #5
NancyDru#895106: Extended workflow access: permission to post comments or edit specific cck fields.
Comment #6
johnvI 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.
Comment #7
johnvPlease 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
Comment #8
NancyDruThanks, John. I'd like several sets of eyes on this.
Comment #9
johnvupdated version, all-in-one patch.
Comment #10
NancyDruAre you doing any OOP stuff? I'd like to move more that way eventually.
Comment #11
johnvno 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?
Comment #12
NancyDruNo, 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.
Comment #13
NancyDruJohn, have you seen https://github.com/modernfidelity/Drupal-Entity-Workflow?
Comment #14
johnvNo, 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!
Comment #15
NancyDruOver 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.
Comment #15.0
NancyDruAdded more related issues
Comment #16
johnvPlease see newest -dev version, which contains a Workflow Field (still without comment and scheduling options.)
It is committed here.
Comment #16.0
johnvAdded #1870928
Comment #17
johnvI added #475712: Allow per-node workflows to the list of use cases in the summary.
Comment #18
johnvA small helper function is added in this commit
Comment #19
johnvNew 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.
Comment #20
johnvFor more info on D8-ifying, classifying this module, follow #1938222: Re-architect Workflow module for 8.x .... or not ?
Comment #21
johnv"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.
Comment #22
johnv"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.
Comment #23
johnvUpdate: The following has been committed:
#2105073: Add support for Entity API, Field API to table workflow_scheduled_transition
#2102663: Added support for Workflow Field to workflow_rules sub-module.
Comment #23.0
johnvadding https://drupal.org/node/475712 as a use case
Comment #24
johnvA 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.
Comment #25
johnvComment #26
parasolx CreditAttribution: parasolx commentedHi, using the latest build -dev version. Activated only submodule Node, but add node form show these error message:
Node can create without any problem.
Comment #27
johnvThanks, this is committed here.
The last notice is still there.
Comment #28
johnvI think this is now sufficiently fleshed out, to declare it Fixed.