Migrationsanleitung auf Kitodo.Production 3.x der UB Braunschweig

Migration von Kitodo.Production 2.x auf Kitodo.Production 3.X

Die Migration besteht im Wesentlichen aus den Schritten: Vorbereitung, Durchführung, Nachbereitung. Für die Migration an der UBBS wurden u.a. die Aktualisierungshinweise auf GitHub (konkret Kitodo 3.x) verwendet. Zu erwähnen sei hier allerdings, das die Aktualisierungshinweise auf GitHub mittlerweile nicht mehr ganz aktuell sind (Stand 2022.04.30). Daraus folgt für die Migration hier, dass Anleitungsschritte zur Vor- und Nachbereitung der Datenbankintegrität (seien es SQL-Skripte oder direkte Datenbankmanipulationen) obsolet sind und im bereitgestellten Migrations-Skript migration_3-3.sql aufgenommen wurden. (Das Erstellen von min. einem benutzerdefinierten Filter muss jedoch weiter durchgeführt werden: Siehe Migration → Vorbereitung → Datenvorbereitung → Punkt 2.)

Übersicht

• Vorbereitung
  • Datenvorbereitung
  • Datensicherung
  • Regelsatz konvertieren und anpassen
• Durchführung
  • Server Upgrade
  • Datenbank Konvertierung
  • Kitodo Software Installation
  • Anpassen der Nutzerrechte
  • Metadaten Konvertierung und Projekt Indexierung
  • Erstellen der Workflows

Vorbereitung

Die Vorbereitung dient der Datenvorbereitung sowie der Prüfung und Sicherung der (Meta-)Daten und Systemeinstellungen, um einen möglichst reibungslosen Übergang zu ermöglichen. Eine zusätzliche Möglichkeit bietet das Klonen des Produktivsystems um auch nach erfolgreicher Migration für eine begrenzte Zeit Einsicht auf die alten Vorgänge mit dem Vorgängersystem nehmen zu können. Dabei gilt es jedoch zu vermeiden, dass das geklonte System noch immer auf die Daten des (neuen) Produktivsystems zugreift. Wie bereits erwähnt, sollten vor der Datensicherung bestimmte Voraussetzungen geprüft bzw. hergestellt werden. Zu den Details:

Datenvorbereitung

• Aus dem Migrationsworkshop, der in Braunschweig im Juni 2020 stattgefunden hat (s.a. Video): "Die Migration setzt voraus, dass es auf dem System keine Vorgänge mehr im Internformat “XStream” gibt. Sollte das noch der Fall sein, muss mit Version 2 das Internformat (in der Projekteinstellungen) geändert und die Metadatendateien mit dem GoobiScript-Befehl action:rewriteProcessMetadata migriert werden. Der GoobiScript-Befehl steht ab Version 2.3 zur Verfügung. Bei einer älteren Version besteht nur die Möglichkeit, alle betroffenen Vorgänge einzeln im Metadaten-Editor zu öffnen und neu abzuspeichern.
• "Mindestens ein Benutzer muss mindestens einen benutzerdefinierten Filter gespeichert haben, damit hernach die Datenbankmigration durchgeführt werden kann." D.h.: "In der Datenbank nachschauen, ob die Tabelle benutzereigenschaften nicht leer ist." indem man den SQL-Befehl select count(*) from benutzereigenschaften; verwendet und prüft ob eine Zahl ≠ 0 angezeigt wird. "Falls es 0 ist, unter den Vorgängen rechts oben unter Filter: etwas eingeben und auf Filter hinzufügen (Diskettensymbol) klicken"
• Bei der Anwendung des Scripts migration_3-3.sql zum Konvertieren der Datenbank (siehe: Migration → Durchführung → Datenbank-Konvertierung) werden konkrete Nutzereinträge zu einzelnen Aufgaben eines Vorgangs nicht mit übernommen, Rollen aber schon. D.h., jede Aufgabe eines jeden Vorgangs sollte mindestens eine Rolle (nicht nur einem Nutzer) zugeschrieben werden. Das Identifizieren aller Aufgaben, die nur (einen) Nutzer, aber keine Rolle zugeordnet bekommen haben, kann bspw. mit folgender SQL-Anfrage umgesetzt werden (evtl. goobi zu kitodo anpassen):

