| ... | ... | @@ -33,6 +33,10 @@ |
|
|
|
- Unklar wie wir mit Metadaten/Playlisten für Live/Line/Streamingquellen umgehen. Diese können nicht in Tank hinterlegt werden, weil Playlisten hier mehr als "Templates" dienen und somit nicht persistent sind. Solche Daten können nur/erst in Steering gespeichert werden.
|
|
|
|
- Vorschläge/Feedback von Christian einarbeiten
|
|
|
|
- Sammeln von Anforderungen der Radios: Welche Metadaten sollen Medienfiles unterstützen?
|
|
|
|
- Konrad: Aktuell werden in diversen Models Bildattribute hinterlegt. Wahrscheinlich lohnt sich eine Auslagerung in ein separates Model, oder?
|
|
|
|
- Konrad: Bei Lohro wurden ab und zu Inhalte veröffentlicht, die auf Basis der Lizenz nicht hätten veröffentlicht werden sollen. Im Rahmen dessen haben wir unser [License Model](https://git.hack-hro.de/lohro/lohrothek/lohrothek-api/-/blob/main/lohrothek/core/models.py#L120) ein bisschen erweitert, auf dass für Lizenzen bestimmte Constraints definiert werden können (z.b. `needs_author` oder `requires_express_permission_for_publication`). So lässt sich dann eine Lizenz wie CC-BY (`needs_author = True`) oder "Alle Rechte vorbehalten" (`requires_express_permission_for_publication = True`) maschinenlesbar beschreiben und eine korrekte Freigabe bei zu lizenzierenden Models (z.B. Bilder) forcieren. Vielleicht ein Denkanstoß, falls wir das Problem irrtümlich oder fahrlässig veröffentlichter Inhalte hier vermeiden wollen :smile:
|
|
|
|
- Konrad: Bezüglich `created_at`, `updated_at`, `created_by` und `updated_by`: Falls der primäre Einsatzzweck eher die Information ist, wer wann Daten geändert hat, lohnt sich vielleicht ein Blick auf die Implementierung von [`LogEntry` in `django.contrib.admin.models`](https://github.com/django/django/blob/9d9ec0c79f52efad3a4d3f6ac4644d5c9fb1d22c/django/contrib/admin/models.py#L48). Ich bin nicht sicher, ob man das Model wiederverwenden will, aber es taugt wahrscheinlich als Inspiration für ein generisches Logging Model für diese Art von Informationen.
|
|
|
|
- Konrad: Bei der Arbeit am Dashboard fiel mir nochmal auf, dass die rrules statisch definiert sind (sowohl im Dashboard, als auch in Steering). Soweit ich es verstehe, können rrules als maschinenlesbarer String abgelegt werden. Es gibt JavaScript Bibliotheken, die diesen String menschenlesbar beschreiben und wir könnten im Dashboard einen rrule Editor hinzufügen und die jetzt verfügbaren Schnellauswahlen beibehalten (nur dass sie auf einen rrule String, statt eines ForeignKeys in Form eines Integers verweisen). Lohnt es sich in `Schedule` das `rrule` Attribut zu einem rrule-String zu konvertieren, auf dass wir mehr Freiheit im Dashboard erhalten und die statische Konfiguration im Dashboard als auch in Steering loswerden?
|
|
|
|
|
|
|
|
## Erweiterung in Tank
|
|
|
|
|
| ... | ... | |
