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
@@ -506,3 +506,37 @@ vollständige erneute Matrix.
|
||||
- Zusätzliche visuelle Chromium-Prüfung bei 656 × 400 und 390 × 700 Pixeln:
|
||||
Sendungskarte unter 130 Pixel hoch, Menü-/Ausgabe-/Timericons sichtbar und
|
||||
Pausebutton wechselt bedienbar zu Fortsetzen.
|
||||
|
||||
## Etappe 6
|
||||
|
||||
| Kriterium | Nachweis | Stand |
|
||||
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
| Spätere Originaländerung verändert Historie nicht | Verhaltenstest ändert Piece und Abschnittskategorie nach Abschluss; historische Snapshots bleiben gleich | erfüllt am 25.10.2026 |
|
||||
| Abschluss nicht doppelt; übersprungen ist nicht gesendet | idempotente Befehlswiederholung, fremde Befehls-ID und materialisierte Usage-Historie im Verhaltenstest | erfüllt am 25.10.2026 |
|
||||
| Bewusste Auswahl archiviert nur gewählte Originale | Abschlusskandidaten und explizite Archivauswahl im Service; Dialog trennt gesendet, übersprungen und offen | erfüllt am 25.10.2026 |
|
||||
| Archivierte Sendung stabil und duplizierbar | Service- und Browsertest prüfen Nur-Lese-Ansicht sowie neuen Entwurf ohne Live-, Historien- oder Freigabedaten | erfüllt am 25.10.2026 |
|
||||
| Gast sieht genau eine Sendung und nur erlaubte Felder | anonymer Chromium-Kontext und Scope-Verhaltenstests für Ablauf, Moderation und Recherche | erfüllt am 25.10.2026 |
|
||||
| Gast-Schreibzugriff und fremde IDs abgelehnt | anonymer direkter POST erhält 403; fremde Medien-ID erhält 404 | erfüllt am 25.10.2026 |
|
||||
| Passwort, Ablauf und Widerruf schützen direkte Aufrufe | Service- und Browsertests prüfen Seite, Gast-Sitzung und direkten Medienrequest vor und nach Widerruf | erfüllt am 25.10.2026 |
|
||||
| Barkeeper verwaltet Freigaben | Anlage, Bearbeitung und Löschung direkt in der Sendung sowie gruppiert in der Verwaltung im Browser geprüft | erfüllt am 25.10.2026 |
|
||||
| Offene Sendungen sind sicher freigebbar | Service und anonymer Browser prüfen aktuellen Plan vor Abschluss und stabilen Stand danach | erfüllt am 25.10.2026 |
|
||||
| Bestehende Abschlüsse werden einmalig übernommen | Upgrade-Test wendet `0015` auf einen Stand bis `0014` zweimal an und findet genau eine Historie | erfüllt am 25.10.2026 |
|
||||
| Bestehende Freigaben bleiben bei Erweiterung erhalten | Migration `0016` ersetzt nur die Fremdschlüsselgrenze und kopiert Freigaben sowie Gast-Sitzungen | erfüllt am 25.10.2026 |
|
||||
|
||||
## Ausgeführte Prüfungen Etappe 6
|
||||
|
||||
- `npm run check`: 0 Fehler und 0 Warnungen
|
||||
- `npm test`: 52 Tests in 11 Dateien erfolgreich
|
||||
- gezielter Chromium-Ablauf für Abschluss, Archiv, historische Ansicht,
|
||||
offene und abgeschlossene Freigabe, Bearbeitung und Löschung in beiden
|
||||
Barkeeper-Oberflächen, Passwort, privaten Scope, Reserve-Medienschutz, fremde
|
||||
ID und Gast-POST: 1 von 1 erfolgreich
|
||||
- `npm run test:e2e`: nach Korrektur eines bestehenden, auf den 24. Oktober
|
||||
festgelegten „Heute“-Fixtures 18 von 18 Chromium-Browsertests erfolgreich
|
||||
- Browserprüfung von Sendungsfreigabe und Gastansicht bei 390 × 844 Pixeln sowie
|
||||
der Verwaltung bei 1280 × 900 Pixeln ohne horizontalen Überlauf; Screenshots
|
||||
visuell kontrolliert
|
||||
- `npm run build`: erfolgreich mit `@sveltejs/adapter-node`
|
||||
- `npm run lint`: Prettier und ESLint erfolgreich
|
||||
- Versionsgleichheit `0.6.0` in Paket, Lockdatei und Cloudron-Manifest geprüft
|
||||
- `bash -n start.sh` und `git diff --check`: erfolgreich
|
||||
+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.
|
||||
|
||||
+27
-1
@@ -419,9 +419,35 @@ verbleibenden Piece-Dauern. Bereits abgeschlossene Abschnitte werden ausgelassen
|
||||
ungeplante Abschnitte werden sichtbar gezählt und eine Überziehung reduziert
|
||||
nicht die geplante Zeit kommender Inhalte.
|
||||
|
||||
`completed` beendet einen Durchlauf, nicht automatisch dessen offene Pieces.
|
||||
`ended_at_utc` beendet einen Durchlauf, nicht automatisch dessen offene Pieces.
|
||||
Wiederaufnahme und neuer Durchlauf sind deshalb getrennte Befehle: Erstere
|
||||
bewahrt Intervalle und Fortschritt, letzterer setzt beides ausdrücklich zurück.
|
||||
Das private Markdownfeld „Interaktion“ folgt derselben Original-/Snapshotgrenze
|
||||
wie Moderation und Überleitung, ist aber nicht Teil der öffentlichen
|
||||
Präsentations-Positivliste.
|
||||
|
||||
## D-027: Abschlusszustand und Freigaben als eigene Sicherheitsgrenzen
|
||||
|
||||
Ein beendeter Live-Lauf ist wiederaufnehmbar und deshalb nicht identisch mit
|
||||
einer historischen Sendung. Erst eine eigene transaktionale Finalisierung setzt
|
||||
`shows.status` auf `completed`. Eine dauerhaft gespeicherte Befehls-ID verhindert
|
||||
Doppelverbuchung; Usage-Historie enthält nur `done`, nie `skipped` oder Reserve.
|
||||
Bestehende Usage-Snapshots bleiben Inhaltsquelle, während Abschnittskategorien
|
||||
beim Abschluss zusätzlich eingefroren werden. Historische Sendungen werden nicht
|
||||
erneut bearbeitet, sondern mit neuen IDs und zurückgesetztem Laufzustand kopiert.
|
||||
|
||||
Lesefreigaben sind keine abgeschwächten Redaktionssitzungen. Sie verwenden eine
|
||||
eigene Positivprojektion mit drei kumulativen Umfängen. Roh-Tokens und
|
||||
Gast-Sitzungstokens stehen nie in SQLite, optionale Passwörter verwenden Argon2id.
|
||||
Passwort, Ablauf und Widerruf werden zentral vor Seite, Seitendaten und Medium
|
||||
geprüft. Präsentationsmedien sind an Freigabe, Sendung und Usage-Snapshot
|
||||
gebunden; beliebige Fundus-Dateien bleiben ausgeschlossen.
|
||||
|
||||
Freigaben verweisen auf `shows` statt ausschließlich auf Finalisierungen. Damit
|
||||
kann ein Barkeeper bereits einen Entwurf oder eine laufende Planung teilen. Die
|
||||
Gastprojektion liest bei jedem Aufruf die aktuellen Sendungssnapshots; der
|
||||
spätere Abschluss stabilisiert genau diese bestehende Datenquelle, ohne Token
|
||||
oder URL zu wechseln. Bearbeitungen behalten den Link, invalidieren aber
|
||||
vorhandene Passwortsitzungen. Vollständiges Löschen ist der unmittelbare
|
||||
Widerruf. Die Sendungsbearbeitung und die zentrale Verwaltung verwenden dieselbe
|
||||
Geschäftslogik und bleiben Barkeepern vorbehalten.
|
||||
@@ -1,5 +1,58 @@
|
||||
# Release Notes
|
||||
|
||||
## 0.6.0 - Abschluss, Archiv und Freigaben
|
||||
|
||||
Veröffentlicht am 25. Oktober 2026
|
||||
|
||||
Sendewerk 0.6.0 trennt das wiederaufnehmbare Ende eines Live-Laufs vom
|
||||
unveränderlichen redaktionellen Abschluss. Abgeschlossene Sendungen erhalten
|
||||
eine stabile Historie, liegen im Archiv und können als neuer Entwurf dupliziert
|
||||
werden. Barkeeper geben genau eine geplante, laufende oder historische Sendung
|
||||
über widerrufbare, optional passwortgeschützte Leselinks frei.
|
||||
|
||||
### Abschluss und Historie
|
||||
|
||||
- Ein Abschlussdialog zeigt gesendete, übersprungene und offene Pieces getrennt
|
||||
und bietet ausschließlich gesendete Originale zur bewussten Archivierung an.
|
||||
- Finalisierung ist transaktional und idempotent. Übersprungene Pieces und die
|
||||
Reservebank werden nicht als gesendet verbucht.
|
||||
- Usage-Texte, Relationen, Kategorien und tatsächliche Zeiten bleiben nach dem
|
||||
Abschluss stabil, auch wenn Fundus-Originale oder Kataloge später wechseln.
|
||||
- Historische Sendungen sind intern nur lesbar. Die Duplikation erzeugt einen
|
||||
unabhängigen Entwurf mit offenen Pieces und ohne früheren Lauf- oder
|
||||
Freigabezustand.
|
||||
|
||||
### Archiv und Freigaben
|
||||
|
||||
- Das Archiv zeigt abgeschlossene Sendungen neben archivierten und gelöschten
|
||||
Pieces und bietet die Duplikation direkt an.
|
||||
- Barkeeper erstellen Leselinks direkt in der Sendungsbearbeitung oder zentral
|
||||
in der Verwaltung für Ablauf, Moderation oder vollständige Recherche, optional
|
||||
mit Passwort und Ablaufzeit.
|
||||
- Noch nicht abgeschlossene Sendungen zeigen Gästen beim nächsten Aufruf den
|
||||
aktuellen Plan. Nach dem Abschluss bleibt derselbe Link auf dem stabilen
|
||||
historischen Stand.
|
||||
- Freigaben lassen sich in nach Sendung gruppierten Verwaltungskarten bearbeiten
|
||||
und endgültig löschen; Passwortänderungen beenden vorhandene Gast-Sitzungen.
|
||||
- Tokens und Gast-Sitzungen liegen nur gehasht vor; Passwörter verwenden
|
||||
Argon2id und Fehlversuche sind begrenzt.
|
||||
- Gastseiten projizieren genau eine Sendung. Private Originaldaten, Nutzer,
|
||||
interne IDs und Felder außerhalb des gewählten Umfangs werden nicht geliefert.
|
||||
- Direkte Medienaufrufe prüfen dieselbe Freigabe, Passwortsitzung, Ablaufzeit und
|
||||
den Widerruf erneut und erlauben nur das freigegebene Präsentationsmedium.
|
||||
|
||||
### Technik und Prüfung
|
||||
|
||||
- Migration `0015_completion_archive_and_shares.sql` übernimmt bestehende
|
||||
abgeschlossene Sendungen und ergänzt Finalisierung, Historie,
|
||||
Duplikationsbefehle, Freigaben, Gast-Sitzungen und
|
||||
Passwortversuchsbegrenzung.
|
||||
- Migration `0016_shares_for_active_shows.sql` erhält vorhandene Freigaben und
|
||||
erweitert ihre Referenz auf alle Sendungszustände.
|
||||
- Paket, Lockdatei und Cloudron-Manifest tragen gemeinsam Version `0.6.0`.
|
||||
- 52 Verhaltenstests und 18 Chromium-Abläufe decken den bisherigen Umfang sowie
|
||||
Abschluss, Archiv und anonyme Lesefreigaben ab.
|
||||
|
||||
## 0.5.12 - Live-Regie und Sendungskalender
|
||||
|
||||
Veröffentlicht am 24. Oktober 2026
|
||||
|
||||
+38
-3
@@ -2,10 +2,45 @@
|
||||
|
||||
## Aktueller Umfang
|
||||
|
||||
Etappe 1 bis Etappe 5 sind abgeschlossen. Architektur, Gesamtdatenmodell,
|
||||
Etappe 1 bis Etappe 6 sind abgeschlossen. Architektur, Gesamtdatenmodell,
|
||||
Anmeldung, Rollen, persistente Inhaltsbearbeitung, Sendungsplanung,
|
||||
Live-Steuerung, Präsentationsausgabe und lokaler Betriebsweg sind dokumentiert.
|
||||
Etappe 6 wurde nicht begonnen.
|
||||
Live-Steuerung, Präsentationsausgabe, unveränderliche Sendungshistorie,
|
||||
Archiv und sichere Lesefreigaben sind dokumentiert.
|
||||
|
||||
## Abschluss, Archiv und Freigaben 0.6.0
|
||||
|
||||
- das Ende eines Live-Laufs bleibt wiederaufnehmbar; erst der getrennte,
|
||||
idempotente Abschluss friert Sendung, Kategorien, tatsächliche Verwendungen
|
||||
und Zeiten unveränderlich ein
|
||||
- der Abschlussdialog zählt gesendete, übersprungene und offene Pieces getrennt
|
||||
und archiviert Fundus-Originale ausschließlich nach bewusster Auswahl
|
||||
- die Verwendungshistorie wird beim Abschluss materialisiert; übersprungene
|
||||
Verwendungen und die Reservebank zählen nicht als gesendet
|
||||
- abgeschlossene Sendungen liegen getrennt im Archiv, sind intern nur lesbar und
|
||||
lassen sich mit neuen IDs, offenen Verwendungen und ohne Live- oder
|
||||
Freigabezustand in einen neuen Entwurf duplizieren
|
||||
- Barkeeper verwalten gehashte Leselinks direkt in der Sendungsbearbeitung und
|
||||
gesammelt in der Verwaltung; Umfang, Passwort und Ablauf lassen sich ändern,
|
||||
Freigaben vollständig löschen
|
||||
- Entwürfe, bereite und laufende Sendungen lassen sich bereits freigeben;
|
||||
Planänderungen werden beim nächsten Gastaufruf sichtbar, während der Abschluss
|
||||
denselben Link auf den unveränderlichen historischen Stand festlegt
|
||||
- passwortgeschützte Freigaben verwenden kurzlebige, gehashte Gast-Sitzungen und
|
||||
begrenzen Fehlversuche pro Link und Clientadresse
|
||||
- Gastseiten liefern genau eine positiv projizierte Sendung ohne interne IDs,
|
||||
Originaldaten oder nicht freigegebene Felder; geschützte Präsentationsmedien
|
||||
prüfen Umfang, Passwortsitzung, Ablauf und Widerruf bei jedem Direktaufruf
|
||||
- bestehende abgeschlossene Sendungen werden durch Migration `0015` mit
|
||||
eingefrorener Historie übernommen; Migration `0016` erweitert bestehende
|
||||
Freigaben verlustfrei auf noch nicht abgeschlossene Sendungen
|
||||
|
||||
Die lokale Prüfmatrix umfasst 52 Verhaltenstests und 18 Chromium-Abläufe.
|
||||
Abschluss, Archiv, historische Nur-Lese-Ansicht, Passwortfreigabe,
|
||||
Scope-Begrenzung, direkter Medienzugriff, fremde IDs, Gast-Schreibversuch und
|
||||
Widerruf wurden zusätzlich in einem anonymen Browserkontext geprüft. Der
|
||||
erweiterte Ablauf prüft außerdem offene Sendungen, aktuelle Planänderungen,
|
||||
Bearbeiten und Löschen in beiden Barkeeper-Oberflächen sowie Desktop- und
|
||||
Smartphone-Layout.
|
||||
|
||||
## Live-Regie und Sendungskalender 0.5.12
|
||||
|
||||
|
||||
Reference in new issue
Block a user