PLF 3.0 provides a set of tools to migrate user and system data from your AIO instance to your new PLF 3.0 instance
Who should read this document ?
You should need this guide if you are in the process of upgrading your system from AIO 1.6 to PLF 3.0 and have data to migrate.
The main migration tool provided is called the Configuration Marshaller. This tool is capable of inspecting the source (AIO) kernel components and performing a set of migration tasks, typically exporting in a format that can be easily reinjected in the Platform 3.0 instance.
The Marshaller is a pluggable service that exposes a REST interface. So most of the interaction with this tool will consist of hitting specific URLs to execute specific migration tasks.
The migration tool provide several services that you may need for your migration :
Export of Portal configuration metadata files (Pages & Navigations)
Export of Application Registry configurations
Export of Resource Bundles data
Export of ECM Administration configurations, metadatas and templates.
Convert Portal configuration metadata files to GateIN format
Export Organization DATA and Import it in Platform server.
Backup/Restore Collaboration data nodes and its related version History nodes.
Some libraries need to be installed. Two for your source AIO server and two others to deploy on your target Platform server.
Warning
You will have to delete those libraries after finishing the migration.
Step 1: Deploy the source migration library on your AIO instance
Stop your AIO server instance
Obtain the libraries bundled with this documentation exo.platform.migration.aio-VERSION.jar and exo.platform.migration.common-VERSION.jar.
Drop libraries in the classpath (for example under lib/ for Tomcat)
Startup and watch the console, you should see the service starting like this :
[INFO] ResourceBinder - Bind new ResourceContainer: org.exoplatform.platform.migration.aio.rest.MarshallConfigurationREST
After the server startup is complete, you could access to this service by typing this URL <SERVERNAME>:<SERVERPORT>/portal/rest/containersConfiguration/.
Step 2 : Deploy the target migration library on your PLF instance
Stop your Platform server instance
Obtain the libraries bundled with this documentation exo.platform.migration.plf-VERSION.jar and exo.platform.migration.common-VERSION.jar.
Drop libraries in the classpath (for example under lib/ for Tomcat)
Startup and watch the console, you should see the service starting like this :
new resource /containersConfiguration : class org.exoplatform.platform.migration.plf.rest.MarshallConfigurationREST
After the server startup is complete, you could access to this service by typing this URL: <SERVERNAME>:<SERVERPORT>/rest/containersConfiguration/.
The Marshaller provides a feature that allows to retrieve kernel configurations of components loaded in the eXo containers. It is capable of retrieving all components and their configured external-component-plugins.
This is very handy to capture customizations before reintroducing in your PLF extension project.
Once the migration library is deployed in your AIO instance, hit : <SERVER_NAME>:<SERVER_PORT>/rest/containersConfiguration/, this will list all containers on this server :
The first link will list all services of the root container, and the second will list all components of the portal container.
Clicking on the second one will result in something like that :
Clicking on each component will return the kernel configuration for this component. For example, click on org.exoplatform.services.naming.InitialContextInitializer, you should get something like this:
<configuration>
<component>
<key>org.exoplatform.services.naming.InitialContextInitializer</key>
<type>org.exoplatform.services.naming.InitialContextInitializer</type>
<component-plugins>
...
</component-plugins>
<init-params>
...
</init-params>
</component>
</configuration>
Any configuration can be retrieved in this way.
On some components, clicking on the link will return a zip file instead of the xml file. These components are said Migration Managed. A special hook intercepts the generic marshaling process to perform more than just dumping the kernel component.
The format of the zip file depends on the component and additional steps are needed for successfully migrating that component. The format and steps are explained in the chapters below.
We also propose a full export feature.
This link will generate all configurations of the selected container. This feature will be helpful in order to get the components for whom the user has modified some configurations. Example: exporting all components of the PortalContainer from both fresh delivered AIO package and customized one will help the user to find the components that needs to be migrated from old system AIO to new system PLF. The user will not need to migrate all components. This feature will generate a zip file containing all kernel configuration of components from the selected container.
Note
A set of zip and xml files, where each file contains the kernel configuration of all components from the selected container.
The zip file looks like:
This migration tool will allow you to change the adopted OrganizationService implementation. For example, this will be very helpful if you attempt to use the PicketLink IDM implementation instead of Hibernate, LDAP or Active Directory implementation.
This tool consists of exporting data from the source (AIO) server and reimporting in the target (PLF) server.
The approach here is to dump the source model data (membership types, groups, and users) as a set of XML configurations for the OrganizationDatabaseInitializer. It makes the export agnostic to the actual datasource (LDAP or DB).
The dump is performed by an interceptor plugin of the Marshaller that :
extracts the organizational model data (membership types, groups, and users) from the current datasource.
creates a set of xml configurations for the OrganizationDatabaseInitializer.
generates a zip file of all xml configurations (to be used as an externalized configuration for the appropriate PortalContainer <YOURPORTALCONTAINERNAME>)
serializes Users and Users Profiles into separate files in a custom format.
Note
Serialization of users and profiles in a custom format is needed because import from the OrganizationDatabaseInitializer is not complete. In particular, it cannot import user profiles and does not support importing all attributes of users such as lastLoginDate.
Configuration The org service interceptor generates three main entries that will be easily injected in the target server :
membership types and groups as a set of configurations for the
OrganizationDataBaseInitializerusers as a set of configurations for the OrganizationDataBaseInitializer
the customized configuration of all external-component-plugins of the OrganizationService : this entry contains an import for the two other entries (membership types , groups and users)
Tip
Users are dumped in batches of 100 users. You can define a different size of these batches in <migration-library>/conf/portal/configuration.xml :
[...]
<component-plugin>
<name>organizationService.handler</name>
<set-method>addHandler</set-method>
<type>org.exoplatform.platform.migration.handlers.impl.OrganizationServiceHandler</type>
<init-params>
<value-param>
<name>max-users-per-file</name>
<value>100</value>
</value-param>
</init-params>
</component-plugin>
[...]
To successfully export your current organization model data, please follow these steps :
hit <YOURSERVER>:<YOURPORT>/portal/rest/containersConfiguration as URL
click on the PortalContainer : portal link
Find and click on the org.exoplatform.services.organization.OrganizationService link :
save the zip file in a predefined location
The organizational model data is now exported in a zip file that contains an organization model data as a set on XML files.
Note
configuration.xml : main entry of the externalized configuration, to be used for your PortalContainer.
a sub-folder "OrganizationDataModel" which contains a configuration file for groups , membership types and a configuration file for users (set of files, each file have a number of users and memberships declarations)
a sub-folder "profiles" which contains a configuration file per user's profile
a sub-folder "users" which contains a configuration file per user serialization
The content of the zip file looks like:
The zip can now be used to import the organization data in.
The first step is to wire the exported OrganizationDataInitializer configurations in the external configuration directory.
Extract the content of exported zip file to <TOMCATHOME>/gatein/conf/portal/<YOURPORTALCONTAINERNAME> to get this structure :
<TOMCATHOME>/gatein/conf/portal/<YOURPORTALCONTAINERNAME>
OrganizationDataModel/
profiles/
users/
org.exoplatform.services.organization.OrganizationService.xml
rename the org.exoplatform.services.organization.OrganizationService.xml file to configuration.xml
Replace the implementation by PicketLinkIDM implementation (or any other types of implementation) in the configuration.xml file :
e.g: replace the hibernate implementation by the PicketLinkIDM one:
[...]
<component>
<key>org.exoplatform.services.organization.OrganizationService</key>
<type>org.exoplatform.services.organization.hibernate.OrganizationServiceImpl</type>
[...]
</component>
by the PicketLinkIDM implementation
[...]
<component>
<key>org.exoplatform.services.organization.OrganizationService</key>
<type>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</type>
[...]
</component>
If you have defined org.exoplatform.services.cms.drives.impl.NewGroupListener as component-plugin for this Service, please make sure to change the parameter "allowCreateFolder" defined in init-params (see details here paragraph ECM drives):
open the file configuration.xml
find the value-param allowCreateFolder for components of type org.exoplatform.services.cms.drives.impl.NewGroupListener
edit the value Both to nt:folder,nt:unstructured*
add the value-param allowNodeTypesOnTree (allowNodeTypesOnTree field declaration is mandatory: added in Platform)
| AIO | PLF |
|---|---|
|
[...] <type>org.exoplatform.services.cms.drives.impl.NewGroupListener</type> [...] <value-param> <name>allowCreateFolder</name> <value>Both</value> </value-param> [...]
|
[...] <type>org.exoplatform.services.cms.drives.impl.NewGroupListener</type> [...] <value-param> <name>allowCreateFolder</name> <value>nt:folder,nt:unstructured</value> </value-param> <value-param> <name>allowNodeTypesOnTree</name> <value>*</value> </value-param> [...]
|
Start your server
Tip
profiles/ and users/ folders are not needed at this stage, you can remove these folders before you start the server.
On startup, the portal container will load the organization model data from <TOMCATHOME>/gatein/conf/portal/<YOURPORTALCONTAINERNAME>/configuration.xml :
[...] <import>OrganizationDataModel/Groups-MembershipTypes.xml</import> <import>OrganizationDataModel/Users0.xml</import> <import>OrganizationDataModel/Users1.xml</import> [...]
Tip
You can verify that these configurations are properly loaded by starting with gatein-dev.sh run and inspecting the console. Here is an example of the server's console output:
[...] INFO: Add configuration file:/exo-working/tomcat/gatein/conf/portal/<YOUR_PORTAL_CONTAINER_NAME>/configuration.xml Dec 14, 2010 3:52:25 PM org.exoplatform.container.configuration.ConfigurationManagerImpl addConfiguration INFO: import file:/exo-working/tomcat/gatein/conf/portal/<YOUR_PORTAL_CONTAINER_NAME>/OrganizationDataModel/Groups-MembershipTypes.xml Dec 14, 2010 3:52:25 PM org.exoplatform.container.configuration.ConfigurationManagerImpl addConfiguration INFO: import file:/exo-working/tomcat/gatein/conf/portal/<YOUR_PORTAL_CONTAINER_NAME>/OrganizationDataModel/Users0.xml Dec 14, 2010 3:52:25 PM org.exoplatform.container.configuration.ConfigurationManagerImpl addConfiguration INFO: import file:/exo-working/tomcat/gatein/conf/portal/<YOUR_PORTAL_CONTAINER_NAME>/OrganizationDataModel/Users1.xml Dec 14, 2010 3:52:25 PM org.exoplatform.container.configuration.ConfigurationManagerImpl addConfiguration [...]
Users profiles need to be imported manually.
Assuming the file org.exoplatform.services.organization.OrganizationService.zip was exported at /home/root/Downloads/org.exoplatform.services.organization.OrganizationService.zip, follow these steps to import user profiles :
Start the server and hit /<YOURPORTALCONTAINERNAME>/<YOURRESTCONTEXTNAME>/userProfiles, you should see :
Insert /home/root/Downloads/org.exoplatform.services.organization.OrganizationService.zip in the submit form
Click on the submit button. An import with success message appears :
Tip
You can verify that the users and profiles have been imported via the community management portlet and see that profiles are well imported.
The User Portal Configuration is made of navigation, pages, portlet preferences and Gadgets.
The approach here is to dump the UserPortalConfig data (navigation, pages and portlet-preferences and by user, group and portal) as a set of XML configurations for the UserPortalConfigService.
The dump is performed by an interceptor plugin of the Marshaller that :
extracts the UserPortalConfig data from the datasource.
creates an set of xml configurations for the UserPortalConfigService.
generates a zip file of all xml configurations (to be used as an externalized configuration for the PortalContainer portal)
To successfully export your current UserPortalConfig data, please follow these steps :
hit <YOURSERVER>:<YOURPORT>/portal/rest/containersConfiguration
click on the PortalContainer :portal link
Find and click on the org.exoplatform.portal.config.UserPortalConfigService link :
save the zip file in a predefined location
Note
a configuration file of UserPortalConfigService component declaration with all customized external-component-plugins of the
UserPortalConfigService.a sub-folder "group" which contains configuration files for groups navigation
a sub-folder "portal" which contains configuration files for portal navigation
a sub-folder "user" which contains configuration files for navigation per user (users who have a separate navigation)
The content of the zip file looks like:
The zip needs some modifications (to fit the structure of UserPortalConfig in PLF) before that it can be used to import the UserPortalConfig data in.
For the conversion of the exported metadata (users, groups and portals navigations), we have added a new REST Service. Steps to convert Portal Config metadata files:
Start your Platform server
hit <YOURSERVER>:<YOURPORT>/<YOURPORTALCONTAINERNAME>/<YOURRESTCONTEXTNAME>/userPortalConfigurationConvertor
Enter the path location of the exported Zip file (org.exoplatform.portal.config.UserPortalConfigService.zip if not renamed)
Click on 'Submit'
As result of this operation you will get a Zip file containing the converted Portal Config metadata. The Zip file looks like:
Warning
To convert the Kernel configuration, please refer to the Migration guide section
Portal declarations.The conversion of the Portal Metadata isn't completely done by the Rest Service. The Rest Service will take care of the structure of XML Metadata conversion, but some portlet preferences and portlet names has changed. Please refer to the Migration guide section
Portal metadata descriptorsfor more informations.
The Resource Bundles are the files that contain translation for the user interface of the portal. In AIO, an UI was provided to edit the Resource Bundles. This UI has not been maintained as the Resource Bundles are no longer persistent in PLF. Since, the UI has significantly evolved between AIO and PLF, there are little chances that you can reuse the translated Resource Bundles in PLF. However, we provide a service that lets you retrieve your AIO Resource Bundles.
The approach here is to dump the Resource Bundle data as a set of XML configurations and Properties files for the ResourceBundleService.
The dump is performed by an interceptor plugin of the Marshaller that :
extracts the Resource Bundle data from the datasource.
creates an xml file of customized configurations for the ResourceBundleService.
creates a set of Properties files for locale.
generates a zip file of all created files (to be used as an externalized configuration for the PortalContainer portal)
To successfully export your current Resource Bundle data, please follow these steps :
hit <YOURSERVER>:<YOURPORT>/portal/rest/containersConfiguration
click on the PortalContainer :portal link
Find and click on the org.exoplatform.services.resources.ResourceBundleService link :
save the zip file in a predefined location :
Note
a configuration file of all customized external-component-plugins of the
ResourceBundleService.a sub-folder "locale" which contains locales for portal navigation.
As explained above, there is no way to import exported resources bundles, as this feature has disappeared in PLF. There is also no mapping between the AIO resource bundle keys and the PLF resource bundle keys. So, if you have translated your AIO instance, be prepared for a complementary translation effort.
Finally, your custom Resource Bundles will need to be hooked as a plugin of the ResourceBundleService. Please refer to the Migration Guide section Resource Bundles to learn how.
The Application Registry is where administrators define access and edit permissions for applications deployed in the server. This can be customized and edited online and this data is persistent. The migration approach consists of exporting the configurations found in the AIO instance in the native xml format for the external component plugin.
Application Registry data migration can be exported via the generic use of the Marshaller :
Hit
/portal/rest/containersConfigurationclick on the
PortalContainer :portallinkclick on the
org.exoplatform.application.registry.ApplicationRegistryServicelink :
save this configuration in a separate file :
Note
The generated XML file isn't compatible with PLF (only AIO), so to know how to convert it, please refer to the Migration guide.
The NodeTypes could be managed by UI, so that administrators could add new NodeType definitions interactively. This tool will allow you to export all persistent NodeType definitions. And to know exactly what was changed by UI, or even by customized configuration, you could use this Tool on an AIO standalone, then use it on your custom project, and finally compare the two exported configurations.
This migration tool module intercepts the configuration of the service org.exoplatform.services.jcr.RepositoryService and add the adequate Plugin to define all NodeTypes and namespaces definition.
The format of the exported configuration is a Zip file named org.exoplatform.services.jcr.RepositoryService.zip, which contains:
org.exoplatform.services.jcr.RepositoryService.xml: The computed RepositoryService configuration with its plugins.nodeTypes: a folder that contains the list of namespaces as sub-folders, each sub-folder contains the set of XML files, each XML file represents a NodeType definition.
The DocumentType Templates represents the dialog, view and skin definitions for a NodeType. Those templates are manageable by UI and by configuration.
This migration tool module intercepts the configuration of the service org.exoplatform.services.cms.templates.TemplateService and allows you to convert all those persistent templates to XML configurations. This is useful when you attempt to:
Export persistent configurations from a server in a production environment
Determines what was modified by custom configurations made on AIO
The format of the exported configuration is a Zip file named org.exoplatform.services.cms.templates.TemplateService.zip that contains:
org.exoplatform.services.cms.templates.TemplateService.xml: The computed TemplateService configuration with its plugins.nodetype-templates: a folder that contains Gtmpl and Skins templates files for each DocumentType.
The Application Templates represents the GTMPL files that will be used for a WCM Potlet:
Search Portlet Templates.
Content List Viewer Templates.
Category Navigation Portlet Templates.
Parameterized Content List Viewer Templates.
Those templates are manageable by UI and by configuration. This migration tool module intercepts the configuration of the service org.exoplatform.services.cms.views.ApplicationTemplateManagerService and allows you to convert all those persistent templates to XML configurations. This is useful when you attempt to:
Export persistent configurations from a server in a production environment.
Determines what was modified by custom configurations made on AIO.
The format of the exported configuration is a Zip file named org.exoplatform.services.cms.views.ApplicationTemplateManagerService.zip that contains:
org.exoplatform.services.cms.views.ApplicationTemplateManagerService.xml: The computed ApplicationTemplateManagerService configuration with its plugins.application-templates: a folder that contains a set of groovy templates (.gtmpl files) for each portlet.
The Metadata Templates represents the dialog and view definitions for a NodeType that is a metadata. Those templates are manageable by UI and by configuration.
This migration tool module intercepts the configuration of the service org.exoplatform.services.cms.metadata.MetadataService and allows you to convert all those persistent templates to XML configurations. This is useful when you attempt to:
Export persistent configurations from a server in a production environment
Determines what was modified by custom configurations made on AIO
The format of the exported configuration is a Zip file named org.exoplatform.services.cms.metadata.MetadataService.zip that contains:
org.exoplatform.services.cms.metadata.MetadataService.xml: The computed MetadataService configuration with its plugins.matadata-templates: a folder that contains Gtmpl templates files for each Metadata.
The "ECM Views" migration tool module, computes the configuration of org.exoplatform.services.cms.views.ManageViewService. This component's plugins allow you to migrate several types of groovy scripts:
ECMExplorer GTMPL templates that will display the content of node in the ECMExplorerPortlet.
ContentBrowser groovy templates
Note
ContentBrowserPortlet is deprecated, use WCM Portlets instead.
The Views of the ECMExplorerPortlet with the sets of buttons on each View.
The format of the exported configuration is a Zip file named org.exoplatform.services.cms.views.ManageViewService.zip that contains:
org.exoplatform.services.cms.views.ManageViewService.xml: The computed ManageViewServiceconfiguration with its plugins.templates: a folder that contains Gtmpl templates files for each View Template definition.
The "Groovy Scripts" migration tool module, computes the configuration of org.exoplatform.services.cms.scripts.ScriptService. This component's plugins allow you to define several types of groovy scripts:
Action scripts are launched when an ECM action triggers them (refer to Actions Concept? section for more information).
Interceptor scripts are be triggered before and/or after a JCR node is saved, when a node is created or edited. They are used to either validate the value entered in a form or to manipulate the newly created node.
Widget scripts are used to fill WebUI components, such as select box options in a dynamic way.
The format of the exported configuration is a Zip file named org.exoplatform.services.cms.scripts.ScriptService.zip that contains:
org.exoplatform.services.cms.scripts.ScriptService.xml: The computed ScriptServiceconfiguration with its plugins.scripts: a folder that contains the GroovyScript files.
The ECM Drives represents the user, group and shared drives that an administrator could add, delete or modify in ECMExplorerPortlet.
This migration tool module computes the configuration of the service org.exoplatform.services.cms.drives.ManageDriveService and allows you to export all Drives definitions in an AIO in production mode.
The format of the exported configuration is an XML file named org.exoplatform.services.cms.drives.ManageDriveService.xml that contains the computed ManageDriveService configuration with Drives definitions.
The "Shared JCR Queries" are the shared JCR Queries that all users could execute from ECMExplorerPortlet interface.
This migration tool module computes the configuration of the service org.exoplatform.services.cms.queries.QueryService and allows you to export all Query definitions in an AIO in production mode.
The format of the exported configuration is an XML file named org.exoplatform.services.cms.queries.QueryService.xml that contains the computed QueryService configuration with all shared Query definitions.
The "Folksonomy Style" are styles associated on tags. Depending on the number of added documents in each tag, then the displaying of it will be different from others. So by configuring the FolksonomyService, you could define the style of tags depending on number of documents on it.
The Stylesheet defintion and the number of documents are modifiable by the UI. So this migration tool module computes the configuration of the service org.exoplatform.services.cms.folksonomy.FolksonomyService and allows you to export it.
The format of the exported configuration is an XML file named org.exoplatform.services.cms.folksonomy.FolksonomyService.xml that contains the computed FolksonomyService configuration with all stylesheet definitions with the associated occurrences.
The "Taxonomy Trees" are the definition of WCM Categories that could be used over all the ECMS Portlets. The Taxonomy definitions and Trees could be added, modified or even deleted by UI.
This migration tool module computes, from the JCR, the configuration of the service org.exoplatform.services.cms.taxonomy.TaxonomyService and allows you to export it.
The format of the exported configuration is an XML file named org.exoplatform.services.cms.taxonomy.TaxonomyService.xml that contains the computed TaxonomyService configuration with all taxonomies Trees, permissions and actions.
The main goal of this RESTfull Service is to migrate the totality of an AIO Collaboration workspace, to PLF compliant collaboration&knowledge workspaces. So it is only useful in case of you have already a collaboration workspace in an AIO server, that is in production or pre-production environment. Otherwise, if your AIO project is in a development phase, you will probably not need to use this tool.
Note
This tool will generate the Forum and FAQ data in a separate workspace backup. This workspace name is knowledge, which refers the workspace used for FAQ&Forum in PLF.
Steps:
Add migration libraries to AIO instance
Hit
/portal/rest/migration/backup/Enter Backup Location: This location will contains the XML backup folders for each workspace
Click on 'Submit'
You will have to wait until these messages appear in the 'AIO Server's console'
[INFO] BackupService - collaboration backup done successfully! [INFO] BackupService - knowledge backup done successfully! [INFO] BackupService - system backup done successfully!
After that, you will get two sub-folders in the chosen location:
Collaboration backup : the whole workspace was backed up, but you could modify this migration tool configuration in order to delete some WCM configuration nodes. Those nodes will allow enable/disable those services "WCMContentInitializerService", "ContentInitializerService", "NewsletterInitializationService". The configuration looks like this:
... <component> <type>org.exoplatform.platform.migration.aio.backup.AIOBackupMigrationService</type> <init-params> <value-param> <name>delete.wcm.services.log.nodes</name> <value>true</value> </value-param> </init-params> </component> ...
If you set this init param
delete.wcm.services.log.nodesto false, on PLF startup, those services will not load configurations, and will not deploy configured artifacts. This could be useful, if you don't want to add default data by configuration. Learn more about ECMS auto deployed artifacts.System backup: System backup : Only a portion of the system workspace is backed up:
Version History nodes.
Bonita business processes definitions nodes
Knowledge backup : the content of PLF knowledge workspace. This data is generated from AIO Collaboration workspace, it contains the FAQ&Forum data nodes (Categories, posts ...).
In PLF, use this documentation steps to perform a restore for each workspace, download this configuration to put in "TOMCAT/gatein/conf/portal/portal/" as an example.
In PLF, the default publication plugin has changed to a new one that is more flexible, it's called 'Authoring plugin'. The old one, StageAndVersion, is now deprecated. It is recommended that you upgrade to the new plugin. Read more about the new Authoring plugin in ECMS reference guide.
Although, it is possible to configure much more sophisticated lifecycles, you can migrate transparently for your users by configuring a lifecycle that reproduces the states of the StageAndVersion plugin:
Import the old content.
Stop Platform server
Add this configuration in your Platform server:
<external-component-plugins> <target-component>org.exoplatform.services.wcm.extensions.publication.PublicationManager</target-component> <component-plugin> <name>AddLifecycle</name> <set-method>addLifecycle</set-method> <type>org.exoplatform.services.wcm.extensions.publication.lifecycle.StatesLifecyclePlugin</type> <description>Configures</description> <priority>1</priority> <init-params> <object-param> <name>lifecycles</name> <object type="org.exoplatform.services.wcm.extensions.publication.lifecycle.impl.LifecyclesConfig"> <field name="lifecycles"> <collection type="java.util.ArrayList"> <value> <object type="org.exoplatform.services.wcm.extensions.publication.lifecycle.impl.LifecyclesConfig$Lifecycle"> <field name="name"><string>lifecycle2</string></field> <field name="publicationPlugin"><string>Authoring publication</string></field> <field name="states"> <collection type="java.util.ArrayList"> <value> <object type="org.exoplatform.services.wcm.extensions.publication.lifecycle.impl.LifecyclesConfig$State"> <field name="state"><string>draft</string></field> <field name="membership"><string>*:/platform/users</string></field> </object> </value> <value> <object type="org.exoplatform.services.wcm.extensions.publication.lifecycle.impl.LifecyclesConfig$State"> <field name="state"><string>published</string></field> <field name="membership"><string>*:/platform/users</string></field> </object> </value> </collection> </field> </object> </value> </collection> </field> </object> </object-param> </init-params> </component-plugin> </external-component-plugins>
Start Platform server
Next, you can alter all existing data to migrate it to the new lifecycle.
Use Crash to connect to the JCR command line (See latest crash documentation link here)
Execute those crash commands for
root/gtnasuser/password:
telnet localhost 5000
connect {{{-}}}c portal {{{-}}}u root {{{-}}}p gtn collaboration
select * from publication:stateAndVersionBasedPublication where publication:lifecycleName<>'Authoring publication' {{{-}}}a {{{|}}} addmixin publication:authoring
select * from publication:stateAndVersionBasedPublication where publication:lifecycleName<>'Authoring publication' {{{-}}}a {{{|}}} addmixin publication:authoringPublication
select * from publication:stateAndVersionBasedPublication where publication:lifecycleName<>'Authoring publication' {{{-}}}a {{{|}}} set publication:lastUser "__system"
select * from publication:stateAndVersionBasedPublication where publication:lifecycleName<>'Authoring publication' {{{-}}}a {{{|}}} set publication:lifecycle "lifecycle2"
select * from publication:stateAndVersionBasedPublication where publication:lifecycleName<>'Authoring publication' {{{-}}}a {{{|}}} set publication:lifecycleName "Authoring publication"
commit
disconnect
Warning
The versionHistory nodes will remain working with StageAndVersion Publication plugin, because the versionHistory nodes couldn't be modified by users, it's system protected nodes.