3 Commits

Include renames

Author	SHA1	Message	Date
bjoernpoettkerandClaude Opus 5	b7b65c64ae	fix: Berechtigungen der Tagesübersicht, WebDAV-Ausbau, Tests instand gesetzt ... Die tägliche E-Mail-Zusammenfassung zeigte Nutzern Bereiche, für die sie keine Berechtigung haben. Zwei unabhängige Ursachen: - Das Backend prüfte weiterhin die Altgruppe PM_Belege. Die Umbenennung zu PM_Buchhaltung (ca1d371) war nur im Frontend angekommen, weshalb der Digest "Manuell bearbeiten" und "In Agrarmonitor" anbot, während die Oberfläche beide Bereiche sperrte. - Der Cron-Versand wertet die Gruppen aus user_settings aus. Diese Spalte wurde nur beim Aufruf der Benutzereinstellungen gefüllt; entzogene Berechtigungen erreichten den Digest daher unter Umständen nie. Behoben durch Angleichen des Gruppen-Mappings und den neuen UserIdentitySyncService, der E-Mail, Benutzername und Gruppen bei jedem authentifizierten Request aus dem Token spiegelt – ohne den Request zu blockieren und ohne DB-Zugriff, solange sich das Token nicht ändert. Die doppelte Identitätspflege im UserSettingsService entfällt. WebDAV wird nicht eingesetzt und ist entfernt; Export-Ziele bieten nur noch FTP. Damit verschwindet das ESM-Paket webdav, an dem zwei Jest-Suites bereits beim Parsen scheiterten. Veraltete Tests instand gesetzt: email.controller und settings.controller mockten weniger Abhängigkeiten, als die Klassen inzwischen haben; postprocessing.service.spec beschrieb noch das alte Regelmodell mit Einzelfeldern statt FilterJson und ist gegen die heutige Filter-Engine neu geschrieben (AND/OR, verschachtelte Gruppen, Fehlerprotokollierung). Enthält außerdem den Arbeitsstand der E-Rechnungs-Mandantenzuordnung, da sich beide Änderungen dieselben Dateien teilen (SettingsPage, package.json). 98 Tests in 12 Suites grün, Backend- und Frontend-Build sauber. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 00:06:50 +02:00
bjoernpoettkerandClaude Opus 4.8	9718d6888a	feat: Webhook-Warteschlange in Datenbank persistieren ... Die Warteschlange liegt nicht mehr im Speicher, sondern in der neuen Tabelle webhook_queue (Entity WebhookQueueItem, documentId als Primärschlüssel). So überstehen ausstehende IDs einen Neustart und werden nach dem Boot weiterverarbeitet. - Neue Entity + Migration (CreateWebhookQueue); in data-source.ts/Barrel registriert. Dev: synchronize legt die Tabelle an; Prod: migrationsRun. - enqueue nutzt INSERT IGNORE (atomar, race-sicher) -> Dedup über den PK. - processQueue holt FIFO (createdAt ASC), entfernt die Zeile vor der Verarbeitung, arbeitet sequenziell (isProcessing-Guard). - getStatus/queueSize lesen die DB-Anzahl. Controller awaitet enqueue. - Unit-Test mit simuliertem FIFO-Repo: Dedup, Remove-on-start, Re-Enqueue, No-Parallel (deterministisch). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-29 17:54:16 +02:00
bjoernpoettkerandClaude Opus 4.8	41eed1871e	fix: Produktions-Crash durch TypeORM-synchronize beheben ... NODE_ENV=production deaktiviert synchronize (zerstörerischer ADD/DROP-COLUMN- Churn auf MariaDB, der die 8126-Byte-Zeilengröße sprengte) und aktiviert migrationsRun. Neue data-source.ts als einzige Konfigquelle (Laufzeit + CLI), Migrations-Workflow (generate/run/revert) inkl. dotenv ergänzt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-18 09:27:04 +02:00