The 8.x branch has been created but does not contain any code yet, so it might be a good time to rethink Workflow significantly, leaving old mechanisms behind and using the new 8.x concepts and the 8.x-improved 7.x concepts like entities/entity classes, fields, and entity references, all in PSR-0/PSR-3 OO code with clear separation of entity classes and various controllers, and ready for non-SQL storage.

Most of this can actually be created on 7.x while the 8.x API is still evolving.

Is this a direction the module maintainer is interested in taking, or is there a decision to remain more compatible with the old Drupal way and not change things a lot for 8.x ?

Comments

NancyDru’s picture

Well, given #594606: Beter workflow support in Core, which the module owner has agreed with, I think it would be prudent to look at re-architecting. There are also some internal notes giving hints into that thinking.

As the only one who seems to be actively maintaining this module at the moment, my time is limited.

Traditionally the first version for a major release is basically a straight port. Later versions move more to the new core style. As you've noted, however, many of this type of change could be considered "overdue" for 7.x.

As always, patches are welcome. Detailed suggestions may meet some acceptance, as time allows.

johnv’s picture

As a first step, I'm trying the move Workflow form/widget/formatter to Field API: #2019345: Create a 'Workflow Field' with Widget, Formatter, Fieldtype

andypost’s picture

Personally I support this re-architect, I've a lot of projects that depends on workflow so glad to help and open to discussion.

The intend #2019345: Create a 'Workflow Field' with Widget, Formatter, Fieldtype is great and seriously will help to migrate d7 data to d8

The workflow entities (probably config entities) should be referenced via ER fields

johnv’s picture

This is my current workplan:
1- Create a working version of "Workflow Field" #2019345: Create a 'Workflow Field' with Widget, Formatter, Fieldtype. In the mean time, I am posting several changes to the Workflow module, hoping not to break anything.

2- The Workflow Node Form is shown in various places: on a Node View + Node Edit + Comment + Node Workflow tab. I am trying to add the Form to all of these places, but it is a "Crime"....
At the moment I have a working simple Options Widget (so, no scheduing and comments), that updates the Node and the Workflow_node_history.
I am wondering which of these variants you are using?

3- Factor out the API into new classes Workflow, Workflow_state, Workflow_transition. The current module will be using these classes. ( We must beat State Machine Module!! ;-) )

4- Create new submodule "Workflow Node", which contains the current workflow_node code. This will be enabled automatically upon update (not on new installations). Now people can choose which version to use. (The current Workflow module will then hopefully be a true Workflow API module)

At this point, The modules Workflow API/Field/Admin UI can be ported to D8. Other submodules can follow (or not..)

Then, the following Feature Request are on the table:

5- Moving Workflow, State, Transition to Entities. (Looking for volunteers!) (Is this necessary for D8?)

6- Refactor the Workflow Form. It is too large (schedule info is old-fashioned, see #2080165: Using date picker on scheduler), and it should support select_options/radio's out of the box (and even action buttons?).

7- The workflow_history table must be amended with new columns that are used in the field tables to support Workflow Field (version, language, etc). This has no priority, since leveraging the Field API opens the door for node versions, Diff module, etc.
- Create a migration function from workflow_node to workflow_field.
- Test (and port) other submodules for compatibility with Workflow Field.
- Inform the maintainers of other module, depending on the Workflow Module.

andypost’s picture

Awesome plan! I think joining forces with state machine module makes sense because they have very similar class model and they will need d8 version too.

The primary target to factor out base classes so other wrappers (entities) are very simple thing.

About forms that are visible on entity_view - you could check entity form project they have a lot of fun with it.
But for d8 I could suggest another approach that we use to decouple comment field from node to own field #1907960: Helper issue for "Comment field"

johnv’s picture

Regarding the 'node form on comment form': My current implementation is the same Workflow field, that is to be added to the comment. After saving the comment, the referenced_entity is found and updated.

johnv’s picture

Just an update of the current status per 22-sep-2013 / 30-sep-2013:
- A Workflow Field is working, including WorkflowForm on Node Form and Comment Form
--- Workflow Form on Node View or Form tab is still to be done.
--- the Workflow Form now works on Node View and Workflow History tab.
--- scheduling can be allowed/forbidden per workflow, and executed with cron.
--- only 1 Workflow Field per Node type is working. 2 Workflow Fields give unpredicted result.

- New 'entity' classes Workflow, WorkflowState, WorkflowScheduledTransition are created.
- New D8-style 'field' classes WorkflowItem (field type) , WorkflowDefaultWidget (Form) are created.
This is all within the main workflow.module. Other submodules haven't been touched, yet. Some CRUD functions can be moved from 'Workflow Admin UI' submodule into the classes.

Code reviews and tests are welcome!

johnv’s picture

Title: Re-architect for 8.x .... or not ? » Re-architect Workflow module for 8.x .... or not ?

I've just committed #2102405: Add Entity support for Workflow Field. We now have a working Workflow Field for Entities, with some limitations, as explained in the issue.

There are some procedural functions left in workflow.module file, but they can be changed when converting to D8.
Also the submodules are not completely working along. (patches welcome)
Next stop is a) try and port all this to D8, or b) objectify Admin UI.

johnv’s picture

Issue summary: View changes

I've created a follow-up D8-issue for andypost's #5 comment:
#2192305: Convert Workflow comment to core Comment field

johnv’s picture

Sent out an invitation to the StateMachine guys:
#2192309: Cooperate with Workflow module

johnv’s picture

IMO, the current state of Workflow is D8-ready.
It is field-, entity-based. It now contains two 'flavours': good old 'Workflow Node' and brand new 'Workflow Field'.
Now that D8 does not supports 'upgrades', but only 'migrations', it seems to me that Workflow Field would be he only flavour in D8.

The D7-D7-conversion took me half-a-year, carefully avoiding to break anything. But a conversion to D8 should be relatively easy, now. So if someone wants to try a D8-port, be welcome!
A fast migration would help to regain the prominent position this module seemed to have in my pre-Drupal-days :-)

PS. to adhere to the abstractifying trend of the last years, see[#2192319]

andypost’s picture

johnv’s picture

Drupal is preparing an application for Google's Summer of Code 2014 contest.
I've added the Workflow module as project number 22, aiming to have a D8 version in fall 2015.

I have ideas for the D8 version, but not enough D8 skills to mentor. Hai-Nam Nguyen (jcisio) has stepped forward to be a mentor.

Any help, ideas are welcome.

johnv’s picture

Status: Active » Fixed

I guess we're done here. I invite you all to join #2351299: Port Workflow module to Drupal 8

Status: Fixed » Closed (fixed)

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