select UserID, login, SchrittID, SchrittTitel, BearbStat, ProzID, ProzTitel, ProjID, goobi.projekte.Titel as ProjTitel 
from goobi.projekte 
join (
		select UserID, login, SchrittID, SchrittTitel, BearbStat, ProzID, goobi.prozesse.Titel as ProzTitel, goobi.prozesse.ProjekteID as ProjID
		from goobi.prozesse 
		join (
				select UserID, login, goobi.schritte.schritteID as SchrittID, Titel as SchrittTitel, Bearbeitungsstatus as BearbStat, ProzesseID as ProzID 
				from goobi.schritte 
				join (
						select goobi.benutzer.BenutzerID as UserID, login, schritteID
						from goobi.benutzer
						join (
								select schritteID, BenutzerID
								from goobi.schritteberechtigtebenutzer 
								where schritteID not in (select schritteID from goobi.schritteberechtigtegruppen)
							)
							as res0
							on
						goobi.benutzer.benutzerID=res0.BenutzerID
					) 
					as res1 
					on 
				goobi.schritte.schritteID=res1.schritteID
			) 
			as res2 
			on 
		goobi.prozesse.ProzesseID=res2.ProzID
	)
	as res3 
	on 
goobi.projekte.ProjekteID=res3.ProjID;

• Bei der Erzeugung von übergeordneten Vorgängen (siehe Migration → Durchführung → Serielle Publikationen migrieren) verwendet Kitodo 3.X die PPNs der Vorgänge. D.h., es sollte sichergestellt werden, dass diese in den Meta-Daten der Mehrbändigkeiten eindeutig und unverändert aufzufinden sind. Bspw. würde das Verwenden von [PPN]_[Jahr] dazu führen, dass für jeden Zeitschriftenvorgang eines Jahres ein separater, übergeordneter Vorgang (und damit zu viele dieser Vorgänge) erzeugt wird.
• Es Empfiehlt sich, einen dedizierten Migrations-Admin-Nutzer anzulegen (und ins LDAP zu schreiben), der unmittelbar nach Installation von Kitodo 3.X mit den zusätzlichen Rollen 11 bis 20 ausgestattet wird.
• Ein weiterer möglicher Schritt zur Datenvorbereitung besteht in der vorzeitigen Erstellung von zu migrierenden Workflows. Diese Aufgabe ist anspruchsvoll und kann die reine Durchführung der Migration dehnen. Details zur Lösung im Fall UBBS können unter Migration → Durchführung → Erstellen der Workflows gefunden werden.

Datensicherung

Kitodo (K2.X und K3.X) arbeitet im Wesentlichen auf und mit (1.) den Daten der Datenbank kitodo (vor der Migration ggf. namens goobi) und (2.) dem Verzeichnis metadaten.

Die Datenbank kitodo (bzw. goobi)

Die Datenbank beinhaltet neben den Nutzerdaten ausschließlich organisatorische und administrative Daten für die Verwaltung der einzelnen Digitalisate (d.h., zu deren Projekte, die Vorgänge selbst, deren Aufgaben, etc.). Rechts ein Vergleich der Tabellen der Datenbank aus K2.X und K3.X. Zur Sicherung reicht hier ein einfaches "dump" aus:

mysqldump -u root -p -R goobi > goobi_backup.sql

ℹ️ Bei der Migration kann das Script migration_3-3.sql zum konvertieren der Datenbank unabhängig vom Namen (kitodo oder goobi) angewendet werden.

Das Verzeichnis metadaten

