Regeln bearbeiten können + Bug: Speichern mit Feld "Empfänger" schlägt fehl #10

New issue

Closed

opened 2026-07-08 21:54:32 +00:00 by glow · 3 comments

glow commented

2026-07-08 21:54:32 +00:00

(Migrated from gitlab.fluffyplace.de)

Bug: Regel mit Feld "Empfänger" lässt sich nicht speichern

Ursache gefunden: Die rules.field-Spalte hat einen CHECK-Constraint, der beim Anlegen der Tabelle festgelegt wird. Vor dem Merge von #4 war das CHECK (field IN ('buchungstext', 'vorgang')) — merchant_name kam erst mit #4 dazu. SQLite kann CHECK-Constraints nicht per ALTER TABLE ändern, und die damalige Migration hat nur die neue Spalte merchant_name ergänzt (per ALTER TABLE ADD COLUMN), nicht aber den Constraint auf bereits existierenden Datenbanken repariert. Wer die App schon vor #4 laufen hatte, sitzt also auf einer Datenbank mit dem alten Constraint.

Reproduziert: POST /api/rules mit field: "merchant_name" auf einer solchen Datenbank wirft SqliteError: CHECK constraint failed, der Fehler wird nirgends abgefangen und crasht als unbehandelte Exception (hässliche Stacktrace-HTML-Seite statt sauberer Fehlermeldung).

Fix: Migration ergänzen, die bestehende rules-Tabellen mit altem Constraint per Table-Rebuild (SQLite-Standardverfahren für Constraint-Änderungen: neue Tabelle anlegen, Daten kopieren, alte löschen, umbenennen) auf den neuen Constraint hebt — ohne Datenverlust. Zusätzlich: Fehler in den Regel-Routen sauber abfangen statt crashen zu lassen.

Feature: Regeln bearbeiten

Aktuell lassen sich Regeln nur anlegen und löschen, nicht bearbeiten — wer eine Regel korrigieren will (Muster, Kategorie, Feld, Tag), muss sie löschen und neu anlegen.

Vorschlag: PATCH /api/rules/:id plus Bearbeiten-Button pro Regel in der UI, der das bestehende Formular mit den aktuellen Werten befüllt (analog zum "Neue Regel"-Formular, das schon da ist).

## Bug: Regel mit Feld "Empfänger" lässt sich nicht speichern **Ursache gefunden**: Die `rules.field`-Spalte hat einen `CHECK`-Constraint, der beim Anlegen der Tabelle festgelegt wird. Vor dem Merge von #4 war das `CHECK (field IN ('buchungstext', 'vorgang'))` — `merchant_name` kam erst mit #4 dazu. SQLite kann `CHECK`-Constraints nicht per `ALTER TABLE` ändern, und die damalige Migration hat nur die neue Spalte `merchant_name` ergänzt (per `ALTER TABLE ADD COLUMN`), nicht aber den Constraint auf bereits existierenden Datenbanken repariert. Wer die App schon vor #4 laufen hatte, sitzt also auf einer Datenbank mit dem alten Constraint. Reproduziert: `POST /api/rules` mit `field: "merchant_name"` auf einer solchen Datenbank wirft `SqliteError: CHECK constraint failed`, der Fehler wird nirgends abgefangen und crasht als unbehandelte Exception (hässliche Stacktrace-HTML-Seite statt sauberer Fehlermeldung). **Fix**: Migration ergänzen, die bestehende `rules`-Tabellen mit altem Constraint per Table-Rebuild (SQLite-Standardverfahren für Constraint-Änderungen: neue Tabelle anlegen, Daten kopieren, alte löschen, umbenennen) auf den neuen Constraint hebt — ohne Datenverlust. Zusätzlich: Fehler in den Regel-Routen sauber abfangen statt crashen zu lassen. ## Feature: Regeln bearbeiten Aktuell lassen sich Regeln nur anlegen und löschen, nicht bearbeiten — wer eine Regel korrigieren will (Muster, Kategorie, Feld, Tag), muss sie löschen und neu anlegen. **Vorschlag**: `PATCH /api/rules/:id` plus Bearbeiten-Button pro Regel in der UI, der das bestehende Formular mit den aktuellen Werten befüllt (analog zum "Neue Regel"-Formular, das schon da ist).

glow commented

2026-07-08 22:04:12 +00:00

(Migrated from gitlab.fluffyplace.de)

mentioned in commit faa7109d61

mentioned in commit faa7109d6195eb4dc3dcab0a8e451af400c41456

glow commented

2026-07-08 22:04:31 +00:00

(Migrated from gitlab.fluffyplace.de)

mentioned in merge request !14