Skip to main content
Skip table of contents

Module management


The individual modules are managed and the current status of the modules is monitored via the administration console. All system modules are displayed in the list. A deactivated or invalid module is displayed with the relevant icons (Fehler) and đź”’ .

Figure: Module management in the administration console

Each module has a validity date and a specific number of user licenses. A module with the validity date Jan. 1, 1970 has unlimited use. The module has a company license if a 0 is displayed for user licenses.

The administrator can import a modified module configuration from CURSOR Software AG, when e.g. 10 additional user licenses have been ordered. An export of the module configuration may be necessary for support. The entire configuration will then e saved in XML format and can be sent via email.



Imports the license file

Exports the license file

Allocation of user licenses if there is no company license

Edit customer licenses. Only relevant for software developers and their partners.

Change customer number. (no SQL statement necessary anymore)

License administration

CURSOR Software AG offers two licensing models:

  • User licenses
    A specific number of user licenses is provided. Each user must be created as an employee and must have a license assigned.

  • Company licenses
    An unlimited number of user licenses is provided. Each employee created in the system can immediately work in the system without an explicit license assignment.

When a module is activated on the basis of user licenses (>0), then employees can be added to the module. The max. number of employees ends on the number of available licenses. This item is deactivated if the module is run with a company license (user licenses = 0).

Edit customer licenses

Via the Edit customer licenses > Add modules button modules can be added to license files. In order to achieve better clarity, the lists can be filtered.

Overload texts from C0 and C1 modules

Specific I18n texts can be created for a C0 or C1 module (see image). The I18n resource bundle is transferred with all keys during module export/import. The I18n entries can be adapted in the C2 layer and transmitted as a packet

An update on the C1 module only overwrites the C1-I18n values and not the C2-I18n values.

Figure: Overloading of C0 texts in modules

Module checks

Checks when publishing

The following checks now take place when publishing modules:

  • whether all module-dependent processes are published

  • whether all module-dependent scripts are published/unpublished draft scripts exist

  • whether all included reports can be compiled without errors


Checks during export

When exporting the module, the same checks happen again as a precaution (analogous to the customizing transport).


Patch level check

When publishing a module, patch levels can be stored that are at least necessary to publish a module. This prevents non-executable module versions from being imported. The patch levels are stored in the module and can be changed when the module is next released. When importing the module in the target system, it is checked whether a patch level has been stored for the current version and, if so, whether this is available. Otherwise, the module cannot be imported and you will receive an error message.

Figure: Configuration of a patch level for a module

Allow I18n import of modules only in a maintenance window

The start of the I18n import of modules checks at the beginning if there are other users in the system.

  • if yes, a note is issued that the import may only take place within the scope of maintenance

  • if no, it is checked whether a maintenance window already exists

    • if yes, the user is asked if he wants to start the import

      • if yes, the import is started

      • if no, the import is canceled

    • if no, the user is asked whether he wants to perform the import as part of maintenance

      • if yes, a maintenance window is created directly and the import is started

      • if no, the import is canceled

Splitting a main partner module into a standard module and a main partner module

There is a switch in the module management that extracts all configurations that require a main partner module from the existing main partner module and writes them to a new module. Then, on the existing main partner module, the flag is removed and written to the newly created extracted module, which is then marked as the main partner module.
The extracted main partner module is then dependent on the former main partner module.
The module data will be specified when splitting, because only one main partner module can exist in a system.

When importing a main partner module, it is checked whether the main partner module has dependencies to an existing module of the same partner and whether this module has an active license. If yes, then the main partner module is also activated directly, if no, then a license must be imported separately as before.

Figure: Module splitting

Keys in unlicensed modules (Web Client)

Keys assigned to a module for which there is no valid license are displayed strikethrough in the key maintenance. The keys are not editable and cannot be selected in the application.


Figure: Keys in unlicensed modules

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.