Die Metadaten (Verzeichnis /usr/local/<goobi/kitodo>/metadaten) sind in Form einer flachen Orderstruktur angelegt, bei der für jeden einzelnen Vorgang ein Ordner (mit Vorgangs-ID als Name) von Kitodo erzeugt wird. Jeder Ordner enthält jeweils eine meta.xml (+ggf. Hilfsdateien) und die gescannten Bilder (in Unterordnern). Die einzelnen Ordner in metadaten beinhalten alle Meta-Daten für das jeweilige Digitalisat (ab K3.X) in einem internen METS-ähnlichen Kitodo-Format (Datei meta.xml).

ℹ️ Aus der meta.xml wird unter Verwendung der Bilddaten beim Abschließen der Digitalisierung durch den Export eine METS-konforme Datei [Vorgangs-ID]_mets.xml im Home Verzeichnis des jeweiligen Nutzers generiert, die anschießend für die Publikation des Werkes verwendet wird.

Zur Sicherung der Metadaten reicht hier ein einfaches Kopieren (z.B. via rsync) aus.

Weitere Sicherungen

Bei Bedarf kann selbstverständlich auch das ganze Hauptverzeichnis /usr/local/goobi/ bzw. /usr/local/kitodo/ und die deployte Webapp (normalerweise unter /var/lib/tomcat<7/8>/webapps/kitodo<X>/) gesichert werden.

Regelsatz konvertieren und anpassen

Regelsätze müssen für K3.X neu erstellt bzw. angepasst werden. Die UBBS verfolgt dabei eine Strategie, bei der der (eine) alte Regelsatz aus K2.X NUR FÜR DIE MIGRATION mittels Regelsatzkonverter (bereitgestellt von der Firma Zeutschel GmbH) zunächst konvertiert, dann vereinheitlicht und letztendlich angepasst wurde um diesen dann zum Konvertieren der Vorgangs-Metadaten (meta.xml) des alten Produktivsystems zu verwenden. Um die neuen K3.X Features ausschöpfend nutzen zu können, wurde für die Bearbeitung alter, bereits migrierter aber auch das Anlegen neuer Vorgänge NACH DER MIGRATION ein neuer Regelsatz erstellt. Zu den Details:

• Der Regelsatzkonverter benötigt die folgenden Dateien (aus dem K2.X Produktivsystem):
  • ruleset.xml
  • goobi_digitalCollections.xml
  • goobi_metadataDisplayRules.xml
  • goobi_opac.xml
  • goobi_processProperties.xml
  • goobi_projects.xml
• Der Regelsatzkonverter erzeugt dabei mehrere "Vorschlags"-Regelsätze, die sich (im Fall UBBS) im Wesentlichen nur in den "Digital Collections" unterschieden und daher zu einer Datei ruleset.xml zusammengefasst werden konnten.
• Weiterhin wurden division, die ggf. in nur einem der "Vorschlags"-Regelsätze vorhanden waren, ebenfalls mit einbezogen, um einen kompletten Regelsatz mit dem Namen ruleset.xml für die Migration zu haben.
• Für die Generierung von übergeordneten Vorgängen ist es ratsam, die Zuweisung von Workflows zu unterbinden. Weiterhin kann der generierte Vorgangstitel für übergeordneten Vorgänge (aber auch allen anderen divisions) spezifiziert werden. Beides geschieht mit: processTitle="TSL_ATS+'_'+CatalogIDDigital" withWorkflow="false" in der Definition der jeweiligen division; CatalogIDDigital bezeichnet hierbei die PPN
• Zur Erstellung und Anpassung von K3.X konformen Regelsätzen kann und sollte die Datei Regelsatz-Beschreibung final.docx(LINK!!) genutzt werden.

Durchführung

Die Durchführung der Migration besteht aus den Punkten:

1. Server Upgrade
2. Datenbank Konvertierung
3. Kitodo Software Installation
4. Anpassung der Nutzerrechte
5. Meta-Daten Konvertierung und Projekt Indexierung
6. Erstellung der Workflows
7. Serielle Publikationen migrieren
8. Extrabehandlung von Zeitungsvorgängen (Nicht an UBBS nötig)

