GLJournalEntryConfiguration and other modules not marked as initialized after import
Description
The import process is not setting some modules as initialized after the import completes. This causes these jobs to then run again later at startup but is unnecessary. The modules listed in the following code from ImportUtility were all marked as initialized=false after an import of Fayette's data:
When this problem was discovered, I did a query on the cfg_configuration table and found that the modules were marked as initialized but just before the process stopped they became false again. This is caused by the ImportUtility requesting a state change after the import process is complete. The module receives notification that the state changed and sets its initialized flag to false.
To improve this process we need to do a couple of things. First we would like to remove the state change that is at the end of the import process in the finally block. This will prevent the ledger-related modules resetting their initialized flags to false when the import process completes.
We then need to do some research to figure out where, if anywhere, in the code that we need to perform some operation as a result of the import process completing that won't be handled on first application startup or as a result of the module being installed while in RUNNING mode. If we find any of these places, we need to create a new ImportCompletionEvent, fire this event just before the import post-process jobs are started, and react to this event in the places that need to be notified. Good candidates would be places that react to ModelStateTransitionEvent.
Finally, we need to update the module install code in our modules to only run the initialization of the module if the application is in RUNNING mode when the module is installed. If we're not in RUNNING mode, the initialization should happen when the application goes into RUNNING mode...not at install time.
The import process is not setting some modules as initialized after the import completes. This causes these jobs to then run again later at startup but is unnecessary. The modules listed in the following code from ImportUtility were all marked as initialized=false after an import of Fayette's data:
When this problem was discovered, I did a query on the cfg_configuration table and found that the modules were marked as initialized but just before the process stopped they became false again. This is caused by the ImportUtility requesting a state change after the import process is complete. The module receives notification that the state changed and sets its initialized flag to false.
To improve this process we need to do a couple of things. First we would like to remove the state change that is at the end of the import process in the finally block. This will prevent the ledger-related modules resetting their initialized flags to false when the import process completes.
We then need to do some research to figure out where, if anywhere, in the code that we need to perform some operation as a result of the import process completing that won't be handled on first application startup or as a result of the module being installed while in RUNNING mode. If we find any of these places, we need to create a new ImportCompletionEvent, fire this event just before the import post-process jobs are started, and react to this event in the places that need to be notified. Good candidates would be places that react to ModelStateTransitionEvent.
Finally, we need to update the module install code in our modules to only run the initialization of the module if the application is in RUNNING mode when the module is installed. If we're not in RUNNING mode, the initialization should happen when the application goes into RUNNING mode...not at install time.