At the moment lightning_workflow implements its own scheduler module while there's a scheduler project. Could we merge these two modules?

Original description:
I'm not running a Lightning installation, but am in need of scheduling workflow state transitions. The Lightning Scheduler module really is awesome at this (including the UX).

Are there any plans to release the Lightning Scheduler as a standalone module? Besides it being a submodule of Lightning Workflow, it also appears to have a dependency on the lightning_core module (albeit a very very small one). I was able to get the module running with some minor code changes (and removing any dependencies it has).

Comments

RaF7 created an issue. See original summary.

mpp’s picture

Title: Lightning Scheduler as a standalone module? » Use Scheduler project as a dependency
Issue summary: View changes
Related issues: +#2798689: Scheduler integration with core Content moderation

Hi @rafatwork, have a look at #2798689 for core content_moderation integration for the scheduler project.

phenaproxima’s picture

I think it's much more likely that Lightning would want to adopt Scheduler, once it supports Content Moderation, than for us to release the module as a standalone project (which would increase the maintenance burden for us)...

rp7’s picture

@phenaproxima
I understand your reasoning, but what I find a huge difference between Lightning Scheduler & Scheduler is that the latter one only supports scheduling for nodes. See the following 2 issues:

Are you aware of this limitation?

phenaproxima’s picture

@rp7: Well, there are other differences too:

- What is Scheduler's user interface like? We put a great deal of effort into our interface, building a very agile and simple UI with React. It would not be acceptable to our users for us to regress it, so Scheduler would need to be willing to accept our UI (and therefore a dependency on React, plus a somewhat complicated JavaScript build process), or something very similar.

- How does Scheduler store the underlying data? If it varies from Lightning's way (at all), we'd have to do a complex and dangerous data migration. I have done those a number of times and they are absolutely no fun; most of Lightning Scheduler's code base is, in fact, migration-related!

- Would does Lightning stand to gain from merging its scheduler with the Scheduler module? Would we get more features? For example, we'd really like to be able to support scheduling multiple items at once, which has proven very difficult to do with Content Moderation, due to the way Workflows is built. But if we got that functionality for free by merging with Scheduler, it would make a stronger case for doing that.

rp7’s picture

@phenaproxima

Thank you for the info.

Since the original intention of this issue won't be met & I'm not an active Lightning user, it's no longer relevant to me & I'll take a step back in this discussion.

Just want to leave this here: the Scheduled Updates module (https://www.drupal.org/project/scheduled_updates) claims to be a solution for your example in point #3. Something that might be worth looking at.

phenaproxima’s picture

Status: Active » Closed (won't fix)

We actually used to use Scheduled Updates in Lightning, but we had to abandon it because it's not compatible with Content Moderation :)

I think I'm going to close this issue; it's been talked over and I think we've reached a good conclusion.

mpp’s picture

Just wanted to reply to the last question in #5:

- Would does Lightning stand to gain from merging its scheduler with the Scheduler module? Would we get more features? For example, we'd really like to be able to support scheduling multiple items at once, which has proven very difficult to do with Content Moderation, due to the way Workflows is built. But if we got that functionality for free by merging with Scheduler, it would make a stronger case for doing that.

It may seem self-evident but having one module tackling a given problem space (i.e. scheduling) would reduce the total amount of code to maintain which reduces the total cost of ownership. It would also mean that the project would have a larger user base to provide fixes, reviews, features and updates like providing compatibility for content_moderation (This effort has now been made or is still going on in at least three different scheduling related projects).
I'm not saying there should be only one project for each problem space but that it should be a step in the evaluation before creating a new one.