Server Upgrade

Als erster Schritt der Migration sollte der Server auf den "aktuellen" Stand gebracht werden. An der UBBS wurde dafür der Kitodo-Server mit Ubuntu 16.04 LTS auf ein Ubuntu 18.04 LTS aktualisiert:

sudo apt-get update, sudo apt-get upgrade, do-release-upgrade

, ggf. purge-old-kernel wenn für das Betriebssystemupgrade mehr Speicherplatz benötigt wird.

Dabei wird das Ersetzen/Beibehalten/Neuanlegen folgender Dateien erfragt:

• /etc/vim/vimrc
• /etc/default/snmpd
• /etc/ntp.conf
• /etc/apt/apt.conf.d/unattacheduppgrades (für upgrades) → ersetzt
• /etc/tomcat8/tomcat-users.xml (nur in VM, in Test-System wird Tomcat 7 duch Tomcat 8 ersetzt) → (ggf. 1 Anpassung nachträglich wenn manager-gui gewünscht)
• /etc/mysql/mysql.conf.d/mysqld.cnf (nur in VM) → ersetzt (1 Anpassung nachträglich: prüfe mysql> show variables like 'innodb_file_per_table'; ggf. setzen der Variable innodb_file_per_table)

Das Ersetzen der Dateien scheint problemlos zu funktionieren und ist ratsam für ein integeres System nach der Migration. Ein vorheriges Sichern der jeweiligen Dateien im Fall von nachträglich notwendigen Anpassungen wird jedoch empfohlen.

ℹ️ Nach dem Server Upgrade kann Kitodo 2.X bei Bedarf erneut gestartet werden. Dafür ist ggf. eine Anpassung an der /var/lib/tomcat<7/8>/webapps/kitodo<2.X>/WEB-INF/classes/hibernate.cfg.xml notwendig

jdbc:mysql://localhost/goobi?useSSL=false&serverTimezone=UTC

Anschließend /etc/init.d/tomcat<7/8> restart nicht vergessen.

Datenbank Konvertierung

• Webapp, d.h. Tomcat ggf. stoppen: /etc/init.d/tomcat<X> stop
• Ggf. erneutes Backup der Datenbank: mysqldump -u root -p -R goobi > goobi_backup.sql
• Neue Datenbank mit Name kitodo erstellen: create database kitodo;
• Neuen kitodo Nutzer erstelen und Rechte geben: create user 'kitodo'@'localhost' identified by 'kitodo'; grant all on kitodo.* to 'kitodo'@'localhost';
• Struktur (d.h. "alte" Datenbank) von goobi einlesen: mysql -u root -p kitodo < goobi_backup.sql
• Datenbank migrieren: mysql -u root -p kitodo < migration_3-3.sql;
• Ggf. Nachfolge-Script (für Zwischen-Release) anwenden: mysql -u root -p kitodo < diff.sql;
• Ggf. erneutes Backup der Datenbank: mysqldump -u root -p -R kitodo > kitodo_migrated_backup.sql

Kitodo Software Installation

Kitodo 2.X geht von einem Programmverzeichnis /usr/local/goobi/ aus, Kitodo 3.X verwendet /usr/local/kitodo/. Da sich die Inhalte der beiden Hauptverzeichnisse auf Ordner-Ebene nur geringfügig unterscheiden, kann somit (1.) auf das Neuanlegen des Hauptverzeichnisses bei der Migration verzichtet werden und (2.) ein einfaches Kopieren cp -r /usr/local/goobi/ /usr/local/kitodo/ ausgeführt werden, welches das ursprüngliche Hauptverzeichnisses gleichzeitig als Backup zurückbehält.

Mit dem neuen (kopierten) Hauptverzeichnis /usr/local/kitodo/ wird nun wie folgt verfahren:

