Document frontend/backend publication trade-off

2026-06-07 22:32:48 +02:00
parent 809c30e5b5
commit 97a302a985
1 changed files with 10 additions and 0 deletions
@@ -40,6 +40,9 @@ Die Umfrage arbeitet mit drei relevanten Zuständen in `tl_survey`:
  - Keine Fragenbearbeitung nach Veröffentlichung
  - Keine Metadatenbearbeitung nach Veröffentlichung
  - Keine Fragenbearbeitung nach ersten Teilnahmen
 - Die Frontend-Sperre für veröffentlichte Umfragen soll bewusst nicht tief im System verankert sein.
  - Für Redakteure genügt das Ausblenden bzw. Deaktivieren der relevanten Buttons und Formulare im Frontend.
  - Es ist ausdrücklich keine zusätzliche harte Systembarriere gewünscht, solange die Redakteursoberfläche den Bearbeitungspfad sauber schließt.
 - Backend ist bewusst toleranter:
  - Ein einzelner Admin darf im Notfall weiter arbeiten
@@ -47,6 +50,13 @@ Die Umfrage arbeitet mit drei relevanten Zuständen in `tl_survey`:
  - `published` ist im Backend editierbar
  - `isActive` ist im Backend per Contao-Toggle schaltbar
 - Bewusster Trade-off zwischen Frontend und Backend:
  - Ein veröffentlichter Survey soll für Frontend-Redakteure praktisch nicht mehr bearbeitbar sein.
  - Im Backend darf der Admin trotz Veröffentlichung weiterhin Änderungen vornehmen, zum Beispiel für Rechtschreibfehler oder kleine Korrekturen.
  - Dadurch bleibt bewusst das Risiko bestehen, dass der Admin auch Fragen oder Strukturen ändert, obwohl bereits Antworten vorliegen.
  - Mögliche Folgen sind verwässerte oder fachlich falsche Ergebnisseiten sowie Inkonsistenzen, wenn bestehende Antworten nicht mehr sauber zur später geänderten Struktur passen.
  - Dieses Risiko wird bewusst akzeptiert und organisatorisch über Briefing/Disziplin des Admins bzw. der zuständigen Redakteure abgefangen, nicht über eine harte technische Sperre im Backend.
 Diese Entscheidung ist absichtlich so getroffen und kein Bug.
 ## Datenmodell und wichtige Tabellen