Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- elo:migration_elo_office_ngx [2026/01/25 15:27] – 84.20.184.166
+++ elo:migration_elo_office_ngx [2026/01/25 16:05] (aktuell) – [Dokumente] 84.20.184.166
@@ Zeile 13: / Zeile 13: @@
 ===== Durchführung einer Migration =====
-Bei Migrationen gibt es hier allen voran immer die Notwendigkeit die Migrationsschritte zu planen. Allzu schwer ist das im Normalfall nicht. Bei ELOoffice stellen sich hier folgende Themen:
+Bei Migrationen gibt es hier allen voran immer die Notwendigkeit die Migrationsschritte zu planen. Allzu schwer ist das im Normalfall nicht. Aufwändig ist es aber meist immer. Bei ELOoffice stellen sich hier folgende Themen:
 ==== Schema ====
   * Dokumentenmasken: die Migration geht hier einmal von einer Übernahme von Dokumentmasken nach dem Prinzip Verwendung hin zu einem Dokument aus. Sprich es wird die Objekte-Tabelle einmal gruppiert (objmask-Feld), die IDs der verwendenten Masken entnommen. Danach werden Dokumententypen in Paperless gleichnamig angelegt.
-  * Felder: hier ist das selbe Prinzip wie bei den Dokumentenmasken, verwendete Felder werden hier in Paperless als Custom-Felder angelegt.
+  * Felder: hier ist das selbe Prinzip wie bei den Dokumentenmasken, verwendete Felder werden hier in Paperless als Custom-Felder angelegt. Eine Binding Feld zu Dokumenttyp gibt es hier allerdings nicht. Somit geht diese Information damit verloren. Gleichwertig können aber in NGX auch Automatisierungen angelegt werden, die hier die Custom-Felder wieder "zuordnen" sobald ein neues Dokument von dem Typ im Storage auftaucht. Bei den Feldern muss man hier dazu sagen, dass hier gleichnamige Felder mit abweichendem Feldtyp zu einem Fehler führen.
+  * Benutzer: noch keine Behandlung vorgesehen, ließe sich aber ebenfalls mit einer Überführung in den Paperless NGX Benutzerstamm abdecken.
+==== Dokumente ====
+Da Paperless NGX ja keine Ordner unterstützt ist es hier notwendig Dokumente zu übernehmen. Ordnerstrukturen lassen sich ggf. wieder in Custom-Feldern abbilden (Haupt/Nebenkategorie, Ebene1/2/3 etc.). Dabei ist zu erwähnen:
+  * verschlüsselte Dokumente müssen vorher über den ELO-Export exportiert werden
+    * die Export-Pfade müssen der Routine bekannt gegeben werden
+  * die Datenverzeichnisse müssen für die Migrationsroutine zugänglich sein
+    * diese müssen der Export-Routine ebenfalls zur Verfügung gestellt werden
+  * NGX unterstützt per Default nur Dateitypen für die auch ein Consumer/Parser hinterlegt ist
+  * NGX macht mit aktiviertem Tika eine Prüfung des Contents. Sprich liegt hinter einem PDF Dokument bspw. eine Text-Datei, dann wird diese wahrscheinlich auch als Text-Datei gewertet und als solche geparst und abgelegt. Liegt hier ein JSON-String dahinter, dann wertet Tika dies als JSON-Datei, dafür gibt es keinen Handler und es führt nach erfolgreichem Upload in NGX zu einem Verarbeitungsfehler.
+Wie verfährt die Migrationsroutine mit den Dokumenten: rein generell werden hier die Dokumentenpfade einmal auf Dateien durchforstet, die nicht mit der Endung ESW (Verschlagwortungsdatei) enden. Hier wird jede Dokumentdatei auf einen Hex-Wert überprüft und es wird versucht diesen Hex-Wert in eine Zahl zu bringen (ELO-Dokumenten-ID).