Unable to create repetition schedule

The dashboard currently allows users to create a repetition schedule when selecting a timeslot in the calendar area.

The POST request to the /api/v1/schedules/-endpoint with the following payload triggers a 500-error in steering with an uncaught exception:

{
  "schedule": {
    "addBusinessDaysOnly": false,
    "addDaysNo": 1,
    "showId": 45,
    "isRepetition": true,
    "firstDate": "2025-01-17",
    "startTime": "08:45:00",
    "endTime": "10:15:00",
    "rruleId": 1,
    "lastDate": null,
    "defaultPlaylistId": null,
    "byWeekday": 4
  }
}

The original schedule has just a single timeslot (rrule is once). I’m adding a repetition schedule for the next day. The request triggers a TypeError in line 538 of the generate_timeslots function (> not supported between instances of datetime.date and NoneType).

I have a few thoughts:

1. Is it helpful that steering has to figure out the repetition? Couldn’t the dashboard just create a regular schedule and add the appropriate number of days to the firstDate property?
2. We only expose that the schedule is a repetition (isRepetition). Wouldn’t it be nice to know which schedule is actually being repeated?

If steering should figure out the repetition and the information which schedule is repeated is useful, we might as well create an endpoint like this:

# POST /api/v1/schedules/4/repeat
{ 
  "addBusinessDaysOnly": false,
  "addDaysNo": 1
}

The request would return a conflict resolution response like POST /api/v1/schedules/ does.

assigned to @eigenwijsje

added bug label

added discuss label

added Cycle [1/25] label

changed milestone to %1.0-alpha6 — Wondrous Whale

added P1 label

added To Do label

added Doing label and removed To Do label

I’ve fixed the cause of the exception.

But, I agree that it seems better to

• keep track of which schedule is being repeated,
• offer a route to better express this.

Let’s create a separate issue for this.

If there is a way to do this without re-introducing drf-nested-routers, I’m open to it.

No need for drf-nested-routers. We can simply use an action with detail=True. I also wouldn’t consider these nested: they are simply operations on a specific resource, which are perfectly fine in the REST world.

added ready-for-testing label and removed Doing label

@kmohrf since you created the ticket, can you please test & close?

Tested and works. Do you want to keep the general feedback on the API (storing which schedule is repeated and adapting the api) somewhere in an epic? It would be good to know how we address the different repetition concepts and which of those are essential and which are just nice to have.

Thanks for the heads-up. I think this ticket is a good start to dump our thoughts for now.

edit: on the other hand, this is meant for the first playout-related POC, where we may not have enough time to finalize all the concepts. So I'm unsure if this follow-up ticket might be the better place.

closed

removed ready-for-testing label

marked this issue as related to aura#97

marked this issue as related to aura#15

removed discuss label