feat: add sandbox package uninstallation

docs/matrix42-26-1-extension-migration.md

@@ -1,8 +1,8 @@
 # Matrix42 26.1 Legacy Extension Migration
 
-Diese Notizen dokumentieren die bisherigen Learnings aus der Migration einer alten Matrix42 Extension inklusive Custom Web Service auf eine Matrix42 26.1 Sandboxed Extension.
-
-Die parallele Pflege der Legacy- und Sandbox-Varianten sowie der manuelle TFS-Rueckweg sind in `docs/legacy-sandbox-development.md` beschrieben.
+Diese Notizen dokumentieren die bisherigen Learnings aus der Migration einer alten Matrix42 Extension inklusive Custom Web Service auf eine Matrix42 26.1 Sandboxed Extension.
+
+Die parallele Pflege der Legacy- und Sandbox-Varianten sowie der manuelle TFS-Rueckweg sind in `docs/legacy-sandbox-development.md` beschrieben.
 
 Die Anleitung ist bewusst als wiederverwendbare Checkliste fuer weitere Legacy-Pakete formuliert. Sie trennt zwischen belastbaren Ergebnissen, verworfenen Zwischenansaetzen und Punkten, die bei jeder Extension erneut geprueft werden muessen.
 
@@ -101,8 +101,23 @@ Das neue Paket basiert auf einem `PackageTemplate` mit:
 - `package.json`
 - `install.xml`
 - `install/...`
+- `uninstall.xml`
+- `uninstall/...`
+- `uninstall_data.xml`
 - `BasePackage/Assemblies` als Build-Ziel fuer Assemblies
 
+### Deinstallation
+
+Eine Sandboxed Extension unterstuetzt die Matrix42-Paketdeinstallation nur, wenn das Paket eigene Uninstall-Skripte mitliefert. Fuer dieses Paket gilt:
+
+- `uninstall.xml` entfernt den WebAPI-Service, alle eigenen Webservice-Operationen, Actions, Data Queries, die F4SD-Navigation, den F4SD-Quick-Call, die F4SD-Rolle und die eigene Lokalisierung.
+- Die vier globalen C4IT-Navigationseintraege werden nicht entfernt, weil sie von weiteren C4IT-Paketen gemeinsam verwendet werden koennen.
+- Schema, Pickup-Werte, Konfigurationseintrag, Dataset-Views und Previews bleiben als Konfigurationsdaten bestehen. Deshalb ist `uninstall_data.xml` absichtlich leer.
+- Der abschliessende Post-Schritt entfernt die `dat`-Eintraege dieses Pakets aus `SchemaScripts`, damit eine spaetere Neuinstallation die Installationsskripte erneut ausfuehren kann.
+- Jede `.del`-Datei verwendet nur eine aus dem Installationsobjekt oder einem Matrix42-Herstellerpaket verifizierte Kombination aus `ObjectId` und `TypeId`. Typ-IDs duerfen nicht geraten werden.
+
+Beim Hinzufuegen eines paket-eigenen Objekts muss immer geprueft werden, ob auch `uninstall.xml`, eine passende `.del`-Datei und `UnregisterInstallScripts_Sobu.post` erweitert werden muessen.
+
 Beim Portieren eines Legacy-Pakets:
 
 1. Altes Paket entpacken.