Module Generator: Changes to a productive module

A fundamental principle and goal of the module Generator are to enable the dynamics of change in the processes also in the module itself. An enterprise workflow should never be exclusively aligned with the process specified by a software. Similarly, process and software design should be identical. Therefore, changes can be introduced into the module in the module generator just as quickly and easily as they can be introduced into the content of the associated process.

Compared to the initial release, where no existing data has to be taken into account yet, the change during operation brings some special features. There may already be hundreds of data records in the module, or there may be users who are actively working with the module. When changing the configuration afterwards, errors due to active users during migration and data inconsistencies must be excluded. The module generator prevents these problems and supports smooth data migration.

Data migrations are necessary when elements are deleted in the configuration. In this case, a new value must be selected for all existing data that currently still uses the value that will be deleted in the future. This occurs when deleting a status, a task type, or a selection option in the Selection from list attribute type. In these cases, the software prompts to select a new value after deletion.

It should be noted that all changes within the configuration, including deletions and migration options, are not performed until the change is released in the productive module.

Identical to the initial release, the configuration errors and possible problems are checked first. It is recommended to perform a test in a temporary test version afterwards. After that, the procedure in this scenario looks different:

• If no data migrations are necessary and no critical settings have changed, the change is made by clicking Update module.
• There are changes that lead to a confirmation message. In this case, all relevant adjustments are listed again before the changes are released. On the one hand, these are the selected data changes, such as the deletion of a status, and on the other hand, safety-critical changes such as the editing rights in the workflow are listed once again. These adjustments must be confirmed before the migration can be carried out.

In case of necessary data migrations, the migration mode is started after confirming the changes. When migration mode is activated, the module is put into read-only mode and users are shown a corresponding message. No more content can then be changed or created. This also applies to tasks within the content.

The migration mode serves as a preparation for the actual migration. In this way, users can be informed at an early stage that a software update will be carried out in the near future. After activating the migration mode, it is displayed how many users are currently still editing content in the module. These changes should be completed, otherwise users will receive an error message when saving and the changes will be irrevocably lost.

While the migration mode is active, work can continue in Q.wiki. It is possible to navigate to the configuration at any time via the list of configurations and a click on In Migration.

As soon as no users are working in the module anymore, the data migration can be started by clicking on Start Migration. This may take longer, depending on the number of elements and complexity of the changes. In smaller modules, the changes will be available after a few seconds. After that, you will be redirected to the overview page and the updated module will be available.

Translated with www.DeepL.com/Translator (free version)