Antragsideen bearbeiten und aktualisieren #2

New Issue

tobias · 2026-03-31T00:04:11+02:00

tobias commented

2026-03-31 00:04:11 +02:00

Beschreibung

Bestehende Antragsideen sollen über die Web-Oberfläche bearbeitet werden können. Der typische Workflow: Eine Idee startet als Stichwort im Ideenspeicher, wird recherchiert, bekommt ein Dossier, wird zum Antragsentwurf ausformuliert — und durchläuft dabei mehrere Status-Stufen.

Anforderungen

Inline-Editing vs. Edit-Formular

Alle Felder aus Issue #1 müssen editierbar sein
Status-Änderungen sollten besonders einfach sein (ein Klick?)
aktualisiert_am automatisch setzen bei jeder Änderung

Status-Workflow

Der Status-Übergang ist der Kern des Workflows:

Ideenspeicher → Recherche → Entwurf → Eingereicht → Beschlossen/Abgelehnt → Abgeschlossen

Änderungshistorie

Soll nachvollziehbar sein, wann was geändert wurde?
Reicht "zuletzt geändert am" oder braucht es ein vollständiges Änderungslog?

Offene Fragen

Edit-Modus: Eigene Edit-Seite, Modal mit Formular, oder direkt Inline-Editing in der Detailansicht (Felder anklicken → editierbar)?
Gleichzeitiges Bearbeiten: Kann es passieren, dass mehrere Personen gleichzeitig am gleichen Eintrag arbeiten? Falls ja: Optimistic Locking ("Eintrag wurde zwischenzeitlich geändert") nötig?
Dossier-Workflow: Das Dossier ist oft der umfangreichste Teil. Soll es einen separaten "Dossier bearbeiten"-Modus geben mit größerem Editor-Fenster + Live-Preview?
Löschen: Sollen Einträge löschbar sein? Soft-Delete (Papierkorb) oder Hard-Delete? Oder reicht Status "Abgeschlossen" als De-facto-Archivierung?
Bulk-Operationen: Braucht es die Möglichkeit, mehrere Einträge gleichzeitig zu bearbeiten (z.B. alle "Recherche"-Items auf "Entwurf" setzen)?
Auto-Save: Soll bei langen Texten (Dossier, Antragstext) automatisch zwischengespeichert werden, oder nur explizit per "Speichern"-Button?

Technische Umsetzung

Backend: PUT/PATCH /api/antraege/:id Endpoint
Frontend: Edit-UI (abhängig von Antwort auf Frage 1)
DB: UPDATE auf antraege Tabelle + aktualisiert_am setzen
Optional: antraege_history Tabelle für Änderungslog

Abhängigkeiten

Setzt auf Issue #1 auf (gleiche Formular-Komponenten wiederverwendbar)

## Beschreibung Bestehende Antragsideen sollen über die Web-Oberfläche bearbeitet werden können. Der typische Workflow: Eine Idee startet als Stichwort im Ideenspeicher, wird recherchiert, bekommt ein Dossier, wird zum Antragsentwurf ausformuliert — und durchläuft dabei mehrere Status-Stufen. ## Anforderungen ### Inline-Editing vs. Edit-Formular - Alle Felder aus Issue #1 müssen editierbar sein - Status-Änderungen sollten besonders einfach sein (ein Klick?) - `aktualisiert_am` automatisch setzen bei jeder Änderung ### Status-Workflow Der Status-Übergang ist der Kern des Workflows: ``` Ideenspeicher → Recherche → Entwurf → Eingereicht → Beschlossen/Abgelehnt → Abgeschlossen ``` ### Änderungshistorie - Soll nachvollziehbar sein, wann was geändert wurde? - Reicht "zuletzt geändert am" oder braucht es ein vollständiges Änderungslog? ## Offene Fragen 1. **Edit-Modus:** Eigene Edit-Seite, Modal mit Formular, oder direkt Inline-Editing in der Detailansicht (Felder anklicken → editierbar)? 2. **Gleichzeitiges Bearbeiten:** Kann es passieren, dass mehrere Personen gleichzeitig am gleichen Eintrag arbeiten? Falls ja: Optimistic Locking ("Eintrag wurde zwischenzeitlich geändert") nötig? 3. **Dossier-Workflow:** Das Dossier ist oft der umfangreichste Teil. Soll es einen separaten "Dossier bearbeiten"-Modus geben mit größerem Editor-Fenster + Live-Preview? 4. **Löschen:** Sollen Einträge löschbar sein? Soft-Delete (Papierkorb) oder Hard-Delete? Oder reicht Status "Abgeschlossen" als De-facto-Archivierung? 5. **Bulk-Operationen:** Braucht es die Möglichkeit, mehrere Einträge gleichzeitig zu bearbeiten (z.B. alle "Recherche"-Items auf "Entwurf" setzen)? 6. **Auto-Save:** Soll bei langen Texten (Dossier, Antragstext) automatisch zwischengespeichert werden, oder nur explizit per "Speichern"-Button? ## Technische Umsetzung - Backend: PUT/PATCH `/api/antraege/:id` Endpoint - Frontend: Edit-UI (abhängig von Antwort auf Frage 1) - DB: UPDATE auf `antraege` Tabelle + `aktualisiert_am` setzen - Optional: `antraege_history` Tabelle für Änderungslog ## Abhängigkeiten - Setzt auf Issue #1 auf (gleiche Formular-Komponenten wiederverwendbar)

