Configuration
Logo and Header Color
To change visual aspects of Cockpit, you can edit the user stylesheet file located in
app/cockpit/styles/user-styles.css
. This file contains CSS which is loaded into Cockpit
and can override the standard styles.
/* hides the Camunda logo */
.app-banner svg {
display: none;
}
.app-banner {
/* hides the "Camunda Cockpit" text */
text-indent: 200vw;;
/* put your logo */
background-image: url(./path/to/the/logo.png);
/* sets the width to match the logo's width */
width: 80px;
}
/* changes the header top border color */
.Header {
border-top-color: blue !important;
}
Localization
The localization of Cockpit is contained in the app/cockpit/locales/
directory. This
directory contains a separate localization file for every available language. The file name
consists of the language code and the suffix .json
(e.g., en.json
).
Cockpit uses a locale file corresponding to the language settings of the browser. You can
set the availableLocales
property in the configuration file to provide a list of available
locales. Every locale which is contained in this list must have a locale file in the locales
directory with the corresponding language code.
If the browser uses a language which is not available, Cockpit uses the locale which is
defined via the fallbackLocale
property in the configuration file:
"locales": {
"availableLocales": ["en", "de"],
"fallbackLocale": "en"
}
To create a new localization for Cockpit, copy the provided language file, translate it and save it as new localization file with the corresponding language code. To make the new translation available, add it to the list of available locales in the configuration file.
Custom Scripts
If you want to add your own scripts to the Cockpit application, you should add a customScripts
property to the app/cockpit/scripts/config.js
file with something like this:
export default {
// …
customScripts:
['custom-module/module.js']
};
This includes a custom-module/module.js
file. The path is relative to the app/cockpit
folder in the Camunda webapp .war file.
You can find a complete example about how to use customScripts
to develop a Cockpit Plugin in the Camunda Platform examples repository.
Legacy Custom Scripts
Custom Scripts created for Camunda Platform 7.13 or earlier can be included using the requireJsConfig
property to the app/cockpit/scripts/config.js
. You can include these custom scripts using the custom requireJS configuration.
export default {
// …
requireJsConfig: {
// names of angular modules defined in your custom script files.
// will be added to the 'cam.cockpit.custom' as dependencies
ngDeps: ['my.custom.module'],
// RequireJS modules to load.
deps: ['custom-ng-module'],
// RequreJS path definitions
paths: {
'custom-ng-module': '../custom-ng-module/script'
}
}
}
For more details about legacy Plugins, check out the legacy Plugin documentation. Please note that this link will take you to the documentation of Camunda Platform 7.13 .
BPMN Diagram Viewer (bpmn.js)
The diagram viewer (bpmn.js) can be either customized by moddle extensions or
additional modules. To extend the BPMN diagram viewer
of Cockpit, a bpmnJs
property must be added to the app/cockpit/scripts/config.js
file.
Additional Modules
To add modules, the additionalModules
property needs to be specified, where each module is registered with its path. The path is relative to the app/cockpit
folder in the .war file of the Camunda Webapp.
...
bpmnJs: {
additionalModules: [
'my-custom-module/module'
]
}
...
You can find an example on how to add an additional bpmn.js module to Cockpit in the Camunda Platform examples repository.
Moddle Extensions
The BPMN moddle can be extended by adding a moddleExtensions
property. Each moddle extension has a unique name (key)
and a path (value) to the JSON file of the moddle extension. The path is relative to the app/cockpit
folder in the
.war file of the Camunda Webapp. The suffix .json
of the file is added automatically and must not be specified.
...
bpmnJs: {
moddleExtensions: {
camunda: 'my-custom-moddle/camunda'
}
}
...
skipCustomListeners and skipIoMappings Flags
You can configure the skipCustomListeners and the skipIoMappings flag globally for cockpit by adding a skipCustomListeners
or skipIoMappings
property in app/cockpit/scripts/config.js
:
export default {
skipCustomListeners: {
default: true, // default value for skipCustomListeners is true
hidden: false // skipCustomListeners checkbox is not hidden
},
skipIoMappings: {
default: true, // default value for skipIoMappings is true
hidden: false // skipIoMappings checkbox is not hidden
}
};
By default (if not configured), the flag value is true
. However, you can set the default value of the flag (true | false
)
in the default
property in the configuration.
Moreover, the checkbox to enable/disable the option is by default not hidden in Cockpit. You can set this behaviour by configuring the property
hidden
(true | false
) in the configuration. If the hidden
value is configured to be false, then the checkbox
will be hidden everywhere in Cockpit.
Runtime Activity Instance Metrics (Process Definition)
export default {
runtimeActivityInstanceMetrics: {
display: true
}
};
By default the activity instance statistics are displayed for the runtime view of the process definition.
Hence, the default value of the display
flag is true
. If the statistics shouldn’t be displayed initially process definition runtime view is opened, the display
option needs to be set to false
.
In any case does the toggle button allow to display/remove the statistics on demand.
Historic Activity Instance Metrics
export default {
historicActivityInstanceMetrics: {
adjustablePeriod: true,
//select from the default time period: day, week, month, complete
period: {
unit: 'day'
}
}
};
By default, the adjustablePeriod
flag value is true
. Setting it to false disables the ability in the process definition history view to manually select the time period for which the activity instances are displayed.
the unit
property of period
allows to specify the default timer period for which the activity instance badges are supposed to be shown.
Here it is possible to select form the range of values: today
, week
,month
,complete
;
Default Filter for the Historic Process Instances Search
export default {
defaultFilter: {
historicProcessDefinitionInstancesSearch: {
lastDays: 5,
event: 'started'
}
}
};
A default filter can be applied for the historic process instances search on the historic process definition view. Like this, it is possible to reduce the amount of instances which are being retrieved at the same time.
It is configurable, for how many days in the past instances are queried based on the start or the end time of historic process instances.
- The property
lastDays
specifies the numeric amount of days in the past based on the current time - The property
event
can be either set to ‘started’ or ‘ended’
Change CSRF Cookie Name
The default name of the CSRF Cookie is XSRF-TOKEN
. When using other applications within the
same-origin, the CSRF mechanisms could interfere with each other. To avoid the name conflict, you
can change the name of the CSRF cookie in the config.js
file as follows:
export default = {
// …
csrfCookieName: 'MY-XSRF-TOKEN'
};
Note: Please make sure to change the CSRF cookie name also on server-side.
Disable Welcome Message for new Users
First-time visitors are shown a message directing them to the camunda welcome page. If you do
not want this message to be shown, you can disable it by adjusting the config.js
as follows:
export default = {
// …
disableWelcomeMessage: true
};
Note: This does only affect the Cockpit login page. For other webapps, you need to adjust the corresponding config file as well.
User Operation Log Annotation Length
The default maximum length of a User Operation Log annotation is 4000 characters. Some databases have smaller limits. You can change the maximum allowed input length in the config.js
file as follows:
export default = {
// …
userOperationLogAnnotationLength: 4000
};
Note: This does only affect the Cockpit Operation Log. For the Admin Operation Log, check out the Admin Configuration.