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
The OnHold property is not set anymore, even tough it was set before
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 ?
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.
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.
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.
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.
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.