Release 0.6.0
This commit is contained in:
hnzio committed
1 parent
fd47910d09
commit
b80dded55d
40 files changed
+4080
-856
No files matched your search
+66
-21
@@ -33,22 +33,22 @@ spätere API dieselben Regeln verwenden.
|
||||
|
||||
## Gesamtdatenmodell
|
||||
|
||||
Die ersten fünf Etappen materialisieren Identität, Inhaltsverwaltung,
|
||||
Sendungsplanung und Live-Durchführung. Folgende Grenzen gelten für umgesetzte
|
||||
und spätere Bereiche.
|
||||
Die ersten sechs Etappen materialisieren Identität, Inhaltsverwaltung,
|
||||
Sendungsplanung, Live-Durchführung, Historie und Lesefreigaben. Folgende Grenzen
|
||||
gelten für umgesetzte und spätere Bereiche.
|
||||
|
||||
| Bereich | Geplante Entitäten und Beziehungen |
|
||||
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Identität | `users`, Rollen, Sessions, Einladungen, Reset-Tokens und Sperren sind umgesetzt; technische Zugänge folgen später |
|
||||
| Taxonomie | getrennte `section_categories`, `formats`, `topics` samt optionalem Themenicon; Pieces und Vorschläge mehrfach verknüpft |
|
||||
| Inhalt | `pieces` mit Status, Soft Delete, Favorit, Revision, Texten, Quellen, Werkzeugen und privaten Medien; Vorlagen speichern Snapshots |
|
||||
| Sendungsbau | `shows`, geordnete `show_sections`, `piece_usages` samt Quellen-/Werkzeug-/Themen-/Mediensnapshots, Reservebank und Vorlagen |
|
||||
| Bereich | Geplante Entitäten und Beziehungen |
|
||||
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Identität | `users`, Rollen, Sessions, Einladungen, Reset-Tokens und Sperren sind umgesetzt; technische Zugänge folgen später |
|
||||
| Taxonomie | getrennte `section_categories`, `formats`, `topics` samt optionalem Themenicon; Pieces und Vorschläge mehrfach verknüpft |
|
||||
| Inhalt | `pieces` mit Status, Soft Delete, Favorit, Revision, Texten, Quellen, Werkzeugen und privaten Medien; Vorlagen speichern Snapshots |
|
||||
| Sendungsbau | `shows`, geordnete `show_sections`, `piece_usages` samt Quellen-/Werkzeug-/Themen-/Mediensnapshots, Reservebank und Vorlagen |
|
||||
| Live | expliziter Live-Stand, aktuelles Element, tatsächliche Piece-Zeiten, persistente Abschnitts-/Gesamttimer und getrennte Präsentationsausgabe |
|
||||
| Historie | unveränderliche Abschluss-Snapshots und Verwendungshistorie; Übersprungenes zählt nicht als gesendet |
|
||||
| Freigaben | widerrufbare, gehashte Lesetokens mit Sendung, Umfang, Passwortoption und Ablaufzeit |
|
||||
| RSS | Feedquellen, Abrufläufe und externe Einträge mit stabiler Herkunfts-ID sowie Status neu/übernommen/verworfen |
|
||||
| API/Audit | technische Berechtigungen, Idempotenzschlüssel und Audit-Ereignisse mit Akteur, Aktion und Ziel |
|
||||
| Betrieb | Anwendungseinstellungen und spätere Job-Zustände, keine Geheimnisse im Klartext ohne begründete Schutzstrategie |
|
||||
| Historie | unveränderliche Abschluss-Snapshots und Verwendungshistorie; Übersprungenes zählt nicht als gesendet |
|
||||
| Freigaben | widerrufbare, gehashte Lesetokens mit Sendung, Umfang, Passwortoption und Ablaufzeit |
|
||||
| RSS | Feedquellen, Abrufläufe und externe Einträge mit stabiler Herkunfts-ID sowie Status neu/übernommen/verworfen |
|
||||
| API/Audit | technische Berechtigungen, Idempotenzschlüssel und Audit-Ereignisse mit Akteur, Aktion und Ziel |
|
||||
| Betrieb | Anwendungseinstellungen und spätere Job-Zustände, keine Geheimnisse im Klartext ohne begründete Schutzstrategie |
|
||||
|
||||
### Historien- und Kopierregel
|
||||
|
||||
@@ -238,13 +238,12 @@ Zurückgehen, Wiederaufnahme und bereits abgeschlossene Laufzeit getrennt von de
|
||||
geplanten Dauer nachvollziehbar.
|
||||
|
||||
`live_show_timer_runs` hält die unabhängige Gesamtzeit. Pause und Fortsetzen
|
||||
behandeln Gesamt-, Abschnitts- und Piece-Intervalle gemeinsam. Beenden setzt den
|
||||
Sendungsstatus auf `completed`, schließt laufende Intervalle, markiert offene
|
||||
Pieces aber nicht als erledigt. Eine ausdrückliche Wiederaufnahme bewahrt Zeiten
|
||||
und Fortschritt; nur „Neuer Durchlauf“ verwirft Laufintervalle und setzt die
|
||||
Piece-Status zurück. Die Restzeitschätzung verwendet je Abschnitt entweder die
|
||||
positive Abschnittsdauer oder die verbleibenden Piece-Dauern und zählt beide nie
|
||||
zusammen.
|
||||
behandeln Gesamt-, Abschnitts- und Piece-Intervalle gemeinsam. Beenden schließt
|
||||
laufende Intervalle und setzt `ended_at_utc`, finalisiert die Sendung aber noch
|
||||
nicht. Eine ausdrückliche Wiederaufnahme bewahrt Zeiten und Fortschritt; nur
|
||||
„Neuer Durchlauf“ verwirft Laufintervalle und setzt die Piece-Status zurück. Die
|
||||
Restzeitschätzung verwendet je Abschnitt entweder die positive Abschnittsdauer
|
||||
oder die verbleibenden Piece-Dauern und zählt beide nie zusammen.
|
||||
|
||||
Die interne Route `/live` benötigt weiterhin eine aktive Sitzung und darf
|
||||
Recherche, Moderation und eigene Arbeitsdaten lesen. Die separate Ausgabe nutzt
|
||||
@@ -295,6 +294,52 @@ sichtbar; die Oberfläche kennzeichnet den Abbruch und versucht die Verbindung
|
||||
mit verlangsamtem Intervall erneut. Private Live-Daten werden nicht Teil dieses
|
||||
Zustandsobjekts.
|
||||
|
||||
## Abschluss, Historie und Lesefreigaben
|
||||
|
||||
`src/lib/server/completion.ts` ist die Transaktionsgrenze des endgültigen
|
||||
Sendungsabschlusses. Er verlangt einen beendeten Live-Lauf sowie passende Show-
|
||||
und Live-Revisionen. Eine Befehls-ID in `show_finalizations` macht Wiederholungen
|
||||
idempotent. In derselben Transaktion werden offene Intervalle geschlossen,
|
||||
Abschnittskategorien eingefroren, ausschließlich erledigte Verwendungen außerhalb
|
||||
der Reservebank in `piece_usage_history` materialisiert, bewusst gewählte
|
||||
Fundus-Originale archiviert und die Sendung auf `completed` gesetzt. Jede normale
|
||||
Planungs- und Live-Mutation sperrt diesen Zustand.
|
||||
|
||||
Die eigentlichen Sendungstexte, Quellen, Werkzeuge, Themen und Medien liegen
|
||||
weiterhin in den beim Einplanen erzeugten Usage-Snapshots. Finalisierung friert
|
||||
die zuvor noch katalogabhängige Abschnittskategorie ein. Abgeschlossene
|
||||
Sendungen werden ausschließlich gelesen oder vollständig in einen neuen Entwurf
|
||||
dupliziert. Das Duplikat erhält neue Show-, Abschnitts-, Usage- und Relations-IDs,
|
||||
offene Usage-Status und weder Live-, Historien- noch Freigabedaten.
|
||||
|
||||
`src/lib/server/shares.ts` erzeugt für Barkeeper zufällige 256-Bit-Lesetokens;
|
||||
SQLite speichert nur SHA-256-Hashes. Eine Freigabe verweist direkt auf eine
|
||||
Sendung und darf deshalb bereits im Entwurf, im bereiten oder im laufenden
|
||||
Zustand entstehen. Der Umfang ist eine Positivliste aus `rundown`, `moderation`
|
||||
oder `research`. Optionale Passwörter liegen als Argon2id-Hash vor. Nach
|
||||
erfolgreicher Prüfung entsteht eine höchstens zwölf Stunden gültige, ebenfalls
|
||||
nur gehashte Gast-Sitzung; Fehlversuche werden pro Link und Clientadresse
|
||||
begrenzt. Änderungen an Umfang, Passwort oder Ablauf invalidieren bestehende
|
||||
Gast-Sitzungen. Ablauf und Löschung werden bei jedem HTML-, Seitendaten- und
|
||||
Medienrequest erneut geprüft.
|
||||
|
||||
Die öffentliche Route `/freigabe/[token]` erhält keine interne Sendungs-ID und
|
||||
keinen ungefilterten `Show`-Datensatz. Sie projiziert genau die am Token gebundene
|
||||
Sendung und nur die Felder ihres Umfangs. Vor dem Abschluss werden aktuelle
|
||||
Sendungs- und Usage-Snapshots bei jedem Aufruf neu gelesen; danach liefert
|
||||
dieselbe Projektion die durch die Finalisierung stabilisierten Snapshots. Die
|
||||
separate Medienroute akzeptiert ausschließlich das ausdrücklich gewählte
|
||||
Präsentationsmedium einer eingeplanten Nicht-Reserve-Verwendung derselben
|
||||
Sendung. Private `/media`-Dateien bleiben weiterhin an eine Redaktionssitzung
|
||||
gebunden.
|
||||
|
||||
Die wiederverwendbare Barkeeper-Komponente `ShareManagement.svelte` liegt direkt
|
||||
in der Sendungsbearbeitung und in der Verwaltung. Beide Routen verwenden
|
||||
dieselben Servicefunktionen für Anlage, Bearbeitung und Löschung; die
|
||||
Sendungsroute bindet Mutationen zusätzlich an ihre eigene Sendungs-ID. Die
|
||||
Verwaltung gruppiert bestehende Freigaben nach Sendung und zeigt deren aktuellen
|
||||
Status und Termin.
|
||||
|
||||
## Oberflächenstruktur
|
||||
|
||||
Die Hauptnavigation umfasst Eingang, Fundus, Sendungen, Archiv und Verwaltung.
|
||||
|
||||
Reference in new issue
Block a user