Migration: Errors in ConfigurationDeploy() might not show up in migration.pl web interface

[bschmalhofer]

During migration from OTRS 6 to OTOBO 10 the following line was encountered in the Apache log file:

[Error][Kernel::System::SysConfig::ConfigurationDeploy][Line:3506]: Setting PostmasterDefaultQueue Effective value is not correct: Entity value is invalid(Platinum-Support)!

This message is emitted by Kernel::System::SysConfig::ConfigurationDeploy() which is called in Kernel/System/MigrateFromOTRS/OTOBOMigrateConfigFromOTRS.pm. The cause of the error message is that the queue Platinum-Support is not available in the migrated database. This could have been caused by a misconfiguration in the source system.

However the code that calls ConfigurationDeploy() looks fishy.

   # Write ZZZAAuto.pm
    my $Success = $SysConfigObject->ConfigurationDeploy(
        Comments    => $Param{Comments} || "Migrate Configuration from OTRS to OTOBO",
        AllSettings => 1,
        Force       => 1,
        UserID      => 1,
    );

The method should return a list of key value pairs, not a single scalar. This means that $Success is set to the last value of that list, which can be 0 by chance. Thus it depends on chance whether a failure of ConfigurationDeploy() is detected and thus reported in the webinterface. A missing error message is bad because in the error case the file ZZZAAuto.pm is propably not updated.

[bschmalhofer]

See also #744.

[bschmalhofer]

Tested this be renaming the state 'closed successful' to 'closed successful renamed'. During migration there was no error message but ZZZAAuto,pm was not written. This effect should not happen all the time, but it did in my initial tests.
Testing now the solution where the result of ConfigurationDeploy() is treated as a hash.

Along the way, I did a bit of tidying of the migration modules.

[bschmalhofer]

The fix looks fine. Here is the changed message:

Migriert die Konfigurationseinstellungen.

The merged configuration could not be deployed. Please try to fix the configuration by running these console commands:
Admin::Config::ListInvalid, Admin::Config::FixInvalid, Maint::Config::Rebuild.

[bschmalhofer]

TODO:

• Documment the message as an known migration problem in content/migration-from-otrs-6.rst .

[bschmalhofer]

I think that there is still an issue with caching. In the test scenario where the state 'closed successful' I could repair the sysconfig with Admin::Config::FixInvalid. But at first there was a complaint for some other settings, indicating that the new states were not valid. This could be explained by the Kernel::System::State cache holding still the states of the initiial OTOBO installation. Let's try to do the migration task OTOBOCacheCleanup twice. The first time before OTOBOMigrateConfigFromOTRS and then before OTOBOPackageSpecifics.

[bschmalhofer]

Using the step OTOBOCacheCleanuptwice did not pan out, as step names are used in a hash somewhere. The second usage thus overwrites the first usage.
The alternative solution is to clean up the cache directly in the OTOBODatabaseMigrate step. This seems to work fine. Redoing the testmigraion from above, the error message is shown as expected. But this time the fixing worked smoothly.

bes:/devel/OTOBO/otobo (issue-#1216-ConfigurationDeploy)$ bin/otobo.Console.pl Admin::Config::ListInvalid
The following settings have an invalid value:
Ticket::Frontend::AgentTicketQuickClose###State = 'closed successful';
bes:/devel/OTOBO/otobo (issue-#1216-ConfigurationDeploy)$ bin/otobo.Console.pl Admin::Config::FixInvalid

Ticket::Frontend::AgentTicketQuickClose###State is invalid, select one of the choices below:
[1] new
[2] closed successful renamed
[3] closed unsuccessful
[4] open
[5] removed
[6] pending reminder
[7] pending auto close+
[8] pending auto close-
[9] merged

Your choice: 2

Deployment successful.
Done.

Apparently the deployment is already done by FixInvalid.

TODO:

• Remove Maint::Config::Rebuild from the documentation and the message.

[bschmalhofer]

Another test migration ran fine. The PR is merged . Closing this issue.

[bschmalhofer]

While Testing #1297 I ran into more SecureMode errors after calling Admin::Config::FixInvalid. The difference to the previous migration scenarios must have been, that SecureMode was now enabled in the source OTRS installation. This can be fixed by calling bin/otobo.Console.pl Maint::Config::ReBuild.
Reopening this issue as the message must be enhanced again.

[bschmalhofer]

Adapted the message. Closing this issue again.