Merge pull request #84 from RotherOSS/issue-rotheross/otobo#1216-Conf…

…igurationDeploy

Issue RotherOSS/otobo#1216 configuration deploy

content/migration-from-otrs-6.rst

@@ -466,9 +466,12 @@ When that happens, please check the settings in *Kernel/Config.pm* and revert th
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 On systems that experienced problems with an upgrade in the past, the migration process may stop due to MySQL errors
-in the tables *ticket* and *ticket_history* (NULL). These have to be manually resolved before you can resume the migration.
+in the tables *ticket* and *ticket_history*. Usually these errors are NULL values in the source table that are no longer
+allowed in the target table. These conflicts have to be manually resolved before you can resume the migration.
 
-4. Errors in Step 4 when migrating to PostgreSQL
+As of OTOBO 10.0.12 there is a check in *migration.pl* that checks for NULL values before the data transfer is done. Note, that the resolution still needs to be performed manually.
+
+4. Errors in Step 5 when migrating to PostgreSQL
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In these cases the not so helpful message "System was unable to complete data transfer." is shown by *migration.pl*. The Apache logfile,
@@ -485,6 +488,28 @@ It is not clear yet, whether the extended privileges have to be granted in every
 
     The discussion in https://otobo.de/de/forums/topic/otrs-6-mysql-migration-to-otobo-postgresql/.
 
+5. Problems with the Deployment the Merged System Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The system configuration is migrated after the migration of the database tables. In this context, migration means the merging
+the default settings of OTOBO 10 with the system configuration of the source system.
+Inconsistencies can arise in this step. An real life example is the setting ``Ticket::Frontend::AgentTicketQuickClose###State``.
+This setting is new in OTOBO 10 and the default value is the state ``closed successful``. But this setting is invalid
+when the state ``closed successful`` has been dropped or renamed in the source system.
+This inconsistency is detected as an error in the migration step **Migrate configuration settings**. Actually,
+the merged system configuration is stored in the database, but additional validity checks are performed during deployment.
+
+The problem must be alleviated manually using OTOBO console commands.
+
+- List the inconsistencies with the command
+  ``bin/otobo.Console.pl Admin::Config::ListInvalid``
+- Interactively fix the invalid values with
+  ``bin/otobo.Console.pl Admin::Config::FixInvalid``
+- Finally manually deploy the system configuration with
+  ``bin/otobo.Console.pl Maint::Config::Rebuild``
+
+After these manual steps you should be able to run *migration.pl* again and continue where the error occurred.
+
 Step 7: Manual Migration Tasks and Changes
 ------------------------------------------