Schedule multiple transitions for a single node in serial

I thought about this today. The good news is, I don't think it would be impossible to implement. The bad news is, it would be really hard.

The devil is in the fact that moderation states are a state machine. This means that, if you're in a given state, the states you can then transition to will vary depending on the state you're currently in.

Now, if you're creating a new chain of scheduled moderation state changes, that's not really a problem. You define one change, then another (which is influenced by whatever the previous state was), and so on. But what if you want to edit such a chain? The only state you can change is the final one, because nothing is coming after it. If you change any of the states in the middle, it invalidates every state that comes after it, since each state depends on the previous one. So, to edit a chain of state transitions, you literally need to remove a whole bunch of them, then recreate them. That's gonna make for some pretty shitty UX.

This is not to mention the fact that such a UI would be very difficult to implement. Lots of AJAXy Form API stuff and other frightening dragons. Not saying it's impossible, just bloody difficult. But I wanted to dump my thoughts here for posterity, and to see if anyone has suggestions for how to proceed here.

Thanks for the thoughts, @phenaproxima. This is obviously a thorny problem. If there's sufficient demand for it, however, we may find that there are ways to deliver the business value outside the originally assumed technical constraints. For example, we have assumed thus far that the solution involves multiple revisions on the same node, leading to the chain invalidation problem you refer to (from changing revision ID's, I assume). What if we cloned entire nodes instead and scheduled an event that unpublished the original node, published the new one, and re-pointed the URL alias? That's just one (somewhat hand wavy) example to illustrate the scope of possibilities. Setting aside the originally proposed implementation, then, what do you think of the story from a business perspective?

This feature is now available in the 2.x branch of Lightning Workflow. To test:

If you are using the Lightning Profile:

composer require drupal/lightning_workflow:"2.0.0-alpha1 as 1.1.0" --no-update
composer update drupal/lightning_workflow --with-dependencies
drush update:db

If you are using Lightning Workflow as a standalone module:

composer require drupal/lightning_workflow:^2.0 --no-update
composer update drupal/lightning_workflow --with-dependencies

Lightning Workflow 2.0 will automatically migrate your existing scheduled transitions in a database update.

@balsama, I'd like to test the new feature, but I'm having trouble. I followed your instructions to upgrade from 1.1.0 to 2.0.0-alpha1, but there were no database updates, and I don't see any differences in the UI. Thoughts?

@TravisCarden Thanks for testing! or trying to test at least :)

What was the output of composer update? Do you see lightning_scheduler_update_8001 in "lightning_workflow/modules/lightning_scheduler/lightning_scheduler_install"? Are you using the profile or the standalone module? Is it possible you have a really old version of Composer or have Lightning Scheduler uninstalled?

We have fixed a few more bugs in the 2.x branch. So it's best to grab HEAD rather than the alpha1 release mentioned above.

If you are using the Lightning Profile:

composer require drupal/lightning_workflow:"2.x-dev as 1.1.0" --no-update
composer update drupal/lightning_workflow --with-dependencies
drush update:db

If you are using Lightning Workflow as a standalone module:

composer require drupal/lightning_workflow:2.x-dev --no-update
composer update drupal/lightning_workflow --with-dependencies

scheduling multiple transitions on node creation and then executing them via cron as their times expire works fine for me given the current dev branch of lightning _workflow.

This is merged in Lightning Workflow 8.x-2.x, so I'm calling this one fixed.