• Tomcat als Owner des Hauptverzeichnis setzen: chown -R tomcatX:tomcatX /usr/local/kitodo/ (Wenn tomcat7 im Rahmen des Server Upgrades deinstalliert wurde, sollte hier die gleiche Owner-Number wie in /usr/local/goobi/` verwendet werden, z.B: 107:115)
• Ggf. tomcat8 installieren und testen
• Ordner diagrams und modules erstellen und Rechte/Owner zuweisen: mkdir /usr/local/kitodo/diagrams; mkdir /usr/local/kitodo/modules; chown tomcat8:tomcant8 /usr/local/kitodo/diagrams
  • in diagrams die beiden Beispieldateien Example_Workflow.bpmn20.xml und Example_Workflow.svg kopieren
  • in modules die mitgelieferten Module kopieren: modules.zip
• Ordner config umbenennen (als Backup behalten) und in neuen Ordner config die Dateien kopieren: config.zip
• Ordner ruleset umbenennen (als Backup behalten) und in neuen Ordner ruleset die Dateien kopieren: rulesets.zip
• Ordner scripts umbenennen (als Backup behalten) und in neuen Ordner scripts die Dateien kopieren: scripts.zip
• Ordner xslt umbenennen (als Backup behalten) und in neuen Ordner xslt die Dateien kopieren: xslt.zip

Analog zur Installation eines neuen Kitodo 3.X sollte die Installation folgender Programme geprüft und ggf. nachgeholt werden:

• tomcat8

• mysql

• imagemagic

• slapd

• ldap-utils

• samba

• apt-transport-https

• unzip

• dos2unix

• Elastic Seach installieren: Folge der Installationsanleitung auf GitHub (Schritt 5)

• Samba konfigurieren: Folge der Installationsanleitung auf GitHub (Schritt 8)

ℹ️ Windows Maschinen von Nutzern, die vorher bereits mit K2.X (und Samba) gearbeitet haben, können unter Umständen auch bei einem korrekt installierten und konfigurierten Samba nach dem (Betriebssystem-) Upgrade nicht sofort die Home Verzeichnisse auf dem K3.X Server einbinden. (Fehler: Falsches Kennwort). Dies konnte an der UBBS behoben werden, indem ein bestimmter Eintrag in der Registy entfernt wurde: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa → LmCompatibilityLevel → löschen

• /etc/sudoers mit Rechten für die Ausführung durch tomcat8 anpassen

• Tomcat konfigurieren und neustarten

• kitodo_config.properties eventuell anpassen

Nun müsste K3.X installiert und online erreichbar sein.

Anpassen der Nutzerrechte

An der Kitodo Webapp anmelden und den Migrations-Admin-Nutzer (MAN) mit allen Rechten ausstatten:

• Zuvor kann jedoch auch erst geprüft werden, ob der MAN auch alle notwendigen Rollen in der Datenbank zugeschrieben bekommen hat: Folge Installation → Installation Schritt für Schritt → Schritt 13
• Mit allen Rollen ausgestattet, kann eine Rolle mit allen Rechen (z.B.: "superuser") erzeugt und der Nutzer MAN damit ausgestattet werden.

Als nächstes sollten der LDAP-Server und LDAP-Gruppe angepasst werden: Folge der Installationsanleitung auf GitHub (Schritt 13)

Metadaten Konvertierung und Projekt Indexierung

Die Konvertierung der Meta-Daten erfolgt in der Kitodo Webapp unter: Dashboard → System → Reiter Migration (siehe Screenshot).

Die zu konvertierenden Projekte können ausgewählt und der Prozess mit "Metadaten dieser Projekte konvertieren" gestartet werden. Konkret werden im Hintergrund nun alle Metadaten (d.h. die meta.xml und ggf. Hilfsdateien) eines jeden Vorgangs (des jeweiligen Projektes) im Verzeichnis /usr/local/kitodo/metadaten/<Vogangs-ID>/meta.xml unter Verwendung der /usr/local/kitodo/xslt/MetsModsGoobi_to_MetsKitodo.xsl in ein Kitodo 3.X konformes METS-ähnliches Format gebracht. Der Prozess kann je nach Projektgröße dauern und ist im Taskmanager einzusehen.

ℹ️ Der Taskmanager in Kitodo ist immer eine gute Anlaufstelle, um nachzusehen, warum eine Aktion nicht oder nicht wie gewünscht funktioniert.

Anschließend kann die Indexierung der jeweiligen Projekte gestartet werden (siehe Screenshot).

Dazu sollte erst "ElasticSearch Mapping erzeugen" angewendet werden. Die Erzeugung eines gesamten Such-Indexes erfolgt über den Button "Indexierung starten" unten links. Die anderen Buttons "Indexierung starten" dienen der Indexierung einzelner Komponenten, wie Vorgänge, Aufgaben, Projekte, usw. entweder von Neuem (linke Spalte "Komplette Indexierung starten") oder ergänzend für die einzelnen Komponente (rechte Spalte "Indexierung vervollständigen").

ℹ️ Das Indexieren kann ggf. länger dauern. Sollte über einen längeren Zeitraum scheinbar kein Fortschritt mehr zu verzeichnen sein, hilft ein Aktualisieren der Seite (F5).

Erstellen der Workflows

In K3.X ist jedem (neuen) Vorgang auch ein Workflow zugeordnet, der die Aufgabenliste zur Digitalisierung abbildet. Um nun auch allen Vorgängen aus K2.X so einen Workflow zuordnen zu können, müssen diese erst erstellt werden. Dies ist eine anspruchsvolle Arbeit, die unbedingt mit dem jeweiligen bibliothekarischen Fachbereich abgesprochen werden sollte. K3.X bietet bei der Migration verschiedene Workflow-Vorschläge an, eine Vereinheitlichung dieser, ggf. über verschiedene Projekte hinweg, ist ebenfalls möglich.

Mit dem Button "Workflow erstellen" (Dashboard → System → Reiter Migrieren) werden die zu migrierenden Projekte gelistet und für die getätigte Auswahl von Projekten mit dem Button "Nach Vorgängen suchen" können dann alle Vorgänge gelistet werden, die noch keinen Workflow zugeschrieben bekommen haben.

ℹ️ Hier gelistete Vorgänge ohne WorkfIow haben in der Datenbank noch den Wert null gesetzt.

Besitzen Vorgänge (eines Projektes) eine identische Aufgabenliste (gleiche Namensgebung und Aufgabeneigenschaften), werden diese zusammengefasst dargestellt (siehe Screenshot).

Das Erstellen und Zuweisen der Workflows zu den "alten" Vorgängen kann vor der Migration vorbereitet werden. Dafür empfiehlt es sich, eine Kopie der Datenbank des zu migrierenden Systems in ein Kitodo 3.X Test-System zu laden (bspw. in einer VM) und die Migration der Workflows zu simulieren. So können alle zur Verfügung stehenden (vorgeschlagenen) Workflows im Detail angesehen, testweise angepasst und ggf. vereinheitlicht werden. An der UBBS konnte aus allen Vorschlägen ein Minimal-Set von 7 "prototypischen" Workflows identifiziert werden, die bei der Migration eingesetzt wurden.

Nach dem Drücken auf das Doppelpfeilsymbol erscheint die eigentliche Zuweisung der Vorgänge zu den Workflows und anschließend zu Produktionsvorlagen. Es gibt die Option, einen neuen oder bereits vorhandenen Workflow anzulegen. Wenn ein bereits existierender Workflow gewählt wurde, kann anschließend entschieden werden, ob die zu migrierenden Vorgänge (mit dem gewählten Workflow) zu einer neuen oder bereits vorhandenen Produktionsvorlage verknüpft werden sollen. Wurde ein neuer (oder angepasster alter bzw. prototypischer) Workflow erstellt, muss auch eine neue Produktionsvorlage dazu erstellt werden.

ℹ️ Bei der Erstellung bzw. Anpassung der Workflows ist zu beachten, dass der Bearbeitungsstatus jeder Aufgabe nicht auf "Abgeschlossen", sondern auf "Gesperrt" gesetzt ist. ℹ️ Wenn ein prototypischer Workflow (der ggf. bei der Migration auch angepasst wurde) mit seiner neuen Produktionsvorlage P eines Projektes A bei der Migration auch für Vorgänge eines anderen Projektes B (im Rahmen einer Vereinheitlichung) ausgewählt wird, funktioniert dies während der Workflowerstellung problemlos. Das Projekt B (und ggf. weitere Projekte C, D, ...) werden dabei aber nicht mit der Produktionsvorlage P verknüpft. Daher muss im Anschluss der Migration in den jeweiligen Projekteinstellungen noch die Produktionsvorlage P zum Projekt B (C, D, ...) hinzugefügt werden.

Serielle Publikationen migrieren

Übergeordnete Vorgänge, d.h. (Vogänge zu) Mehrbändigkeiten, können nach der Metadaten-Konvertierung und Workflow-Erstellung in der Kitodo Webapp unter: Dashboard → System → Reiter Migrieren generiert werden. Im Rahmen der Datenvorbereitung (Vgl.: Migration → Vorbereitung → Datenvorbereitung) sollten daher zuvor (im K2.X Produktiv-System) die PNNs bereinigt worden sein. Weiterhin kann im Regelsatz (für die Migration) angegeben werden, wie die Titel der übergeordneten Vorgänge generiert werden sollen (Vgl.: Migration → Vorbereitung → Regelsatz konvertieren und anpassen).

Nachbereitung

Sämtliche Vorgänge wurden nun migriert. Abschießend müssen noch die Projekte im Hinblick auf Ordnerstruktur und Bild-Derivate angepasst werden:

• Im Projekt die Einstellungen für METS-Dateigruppen und Ordnerverwendung prüfen
  • Dateigruppe MAX/THUMBS entstehen bei der Migration
  • Dateigruppe LOCAL muss auf die Quelldateien zeigen und unter Ordnerverwendung als Quelle angegeben sein
• KitodoScript action:createFolders auf (z.B. nach Projekt) gefilterte Vorgangsliste ausführen
• KitodoScript action:generateImages folders:jpgs/max,jpgs/thumbs images:all auf (z.B. nach Projekt) gefilterte Vorgangsliste ausführen

ℹ️ Das Erstellen der Ordner für die Vorgänge eines Projektes erfordert, dass die entsprechenden Vorgänge in der Filter-Ansicht erst ausgewählt werden (die Checkbox muss angehakt werden), um anschließend das KitodoScript zum Ordner erstellen ausführen zu können. Hat ein Projekt sehr viele Vorgänge, ist das Auswählen aller Vorgänge aktuell noch etwas umständlich, da die Checkbox am Tabellenkopf lediglich dafür sorgt, dass die Vorgänge der sichtbaren Seite ausgewählt werden. Eine Erleichterung besteht darin, zuvor die Tabellengröße in den "Benutzerdaten & Einstellungen" (ganz oben rechts) von 10 auf z.B. 100 zu setzen, da dann die Anzahl der angezeigten Vorgänge größer wird und damit mehr auf einmal ausgewählt werden können.

Einzelne Projekte nach- bzw. erneut Migrieren

Sollte es Probleme mit den (migrierten) Metadaten eines Projektes geben, ist es möglich (aber nicht empfehlenswert), einzelne Projekte erneut zu migrieren. Das Vorgehen besteht dabei im Wesentlichen im Ersetzen der zu migrierenden Daten (meta.xml) in den Vorgangsordnern des betreffenden Projektes durch die ursprünglichen Daten und einem anschließenden (erneuten) Konvertieren der Metadaten im Migrieren-Reiter.