4 Commits

Include renames

Author	SHA1	Message	Date
adminandClaude Sonnet 5	b8193be6ec	fix: Untis-Hub-Status ueber Geraete hinweg synchronisieren ... UntisHubJobState (Faelligkeits-Zeitstempel des Untis-Hubs) lief bisher ausserhalb des Sync - jedes Geraet fuehrte seine eigene Buchhaltung, wodurch auf allen Instanzen dieselben Punkte offen blieben und ein bereits erledigter Abgleich anderswo erneut WebUntis-Traffic ausgeloest haette (Nutzer-Feedback). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-13 22:24:03 +02:00
adminandClaude Sonnet 5	038337997f	feat: Anhänge je Stunde, Klausur-Sitzplan mischen, Gefährdungsbeurteilungs-Assistent ... Lesson bekommt dieselbe Anhang-Infrastruktur wie Documentation (Material, Arbeitsblätter, Experimentunterlagen), samt Fix einer Sync-Lücke, die Anhang- Dateibytes bisher nur für Documentation statt generisch übertragen hat (IHasAttachments). Sitzplan-Tab bekommt einen "Plätze mischen"-Button für Klausursitzpläne. Neu: mehrschrittiger Gefährdungsbeurteilungs-Assistent mit optionalem KI-Entwurf (ai-backend/gbu.php) und PDF-Export, Format bewusst als JSON-Anhang statt eigener Datenbank-Entität. Details und Architekturentscheidungen in TODO.md (4.2, 7.1.5, 10.1.8). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 17:13:14 +02:00
adminandClaude Sonnet 5	f0f8fa25e5	Baustein 6: Datei-Anhaenge synchronisieren (Kapitel 10) ... Anhaenge laufen bewusst NICHT ueber den JSON-Ereigniskanal (wuerde ihn fuer Fotos/Scans stark aufblaehen), sondern ueber einen eigenen verschluesselten Binaerkanal - analog zum bereits bestehenden Muster in SnapshotService. - Neue Endpunkte POST/GET /api/sync/attachments/{storageId} in LehrerApp.Api (AttachmentStore, dateibasiert je Nutzer) - EventQueue: neue, vom JSON-Ereignis getrennte Warteliste fuer ausstehende Uploads (SyncEventPublisher traegt Anhaenge einer gespeicherten Documentation dort ein) - AttachmentSyncer laedt ausstehende Anhaenge hoch (in SyncEngine.SyncNowAsync nach dem Event-Push) - EventApplier laedt fehlende Anhaenge nach dem Anwenden eines Documentation-Ereignisses nach - ueber die rohe Collection statt IAttachmentStorage.Upload, da dieses immer eine neue Id vergaebe und hier die Original-StorageId erhalten bleiben muss Round-Trip-Tests belegen byteidentische Uebertragung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-17 11:30:04 +02:00
adminandClaude Sonnet 5	ce4dfb0197	Baustein 5: EventApplier (Inbound Apply) + Loop-Prevention (Kapitel 10) ... Die zentrale, bisher komplett fehlende Luecke: selbst mit Baustein 1-4 haette SyncEngine.PullAsync empfangene Ereignisse nur zur Konflikterkennung genutzt, nie in die lokale LiteDB geschrieben - ankommende Aenderungen von anderen Geraeten waeren nirgends sichtbar geworden. Neu EventApplier: entschluesselt, dispatcht ueber eine explizite EntityType-Tabelle, schreibt IMMER direkt auf die rohe LiteDB- Collection, nie ueber eine Repository-Save/Delete-Methode - sonst wuerde der OnChange-Hook (Baustein 2) die gerade angewendete Aenderung als neues ausgehendes Ereignis re-enqueuen (Sync-Ping-Pong). Ein gemeinsames Suppress-Flag wurde geprueft und verworfen: SyncEngine laeuft per Timer nebenlaeufig zum UI-Thread, ein Flag koennte einen echten Nutzer-Save waehrenddessen verschlucken. Der direkte Collection- Zugriff ist zustandslos und dadurch korrekt. Kaskaden-Faelle nutzen dieselben internen LiteDbContext-Hilfsmethoden wie die Repositories (Baustein 4). Neu SyncEventPublisher, der den OnChange-Hook in ein verschluesseltes EventQueue.Enqueue uebersetzt (an LiteDbContext.OnChange gehaengt). Mit dediziertem Loop-Prevention-Test abgesichert: belegt mit echtem LiteDbContext + OnChange-Zaehler, dass Apply keinen neuen Hook-Aufruf ausloest. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-17 11:27:12 +02:00