Data module migration

Scope

What is in 5.2

• We configure content-apps for all existing types in the data module
• We use detail subapps to create/edit new entries
• We also migrate default data-module-based Company type for fresh install
  
  • We don't migrate Contact and category, those are already migrated
  • We don't migrate RssAggregator, module is currently being migrated to its own workspace
• We drop legacy admininterface classes and config
  
  • where we provide proper replacement and migration to this replacement

What is NOT in 5.2

• We don't move content to new workspaces
• We don't change ACLs consequently
• We don't have an app to manage custom types

Migration concretes

1. Dialogs

•  We migrated Types dialog definitions to 5.0 dialogs
  
  • and refer to their inner form from the data-types detail subapps

2. Content apps

•  We created migration tasks for creating content apps based on dataTypes
  
  1. creating basic app definition with a task + appLauncherLayout entry
  2. create browser subapps (workbench)
  3. add browser "default" actions + availability (edit)
  4. create detail subapps, link to dialogs' inner form definitions
  5. add actions to create items with different types

3. Multiple hierarchical types

•  We open the right subapp based on selected item type
•  For creation, we have multiple add actions for each available item type, displayed based on action availability

4. Mixin supertypes for data nodeTypes

• If mixins are missing, nodes are not decorated with LastUpdateContentDecorator, and lastModified properties are not updated
•  Node-types migrated:
  
  • dataBase - added mgnl:created, mgnl:lastModified supertypes
  • dataItem - added mgnl:activatable, mgnl:versionable supertypes
  • dataItemNode - added mgnl:activatable supertype
  • dataFolder - added mgnl:activatable supertype

5. Legacy code and configuration

•  We removed old DataModule 2.x legacy apps (as seen until Magnolia 5.1)
•  We removed legacy GUI classes and config (trees, pages)

Cleanup of legacy UI classes and config

Elements	Affected sources	Affected config	Changes / Replacement	Migration
Dependencies	pom.xml META-INF/magnolia/data.xml		adminInterface
	info.magnolia.module.data.TypeDefinition		@Deprecate getIcon()  configure icons in workbench nodeTypes instead deprecate whole class?
		server.URI2RepositoryMapping.mappings.dataModuleTypeImages	no longer used
Commands	info.magnolia.module.data.commands		Activation commands which need to be based on itemTypes should have this property configured on the command itself. This might involve using a specific command catalog for each tree that was previously configuring itemTypes. The activation actions in browser subapp should then set the catalog property accordingly. We should also do the same for versioning actions We don't migrate this automatically Ideally in the future, such behavior is driven directly by node-types (e.g. mgnl:content vs. mgnl:contentNode) The data commands which activate/deactivate "All" are no longer used one may configure or implement bulk actions instead see info.magnolia.ui.framework.action.AbstractMultiItemAction
	TypeActivateCommand TypeDeleteCommand	modules.data.commands.dataType.*	Replaced with plain activation of data/apps and appLauncherLayout
Controls	info.magnolia.module.data.controls.*	modules.data.controls.*	Replaced with fields
	DataButtonSet DataUUIDButtonSet DataMultiSelect DataUUIDMultiSelect		Migrator exists
	DataFileControl		Support of migration to UploadField is unlikely to land in 5.2
	DataMultiValueControl NodeNameControl TypeIconFileControl		No longer required
SaveHandler	info.magnolia.module.data.save.DataSaveHandler		No longer required, uses multi-value transformers instead Post-save actions should be migrated to info.magnolia.ui.form.EditorCallback
Dialogs	info.magnolia.module.data.dialogs.*		Dialogs for types are migrated to the 5.x style  TypeSelectDataDialog has been replaced with multiple actions + availability in browser subapps
		modules.data.dialogs.dataType	Creating data types on the fly no longer supported This will be replaced with a content-app creator in the future For the time being, one may still create types at runtime via groovy, and configure content apps accordingly.
Import			No changes
Trees	info.magnolia.module.data.trees.* mgnl-resources/js-classes/mgnl/data/DataTree.js mgnl-resources/js-classes/mgnl/data/TypeTree.js	modules.data.trees.*	Replaced with content apps
Pages	info.magnolia.module.data.lists.DataVersionsList info/magnolia/module/data/lists/DataAwareInbox.html	modules.data.pages.*	Replaced with versioning actions in content apps
Util	info.magnolia.module.data.util.DataUtil		@Deprecate the whole class: Since 5.2, handling of multiple values is done at field level by setting property transformers We no longer configure legacy dialogs for data module TypeDefinitions are solely used initially for migration to content apps.

Ideas

• Move and split app creation tasks to ui content app?
• Do customers prefer:
  
  • auto-upgrade of custom datatypes with less control (e.g. icons)
  • manual upgrade of custom datatypes with more control, but via groovy
  • still defaults to all but you can pass additional config
  • can we run such a migration twice to refine resulting app
• Dialog migration
• i18n, where does it come from? old i18nBasename still supported?
• missing label and description for e.g. company dialog