Initialer Import des AssetManagers

2026-08-02 21:28:50 +00:00
commit ed72ce8821
256 changed files with 26361 additions and 0 deletions
@@ -0,0 +1,35 @@
+AssetManager v0.3.8.3 – dynamische MeshCentral-Feldsynchronisierung
+===================================================================
+
+Korrekturen:
+- Feste SYNC_FIELDS-Liste vollständig entfernt.
+- Ausschließlich aktivierte Einträge aus mesh_field_mappings bestimmen die Synchronisierung.
+- Systemfelder werden dynamisch über field_definitions und die Asset-Spalten geschrieben.
+- Custom-Felder werden dynamisch in asset_field_values gespeichert.
+- Neue Mappings auf bestehende System- oder Custom-Felder funktionieren ohne Codeänderung.
+- Update-Regeln fill_empty, meshcentral_wins und local_wins gelten für beide Feldarten.
+- Pro tatsächlich angewendetem Mapping erscheint eine Debug-Zeile im Live-Protokoll.
+- Unbekannte/inaktive Zielfelder und fehlende Systemspalten werden verständlich protokolliert.
+- mesh_mtype wurde im ORM-Modell ergänzt; die vorhandene Migration bleibt kompatibel.
+- Neue Assets werden vor dem Schreiben von Custom-Feldern geflusht, damit asset_id korrekt gesetzt ist.
+
+Installation:
+1. Datenbank sichern.
+2. ZIP im bestehenden AssetManager-Verzeichnis entpacken.
+3. Vorhandene .env, config.json, Daten, Uploads und Logs nicht ersetzen.
+4. docker compose down
+5. docker compose up -d --build
+6. docker compose logs --tail=200 app
+
+Prüfung:
+- Auf der MeshCentral-Seite nur die gewünschten Mapping-Regeln aktivieren.
+- Für Teständerungen Update-Regel "MeshCentral gewinnt" verwenden.
+- Im Live-Protokoll nach "Mapping '<feld>' angewendet" suchen.
+
+Getestet:
+- Python-Syntax aller App-Module.
+- Isolierter SQLite-Lauf mit einem Systemfeld (notes), mesh_mtype und einem Custom-Feld.
+- Derselbe RAM-Quellpfad wurde erfolgreich gleichzeitig in notes und in ein Custom-Feld geschrieben.
+
+Nicht durchgeführt:
+- Kein Produktivtest gegen die reale PostgreSQL-/MeshCentral-Installation des Anwenders.