OpenFn / lightning

OpenFn/Lightning ⚡️ is the newest version of the OpenFn DPG and provides a web UI to visually manage complex workflow automation projects.
https://openfn.github.io/lightning/
GNU Lesser General Public License v3.0
129 stars 35 forks source link

Preventing simultaneous editing should not stop users from running workflows #2282

Closed taylordowns2000 closed 3 weeks ago

taylordowns2000 commented 3 months ago

This isn't quite a bug, but a pretty high priority issue. In #2241 we were attempting to prevent a possible data loss situation where two edits would overwrite one another.

That feature was all about preventing simultaneous editing of a workflow. As it was delivered, however, it also included code that prevents user B from running a workflow while user A is looking at the same workflow.

We don't want this. It's OK for user B to run a workflow while user A is looking at that workflow.

What's more, with the current implementation it's still possible for user B to run the workflow while user A is looking at it, but they're forced to go on a bit of a journey... they're only blocked from running the workflow from the Inspector interface and they're forced to navigate to the History page before clicking "retry" or to CURL the webhook URL to create a new workorder.

We may find that the fix is as simple as removing the || !@has_presence_edit_priority from this code:

disabled={
  @save_and_run_disabled ||
  @snapshot_version_tag != "latest" ||
  !@has_presence_edit_priority
}

But careful testing should be done.

Note that the run button on the Inspector may be built in such a way that it always "saves and then runs". It will probably Just Work :tm: once we remove the has_presence_edit_priority bit since we’re already blocking edits to the editor—so they won't have updated anything even if they "save and run", but I’d rather take some more time to guarantee this, maybe through tests?

taylordowns2000 commented 3 months ago

@christad92 , @elias-ba , documented here for later!

christad92 commented 2 months ago

With save and run, there is a risk of potentially overwriting unsaved work by running a version of the workflow that is actively being worked on. That said, we need to ensure that when the Create work order/Retry from here button is pressed, the run should be executed with the latest version of the workflow.

users should also get a notification saying that someone is active on the workflow, running this might overwrite their work (if we save), and the work order can result in an error/exception.

christad92 commented 1 month ago

An update on this:

We really should push the update. If the workflow is saved by the editor, the current user should either see that what WAS “latest” is now no longer “latest”. Or they should get their view updated to the latest automatically. I’d vote for the first one. So if Sizwe saves, and I was viewing “latest” in view-only mode, push an event that makes my view switch to show that the code I’m viewing is no longer the latest, but instead v27 or whatever with run disabled. That therefore blocks me from running until I switch to the latest.

We should show a flash message when the version changes to say "The version of the workflow you are viewing is no longer the latest"