I'd like to propose that workflow be broken down into a few smaller modules. The approach is similar to how Views handles things.

Here's my list:

  • Workflow API - All the functions, tables, actions for moving things through workflows. The current API makes a few assumptions that make it hard to work with programmatically, most often involving global $user, and those would be repaired as part of this effort.
  • Workflow Node UI - The UI for end users, focused on the workflow tab. There may be sites that manage their workflow transitions entirely through actions, web services, or other non-form-based methods that just need the API. This would also allow others to implement a custom workflow UI without having to hook_form_alter away all the current UI.
  • Workflow Admin UI - The UI for admins to define and manage workflows; all the forms under admin/build/workflow. This could be considered a development module to be disabled on production sites, increasing performance, and, like the Node UI, allows others to easily implement an alternative UI.
  • Workflow Scheduler - If enabled, expands the API and UIs to allow for scheduled transitions. Not all sites that need workflows need scheduling.

I'm willing to tackle this, but I thought I'd see if others thought it was a good idea and saw the same divisions before I started.

So, thoughts?

CommentFileSizeAuthor
#3 workflow_split.zip77.17 KBgcassie
#2 workflow_split.zip76.64 KBgcassie
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

eriktoyra’s picture

eriktoyra CreditAttribution: eriktoyra commented

+1 for your proposed breakup of the Workflow module.

gcassie’s picture

gcassie CreditAttribution: gcassie commented
FileSize
workflow_split.zip76.64 KB

well, i have been poking at this over the past few weeks and here's a start at it. there are more modules in here than the original plan, please welcome Workflow Rules and Workflow Actions.

the goals here are to:

  • make the core workflow module "form agnostic"
  • allow other modules to interact with workflows more easily
  • increase performance by not loading unwanted features and UIs

moving away from node_save() is part of this; its impact can be unpredictable when dealing with stuff like revisions, action chains, and so on. these modules attempt to use additional submit handlers to do that job.

they also split admin functions (transitions, summary, access control, and general options) into their own menu items to try to reduce admin screen load times for complex workflows.

i've only tested this with a few nodes and workflows on a small, local install. if others can give it try and throw some feedback that would be most helpful.

gcassie’s picture

gcassie CreditAttribution: gcassie commented
FileSize
workflow_split.zip77.17 KB

slight updates to actions and actions workflow hook signatures.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented

.

Josh Waihi’s picture

Josh Waihi CreditAttribution: Josh Waihi commented

subscribe

bdunwood’s picture

bdunwood CreditAttribution: bdunwood commented

subscribe

EvanDonovan’s picture

EvanDonovan CreditAttribution: EvanDonovan commented

Brilliant! subscribe.

mlowkwai’s picture

mlowkwai CreditAttribution: mlowkwai commented

.

devkinetic’s picture

devkinetic CreditAttribution: devkinetic commented

Subscribing. As someone looking at implementing workflow on a new site, this looks very nice. How is progress going & are there any drawbacks?

gcassie’s picture

gcassie CreditAttribution: gcassie commented

hi all,

i haven't had a chance to come back to this, unfortunately. if someone could take the updated versions for a spin or give the code and structure a review, and then post back their findings, that would be most helpful.

eaton’s picture

eaton CreditAttribution: eaton commented

This looks pretty promising - I've been monitoring the 'Workflow Exportables' stuff silently for a bit, and it looks like this would be a very useful first step towards modularizing the currently tangly codebase.

I'll be doing more testing shortly.

q0rban’s picture

q0rban CreditAttribution: q0rban commented

subscribe

FiNeX’s picture

FiNeX CreditAttribution: FiNeX commented

subscribe

smls’s picture

smls CreditAttribution: smls commented

subscribe

gagoo’s picture

gagoo CreditAttribution: gagoo commented

subscribing

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented
Status: Active » Needs work

I think this way we should go with workflow in D7:
1) Workflow is entity
2) State is field
3) Core actions, triggers integration
3) State formatter is configurable for displaying within entity view states
4) Access to none-workflow entity to view/change could be optional
5) Rules, views integration

The http://drupal.org/project/statereference probably is good place to grow default views implementaion

Suppose workflows itself can exportable... with uuid integration...

Suppose for D8 workflow should replace|transform into node.(status, promote, sticky) as part of standart profile

mrsinguyen’s picture

mrsinguyen CreditAttribution: mrsinguyen commented

subscribe

Niklas Fiekas’s picture

Niklas Fiekas CreditAttribution: Niklas Fiekas commented

Subscribe.

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

I like where George is going with this, and I think we should think about this when moving into the Drupal 7 world.

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
CreditAttribution: hanoii commented

subscribe

Taxoman’s picture

Taxoman CreditAttribution: Taxoman commented

Subscribing

rv0’s picture

rv0 CreditAttribution: rv0 commented

subscribe

rcuisnier’s picture

rcuisnier CreditAttribution: rcuisnier commented

subscribe

Bastlynn’s picture

Bastlynn CreditAttribution: Bastlynn commented
Version: 6.x-2.x-dev » 7.x-1.x-dev

Now that we have a functioning dev branch of 7 I'll entertain patches for 7 on this. I agree with the overall goal here.

Bastlynn’s picture

Bastlynn CreditAttribution: Bastlynn commented
Status: Needs work » Needs review

the 7.x dev branch has been updated with the request here in mind. Moving Workflow towards an API makes sense on multiple levels, and for performance reasons allowing users to turn off code they don't need is good.

Workflow is now split on the branch into:

workflow_access
workflow_actions
workflow_admin_ui
workflow_rules
workflow_views

I decided against moving the scheduler out as it fits well into the API structure. I also decided against moving the node ui out until I can adjust that to be more entities directed and we pin down exactly where the work is going on that end of things.

Please take a look at the changes made, and let me know if I've overlooked something. :)

miloyz’s picture

miloyz CreditAttribution: miloyz commented

Bravo~

Bastlynn’s picture

Bastlynn CreditAttribution: Bastlynn commented
Status: Needs review » Closed (fixed)

Based on how well this seems to be holding up in the 7.x-dev branch, I'm going to go ahead and close this request out. If there's reason to keep it open or something I missed, feel free to reopen. :)