tobias commented

2026-03-31 00:10:38 +02:00

Entscheidungen (Tobias, 31.03.2026)

Edit-Modus

Noch offen — Optionen:

Inline-Editing für kurze Felder (Titel, Status, Priorität) + dedizierter Editor für lange Texte (Dossier, Antragstext)
Tobias schaut sich das Konzept an

Änderungshistorie

Vollständiges Log — Wer hat wann was geändert. Braucht antraege_history Tabelle.

Löschen

Soft-Delete — Papierkorb-Logik. geloescht_am Timestamp, aus normaler Ansicht ausgeblendet, wiederherstellbar.

Auto-Save

Ja — Automatisches Zwischenspeichern bei langen Texten (Dossier, Antragstext). Debounced, z.B. 3 Sekunden nach letztem Tastendruck.

## Entscheidungen (Tobias, 31.03.2026) ### Edit-Modus **Noch offen** — Optionen: - **Inline-Editing** für kurze Felder (Titel, Status, Priorität) + dedizierter Editor für lange Texte (Dossier, Antragstext) - Tobias schaut sich das Konzept an ### Änderungshistorie **Vollständiges Log** — Wer hat wann was geändert. Braucht `antraege_history` Tabelle. ### Löschen **Soft-Delete** — Papierkorb-Logik. `geloescht_am` Timestamp, aus normaler Ansicht ausgeblendet, wiederherstellbar. ### Auto-Save **Ja** — Automatisches Zwischenspeichern bei langen Texten (Dossier, Antragstext). Debounced, z.B. 3 Sekunden nach letztem Tastendruck.

tobias commented

2026-03-31 00:13:44 +02:00

Edit-Modus — Entschieden

Inline-Editing für kurze Felder (Titel, Status, Priorität, Bereich, Ausschüsse, Personen) + Split-Editor für lange Texte (Dossier, Antragstext): Links Markdown-Eingabe, rechts Live-Preview.

### Edit-Modus — Entschieden **Inline-Editing** für kurze Felder (Titel, Status, Priorität, Bereich, Ausschüsse, Personen) + **Split-Editor** für lange Texte (Dossier, Antragstext): Links Markdown-Eingabe, rechts Live-Preview.

tobias added the

backend

feature

frontend

labels 2026-03-31 00:28:32 +02:00

tobias commented

2026-03-31 00:29:24 +02:00

Abhängigkeiten

#4 Migrationssystem — brauchen wir für Schema-Änderungen
#5 Änderungshistorie — wird beim Editieren mitgeschrieben
#6 Soft-Delete — Löschen-Button im Edit-Modus

Empfohlene Reihenfolge

#4 Migrationssystem (Infrastruktur)
#5 + #6 (Schema-Erweiterungen)
#2 Editieren (nutzt alles)
#3 SSO (unabhängig, kann parallel)

## Abhängigkeiten - **#4** Migrationssystem — brauchen wir für Schema-Änderungen - **#5** Änderungshistorie — wird beim Editieren mitgeschrieben - **#6** Soft-Delete — Löschen-Button im Edit-Modus ### Empfohlene Reihenfolge 1. #4 Migrationssystem (Infrastruktur) 2. #5 + #6 (Schema-Erweiterungen) 3. #2 Editieren (nutzt alles) 4. #3 SSO (unabhängig, kann parallel)

Sign in to join this conversation.