Scheduling review - API and UI
considering
Mikee Elliott
When scheduling a repeating series of events, it's possible to enter start dates for the series into the past. These dates in the past are ignored when creating the captures, but will clash with captures within the entire date range.
Allowing a capture series to be started in the past doesn't make sense.
Clashing with captures that won't be created as part of that workflow also doesn't make sense.
When we have scheduled a one-off replacement for a failed series, we are prevented from entering the timetabled dates for the entire series when attempting to re-insert this schedule due to clashing with captures that have already passed.
We have also encountered the issue of 'failed' recordings that were programmed after their supposed time.
Can the validation rules around schedule creation please been changed to either:
Not permit schedule creation starting before the first valid capture time (ie NOW), or
Not clash with captures in the past, or
both these things
Mikee Elliott
We have encountered a situation again this semester where we're clashing and failing recording insertion on the API where no clash is detectable in the UI
There is an exception pattern in the recording, where another series lives, and the API is failing with a reported clash.
Hannah Petty
considering
Hi Mikee Elliott
We're about to revamp scheduling as a part of our next round of Folders work. The new interface will actually surface conflicting capture information as well as make several improvements to the workflow in general. We'll take a look and see what we can do on the API side as well.