On editing a scheduled event, the workflow property "OnHold" flag does not display as it has previously been scheduled

Steps to reproduce

Steps to reproduce:
1. Schedule an event, and tick the OnHold property in the "Schedule and upload" workflow
2. Edit the event afterwards and klick to "workflows"
3. The OnHold property is not set anymore, even tough it was set before

Actual Results:
The OnHold property is not set anymore, even tough it was set before

Expected Results:
The settings for the Workflow to be 1:1 the same as set on scheduling

Workaround (if any):
Delete the event, reschedule it, don't edit it.

This maybe relates to Issue #12340 ?


James Perrin
October 30, 2018, 12:06 PM

Ok, it's not even the fact that the "straightToPublishing" configField is hidden but just that setting any input values programmatically does not create any 'change' events. A lot of UI hiding/showing is done on these changes.

We could call change() on all configFields when loading the workflow config but this will also cause it to be PUT back multiple times as saveWorkflow() is set to run whenever the user changes a workflow parameter.

Instead, we can bind a custom event "updateConfigUI" to "straightToPublishing" and call that whenever we set its value.

James Perrin
October 29, 2018, 4:51 PM

The use of a hidden input to store configField class data, turns out not to be a great idea as changing it does not trigger any events!

I can explicitly trigger a change event when loading a config, but now if you change the hold flag it does not PUT the new workflow config in the schedule.

James Perrin
October 29, 2018, 2:54 PM

This is due to whole the standard schedule-and-upload workflows configuration is written. The workflow config parameter saved is "straightToPublishing" which is a hidden value. There is nothing triggered on this parameter changing to cause the holdOrPublishToggle toggle to change. I'll add some JS to the workflow that should fix this.

Katrin Scharnowski
October 1, 2018, 8:32 AM

We ran into this issue as well (in OC 4.4). It seams, however, that it's only a display error, thus the recording is not actually published after recording. This error only occurs in options set by radio buttons, check boxes are not affected.
It also seems like this issue occurs in 5.x and 6.x as well.

Andi Krieger
February 21, 2018, 5:41 PM

This is still active in 4.1 (build: 92f1eb4).

And quite critical for production usage, if that means that an event does not remember the "OnHold" property.

Fixed and reviewed


James Perrin


Andi Krieger


Incorrectly Functioning With Workaround