Module management
General
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 
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.
Symbol | Action |
|---|---|
 | 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