As a user, I need more control over workflows, so that I can work more efficiently
Actually, several stories shall be addressed:
*As a producer, I need to be able to stop running workflows, so that I don't need to wait until they finished *
Use case example: Too bad if a producer has started a workflow just to find out a little later the he needs to first adapt metadata or cut the video. Currently, the producer needs to wait until the workflow has finished processing (can take hours) before he can apply the changes and start the workflow.
If the producer could stop running workflows, he wouldn't have to wait for hours...
As a system administrator, I need to be able to delete workflows
Use case: In support cases where many workflows were started but all failed (until the last one that fixed whatever the problem was), it is desirable to not keep all the attempts to fix the problem (usually requires starting workfows) in the history.
On the other hand, it is undesirable that producers can delete workflows as they normally shouldn't.
NOTE for future readers: read comments on the commit to get the scope of the patch related to this ticket.
This has been merged. I therefore close this issue as "Fixed and reviewed".
Oh yes the 100's of WF were all resumed, successfully too.
So far we have just 2 WFs paused since moving to OC 3.x and we only found them when I added the Rute's PAUSED state code a few of weeks ago. They will get STOPPED or RESUMED depending on the reason, they may be then re-run with editing.
Just off the top of my head, FAILING a workflow may be more useful than just STOPPED, the reason is we've implemented the archive operation in our error-handler workflow so if compose fails after editing the smil file is not lost etc.
@james.perrin when you PAUSED recordings, do you usually stop/delete/ignore them, or sometimes RESUME them? I imagine those 100s of WFs that were blocking ended up being resumed. That is also a good use case related to using PAUSE to reduce load in high load situations. It's kind of like throttling network traffic to prevent lost packages.
I've actually used Rute's code as a basis to add this functionality to our 3.x AdminUI a few weeks ago, the main reason being to handle the odd case were a recording has been made in error or something was recorded that should not be published. We allow users or service staff to pause recordings via their domain specific UI's, but we weren't able to see PAUSED recordings via the AdminUI. We allow indefinite PAUSED WFs though there are so few we can chase these up manually.
We have paused 100's of WFs when we came up a massive blockage in the old "synchronized" archive operation, see my talk form Cologne.
The "pause on fail" functionality of Rute's original code is less important to us as our WFs are so light in comparision to DCE's