Rework ContentSequence(Items) and RadioReport Interaction

Ticket in German as this is too complicated for the clocktime of creation:

Aus dem Gespräch mit Robert soll ein sauberes und klares Konzept für den Umgang mit ContentSequence, ContentSequenceItem und RadioReport geschaffen werden. Festzustellen ist, dass aktuell kein Konzept konsistent angewendet wird. Wir möchten daher einen klaren Zustand schaffen.

@robert: Entgegen unserer Diskussion habe ich im Konzept eine Änderung vollzogen, nämlich die oberste ContentSequence die eh nur ein Element erhalten würde entfernt und direkt die ContentSequenceItem gewählt. Das vorab möglicher Irritation durch Vorwissen vorzubeugen :)

Zielkonzept Datenmodell

• Jedem RadioReport ist ein einziges ContentSequenceItem zugeordnet. Der RadioReport ist damit ein abgeschlossener Knotenpunkt, keine Auflistung mehr.
• Das zugeorndete ContentSequenceItem repräsentiert die zusammengefasste (!) Summe des Inhaltes des RadioReport. Es kann über ContentSequenceItem.audiofile eine einzige (originale) Audiodatei zugeordnet werden.
  • Ist der RadioReport vom Typ podcast oder full_show, repräsentiert er eine Episode. Das zugeordnete ContentSequenceItem repräsentiert ContentSequenceItem.audiofile damit den kompletten Mitschnitt der Episode als eine (summierte) Audiodatei.
  • Ist der RadioReport einer der allgemeineren Beitragstypen, repräsentiert dieses ContentSequenceItem.audiofile den vollständigen Beitrag, wiederum als eine einzige Audiodatei.
  • Das Datenmodell ist für beide Fälle weiterhin exakt gleich
• Enthält der RadioReport zusätzlich einen Ablauf / besteht aus mehreren Teilen, wird eine neue ContentSequence angelegt und als ContentSequenceItem.nested_sequence zugeordnet. In diese ContentSequence findet die Planung statt
• Das alleinstehende ContentSequenceItem (das neue RadioReport.content_sequence) ist selbst nicht Teil der (optionalen) ContentSequence.
• Mehrteilige Beiträge die keine zusammenfassene Audiodatei besitzen, sondern explixit aus einzelnen Audiodateien besteht, haben für RadioReport.content_sequence_item kein ContentSequenceItem.audiofile gesetzt. Zurückgegeben wird die Liste der (zur veröffentlichung erlaubten) Audiofiles der ContentSequenceItems die sich in RadioReport.content_sequence_item.nested_sequence befinden.

Beispiel: Beitrag mit nur einer (gesammten) Audiodatei

  graph LR;
      RadioReport-->ContentSequenceItem;
      ContentSequenceItem-->Audiofile;

Beispiel: Beitrag mit mehreren Teilen

  graph LR;
      RadioReport-->ContentSequenceItem;
      ContentSequenceItem-->ContentSequence;
      ContentSequenceItem.->Audiofile;
      ContentSequence-->ContentSequenceItem1
      ContentSequence-->ContentSequenceItem2
      ContentSequence-->ContentSequenceItem3
      ContentSequenceItem1-->Audiofile1;
      ContentSequenceItem2-->Audiofile2;
      ContentSequenceItem3-->Audiofile3;

Notwendige Änderungen

Datenmodell

• Das RadioReport.content_sequence Feld wird gelöscht.

• Ein Audiofile wird im Datenmodell nicht mehr direkt einem RadioReport zugeordnet. Die direkte (reverse) Auflösung von RadioReport.audiofiles existiert damit auch nicht mehr.

• Die Auflösung von RadioReport.audiofiles könnte übergangsweise als Weiterleitung zu RadioReport.content_sequence_item.audiofile umgesetzt werden. Dadurch werden notwenige Codeänderungen vermutlich recht deutlich reduziert und die Datenmodelländerung verborgen.

Migration

• Für jeden RadioReport ist ein neues ContentSequenceItem anzulegen
• Wenn ausschließlich eine einzige Audiodatei, aber keine (nach altem Datenmodel) ContentSequence existiert, wird sie direkt diesem neuen ContentSequenceItem zugeordnet
• Wenn mehrere Audiodateien dem RadioReport zugeordnet sind, wird eine neue ContentSequence erstellt und dem neuen ContentSequenceItem zugeordnet. Anschließend wird für jedes RadioReport.audiofilesein neues ContentSequenceItem angelegt und der Liste hinzugefügt.
• Wenn nach altem (!) Datenmodell bereits eine RadioReport.content_sequence mit ContentSequenceItems existiert ist zu prüfen, ob darin ein ContentSequenceItem existiert, welches RadioReport.audiofiles referenziert. Das betrifft vermutlich alle migrierten Datensätze von v0.12.0 nach v0.13.0.

API & Programmlogik

• Thekno API: Für die Beitragsübersicht /recordings gilt
  • Wenn RadioReport.content_sequence_item.audiofile existiert, kann direkt diese Datei direkt (in einer Liste mit nur einem Element? Prüfen.) raus gegeben werden.
  • Wenn RadioReport.content_sequence_item.audiofile nicht existiert, werden alle Audiodateien des RadioReport.content_sequence_item
• Internal API: Ändern der ausgelieferten ContentSequence zu RadioReport.content_sequence_item.nested_sequence
• is_broadcasted_within_gema_range() muss das RadioReport.content_sequence_item explizit mit testen. Subelemente (z.B. bei Mehrteilern) aus RadioReport.content_sequence_item.nested_sequence müssen einzeln geprüft werden. Sequence

Darstellung

• Produktionsbackend
  • Das hochladen einer Audiodatei zu einem Beitrag / Episode bleibt bestehen. Es wird allerdings nicht mehr RadioReport.audiofiles sondern RadioReport.content_sequence_item.audiofile geändert und das entsprechende Element im Zweifel angelegt.
  • Ein + Zeichen darf gerne suggerieren, dass weitere Audiodateien reingeladen werden könnte. Beim Klicken sollte ein Hinweis erscheinen, dass mehrteilige Beiträge im unteren Content Sequence Builder in korrekter Reihenfolge angegeben werden sollen.
• Der Content Sequence Builder darf ausschließlich die RadioReport.content_sequence_item.nested_sequence bearbeiten. Es gibt aber auch nix anderes mehr.

Offene Fragen

• Was machen wir in der Migration, wenn mehrere Audiodateien + eine vorhandene ContentSequenceList existiert?