These change logs document all relevant changes for the Cumulocity cloud deployments.
The following types of change are included:
Displaying all changes since December 6, 2023
This is a follow-up on a recent announcement about migrating the Microservice SDK to Spring Boot 3.
Starting from version 10.20.155.0, the Microservice SDK is now using Spring Spring Boot 3.3.x, which marks the end of the recent dependency updates published in quick succession. Notice that along Spring Boot, most other dependencies were also updated to eliminate all security vulnerabilities those dependencies had.
Because of the amount of changes we also published intermediate versions to help with the upgrade process of all the applications using the SDK.
Version 10.20.150.1 contains a fix for the previously announced version 10.20.150.0 for applications configuring additional servlets. Use this version when updating your application to Spring Boot 3.0. For details refer to the Spring Boot 3.0 Migration Guide.
Version 10.20.151.1 is based on Spring Boot 3.1 and is recommended as an intermediate step to limit the amount of changes done at once. For details refer to the Spring Boot 3.1 Migration Guide.
Version 10.20.153.1 is based on Spring Boot 3.2 and is another recommended intermediate step. For details refer to the Spring Boot 3.2 Migration Guide.
Finally, when upgrading to version 10.20.155.0 based on Spring Boot 3.3, refer to the Spring Boot 3.3 Migration Guide.
When deleting or modifying a global role, an administrator can now ensure that changes take immediate effect by using a new option to log out all users assigned to that role.
To provide developers with more guidance on how to use filter chips in their applications, codex examples for filter chips have been added. The examples demonstrate how to implement filter chips in various scenarios and highlight best practices. With these new codex examples, developers can more easily understand and leverage filter chips in their own applications, enabling them to create more intuitive and user-friendly filtering experiences.
To support developers in utilizing hookServices in their applications and plugins, documentation and examples have been added to the Cumulocity Codex. The documentation provides an overview of the hookServices API and suggests use cases for it. It also includes a code sample demonstrating widget plugins sharing a common state via an externally injected service. With these new resources available, developers should find it more straightforward to integrate hookServices into their projects, enabling them to extend and customize functionality as needed.
Previously, when an error occurred on logging in via SSO, the plain HTML error text was displayed in the browser.
With this change, optional Redirect to the user interface application configuration has been added which allows displaying the error text as a standard UI error message.
The new configuration parameter is optional and does not affect current SSO configurations.
Using this option requires updating the “Valid Redirect URIs” in the authorization server with the value “<tenant_domain>/apps/*”. For details, refer to Custom template configuration.
The device profiles view has been migrated to a data grid. The data grid provides a more modern and user-friendly way to view and manage device profile items compared to the previous list view. The data grid offers enhanced features such as sorting, filtering, and pagination, making it easier to find and work with specific items.
In previous versions, the operation c8y_ua_command_ProcessMappingsForDeviceValues failed entirely if any single mapping failed. The new behavior allows the operation to continue reading nodes even if some nodes cannot be read due to bad status codes. Although the operation will still be marked as failed, all readable nodes will be mapped. Additionally, the result and failure messages have been improved to indicate which nodes failed and which were successful.
The DTM plugins component now includes a new asset properties widget module, which enhances the functionality of the existing “Asset properties” widget. This includes:
The module is designed for easy integration into any Cumulocity application. In future releases, this widget will replace the current “Asset properties” widget across all Cumulocity applications.
To improve the documentation of UI components, a Codex example has been added for the CountdownInterval component. This example demonstrates how to use the CountdownInterval component in an application, showcasing its functionality and configuration options. Developers can now refer to this example to better understand how to integrate the CountdownInterval component into their projects, making it easier to implement countdown functionality in their applications.
As part of continuous improvement efforts, the illustrations used in various sections of the Cockpit user interface have been updated. The new illustrations provide a fresh and modern look while still effectively conveying the intended message or concept. This change enhances the visual appeal and user experience of the Cockpit interface without impacting any functionality or existing user workflows.
The Apama Docker images are now available at public.ecr.aws/apama, and can be viewed at https://gallery.ecr.aws/apama/. Previously, they were available at softwareag/, and viewed at https://hub.docker.com/u/softwareag.
Within any Dockerfiles that use the Apama images, you will need to change FROM softwareag/<IMAGE>:<TAG> to FROM public.ecr.aws/apama/<IMAGE>:<TAG>.
The location of Apama within the image has been moved from /opt/softwareag to /opt/cumulocity. Existing images remain unchanged.
Previously, warning messages were logged when input events were dropped by an Analytics Builder model because they were delayed beyond the reorder buffer duration. In addition to the warning messages, an alarm is now raised when input events are dropped. The alarm provides improved visibility compared to relying on viewing log messages, which is especially useful for multi-tenant Streaming Analytics microservices where it may not be possible to view the logs at the parent tenant. See Analytics Builder dropped events for more details on the alarm.
This is a follow-up on a recent announcement about migrating the Microservice SDK to Spring Boot 3.
Starting from version 10.20.150.0, the Microservice SDK is now using Spring Spring Boot 3.0.x. Please follow the Spring Boot 3.0 Migration Guide to upgrade your applications when updating to that or later versions of the SDK. To make the migration process easier we recommend first updating to version 10.20.134.0 with JDK 17 and later to version 10.20.140.0 with Spring Security configuration changes, if it was not already done.
To provide more clarity and improve validation when configuring widgets, type information has been added to the widget configuration. Previously, the widget configuration did not include any type information, which could lead to confusion and misconfiguration. With this change, each configuration property now specifies its expected type, such as string, number, or Boolean.
To enhance the user experience and functionality a new select component has been introduced. This update includes significant changes that may require action from developers.
Key features:
c8y-select component will need to be updated.Required actions: Developers must select one of the following options:
c8y-select components to the new interfacec8y-legacy-select to maintain the current functionalityTo improve the usability of the alarms overview, filtering for specific alarm types has been added. Users can now select which alarm types they want to see in the overview by using the new filter options. This allows users to focus on the alarms that are most relevant to them, making it easier to identify and address critical issues in a timely manner.
The deprecated ILabels interface has been removed from the Web SDK. Instead, the ModalLabels interface is used.
For better clarity, the Position in navigator field in the dashboard settings has been renamed to Position in tabs.
As part of ongoing efforts to modernize the look and feel of the Cumulocity UI, the branding colors and the logo have been updated and aligned with current design trends. For example, the brand logo has been relocated to the bottom of the navigator to enhance user focus on navigation elements, reduce visual competition with the app icon, and optimize space utilization. This change provides a refreshed visual appearance throughout the Cumulocity UI, without impacting existing functionality or user workflows, but it could imply a need to review any custom branding applied as some design tokens have been updated or removed. Additionally, the link color is no longer related to the branding color and needs to be updated if a branded link color is wanted.
As part of keeping the Cumulocity platform up-to-date with the latest web technologies, Cumulocity has been upgraded to use Angular 18. This upgrade brings the latest features, performance improvements, and bug fixes from the Angular framework to the Cumulocity platform. The upgrade to Angular 18 should be largely transparent to users, with no visible changes to the user interface or existing functionality. However, any custom widgets or plugins developed for previous versions of Cumulocity may need to be updated to ensure compatibility with Angular 18.
The LWM2M specification allows devices to send an empty payload when there is no data to report. In case of an empty payload, no content-type is required. Previously, LWM2M agents would reject messages with an empty payload and no content-type. Now, these messages will be accepted and processed as intended.
To improve readability and consistency, the titles of device management application now use title case (Device Management) instead of sentence case (Device management). The functionality of the entities remains the same, only the casing of the titles has been modified.
In earlier LWM2M agent versions, device location updates occurred only when the device provided complete location object data. Now, updates happen whenever both latitude and longitude resources are reported together.
In the past, the bulk action control did not receive the IDs of the selected items, which made it impossible to display a bulk action conditionally based on the subset of selected items. With this change, the selected item IDs are now passed to the bulk action control showIf function.
The wizard for bulk registering LWM2M devices to Cumulocity provides default bulk registration templates. These templates have been updated to reflect new properties including the X.509 security mode.
When creating a duplicate of a local smart rule, it is now possible to select an asset from outside of the hierarchy. A duplicate of the rule is now created in the context of the selected asset.
Previously, when creating a new dashboard, it would open in view mode which required an extra click on the Edit button to start editing the dashboard. With this change, newly created dashboards now directly open in edit mode. This allows users to immediately start editing and configuring the new dashboard, saving them a click and making the user experience more intuitive.
This is a follow-up on a recent announcement about migrating the Microservice SDK to Spring Boot 3.
As a second step of this process, starting from version 10.20.140.0, the Microservice SDK is now using Spring Security 5.8. This change enabled a migration preparing for Spring Security 6.0 to be performed in the Microservice SDK following this migration guide. We recommend all users of the Microservice SDK to also follow that guide when updating their applications using the updated version of the SDK.
Note that following the changes in the MethodSecurityExpressionHandler configuration described here, the methods provided by com.cumulocity.microservice.security.service.SecurityExpressionService that were previously configured using a custom SecurityExpressionRoot extension, are now available via an independent bean definition named c8yAuthz. This means that, for example, the expression isCurrentTenantManagement() will no longer resolve and needs to be prefixed by the bean name instead @c8yAuthz.isCurrentTenantManagement(). This allows customers to easily add their own security expression extensions, if needed.
To improve the user experience in Analytics Builder, the On value change option of the Mode parameter in the Pulse block has been renamed to On value change (excluding to false). In addition, the block reference has been updated to clarify that for a boolean input, a pulse is only sent when the input changes to true (not false).
The text fields in the “Send measurement”, “Create alarm”, and “Send event” functionalities used to be limited to 100 characters. This limitation has been removed, allowing you to enter longer text without restrictions.
The configuration repository has been migrated to a data grid. The data grid provides a more modern and user-friendly way to view and manage configuration items compared to the previous list view. The data grid offers enhanced features such as sorting, filtering, and pagination, making it easier to find and work with specific configuration items.
The Extract Property block in Analytics Builder now includes a new optional checkbox called Ignore Separators In Property Path. This allows you to extract a property that has a separator such as a period (.) in the property name.
For example, if the Ignore Separators In Property Path checkbox is selected and the Property Path parameter is specified as location.city, then the property name location.city is extracted from the input value.
For compatibility, the previous behavior remains as the default, that is, the new checkbox is not selected by default.
The deprecated JWT authentication with Cumulocity has been removed. This change will only impact you if your organization used an early version of single sign on (SSO) on Cumulocity. For details, refer to the earlier announcement.
In a future version, we will update Angular to version 18 and update our base branding. This update brings improvements and new features, but may also introduce breaking changes that could impact your existing implementations. When updating to this new version, please verify your branding, especially the logo position, as it has been modified.
To ensure a smooth transition to Angular 18 and help you to adapt your implementations, we will provide an upgrade documentation when this change happens. This documentation will help you navigate through the changes and update your codebase accordingly.
This is a follow-up on a recent announcement about migrating Microservice SDK to Spring Boot 3. As a first step of this process, starting from version 10.20.134.0, the Java SDK and Microservice SDK are now both using Java 17 both on the source as well as the runtime level. This means that using Java 17 is now a minimum requirement for using the Microservie SDK.
We are pleased to announce an upcoming update to the Spring Boot version used in the Microservice SDK. The new version will be Spring Boot 3.3.3, which will also bring updates to several third-party libraries and frameworks. These mandatory changes will include:
Minimum required Java version: 17 (currently Java 8)
Jakarta EE 9+ baseline
Spring Security: 6.3.3
Spring Framework: 6.1.12 (currently 5.3.24)
HTTP Client: 5.3.1
Impact: Each of these updates may impact your microservices, potentially requiring code changes.
Rollout: The update will be available in Continuous Deployment (CD) versions starting in Q4 2024 and in versions of the next annual release 2025. A separate announcement will be made to confirm the CD version containing the change.
Migration Resources: Refer to the following guides for assistance with the changes:
Notifications 2.0 subscriptions may specify the Cumulocity APIs to subscribe to, for example alarms or measurements.
Subscriptions may use a wildcard value (*) for the API selector, indicating that the subscription should include all available APIs.
If the API selector is omitted from a subscription request, it is treated as equivalent to using the wildcard value.
Currently, a tenant context subscription using the wildcard API selector will deliver updates from a subset of the available APIs. See the Notifications 2.0 subscription REST API documentation for details on the current tenant context subscription behaviour.
In future, such subscriptions will also deliver updates from the operations API.
This applies to subscriptions that were created before the change is enabled, as well as new subscriptions.
For example, after this change is enabled, an application that POSTs the following request to the /notification2/subscriptions endpoint may receive operations updates, regardless of when the subscription was created:
{
"context": "tenant",
"subscription": "testSubscription",
"subscriptionFilter": {
"apis": [
"*"
]
}
}
Applications using the wildcard API selector in tenant context subscriptions should be prepared to receive operations updates in addition to the updates they were previously receiving.
To avoid disruption, application developers should either:
ensure that their applications can handle operations updates, or
include an API selector
before this change is enabled.
The change will be enabled in the Cumulocity CD deployments no earlier than January 15, 2025. It will also be included in the 2025 yearly release. A further announcement will be published when the change is enabled.
A new subassets view module has been added to the DTM plugins component, which includes official DTM plugins and enables integration with both default and custom web applications. This module allows users to efficiently view and manage subassets. In future releases, it will replace the existing subassets view in other Cumulocity applications.
In the Subassets page, instead of the key of the default location property, its label is displayed for improved user experience.
For simplicity, “model” has been removed from the asset model sample names. Additionally, the descriptions and UI layout have been improved to ensure consistency.
Real-time updates have been improved to ensure that changes made by concurrent users to asset models are immediately reflected.
The DTM microservice has been renamed from “dtm-ms” to “dtm”. REST endpoint paths have been updated accordingly, replacing the “dtm-ms” segment with “dtm”. Users will not perceive any change. However, they may need to manually unsubscribe and uninstall the older version.
The subasset module, which was originally imported from the ngx component, has now been replaced with the official plugin from the dtm-plugins component. This change maintains all existing functionality while enabling easy integration of module with both default and custom web applications.
In the New asset model page, the Asset models and Asset model samples tabs have been removed for a more focused user experience as they are not required for creating a new asset model.
The Platform service-level agreement now provides a more precise definition on how Cumulocity manages the Cumulocity platform service for your tenants and what might be possible limitations and responsibilities that you should be aware of.
Previously, the Alarm Input and Event Input blocks did not use the the correct source time for an update operation when the Ignore Timestamp checkbox was not selected. Instead, the creation time of the block was incorrectly used to schedule the input events. This has been fixed and alarm and event updates are no longer missed by the model. When the Ignore Timestamp checkbox is not selected, the input blocks now use the last update time of the block to schedule the input events in case of update operations.
In the user documentation, information has been added on how to register and delete LWM2M devices using the REST API, see Registering LWM2M devices.
The custom firmware update URL has been replaced with a standard firmware definition that points to an external URL. Right now this parameter is still available and takes precedence over any other option, but it will be removed in future LWM2M agent versions.
Cumulocity provides connectivity monitoring capabilities for which a required interval needs to be defined. For LwM2M device, this is automatically set by the LWM2M agent based on the registration lifetime. However, if the value is set manually, it will be overwritten by the LWM2M agent after each registration or registration update. This behavior can now be disabled both globally or for specific devices, allowing users to define the required interval independent of the registration lifetime.
Previously, the LWM2M agent could only cancel observations using the “reset” method. With this change, the LWM2M agent can now also use “GET with observe” method to cancel observations.
To improve security, the LWM2M service can now ignore packets from predefined source ports.
Previously, the LWM2M agent supported write operations in “Replace” mode only. With this change, write operations can now also be sent in the “Partial Update” mode using the “writep” command.
To improve the user experience and to ensure consistency, the firmware list has been migrated from a simple list view to a grid view.
The branding editor allows users to create a unique and consistent branding across their applications, improving the overall user experience and making it easier to align the application’s appearance with corporate design guidelines.
We have made significant improvements to our branding editor, offering a more robust and user-friendly experience for managing brand identity across multiple applications.
New functionalities:
Functional improvements:
To simplify plugin development and deployment, support for module-less plugins has been added. With this change, plugins no longer require a module to function, allowing to implement and deploy plugins more easily. This impacts plugin developers who can now create plugins without the overhead of a module and users who can benefit from a wider variety of available plugins that are simpler to install and use.
To improve the user experience, the links in the model editor and EPL editor for renaming a model or EPL app have been renamed to Model settings and App settings. Previously, these links displayed the name of the model or app. These names are now displayed at the top of the editor page.
Previously, adding Cumulocity schematics to Angular projects initialized with the standalone flag set to true failed. This issue has been addressed. Now, when integrating Cumulocity schematics into standalone Angular projects, the standalone flag is automatically set to false. Full support for standalone projects will be implemented in future updates. This interim solution allows developers to use Cumulocity schematics with projects initially set up as standalone, though with standalone features disabled.
The Add Asset module has been moved from the Digital Twin Manager (DTM) application to the newly created DTM plugins component. This component consists of modules from DTM as official plugins, enabling their integration into default and custom web applications. The Add Asset button will continue to be available in the standard DTM interface.
To ensure users agree to the service terms for microservice deployment when uploading a microservice, a new text acknowledgment has been added to the microservice upload dialog.
Previously, a new user received an email with a link to set their password. Now when the checkbox Send password reset link as email is cleared, the User must reset password on next login option is selected by default. This means the new user must change their password during their first login.
The Expression block in Analytics Builder has been updated to allow you to concatenate string and non-string values, similar to EPL. This is useful, for example, if you want to specify an expression like the following: “The current temperature is " + input1 + " degrees Celsius”.
The Counter block in Analytics Builder has been updated to allow you to set a maximum value for each counter independently. This change was made because it was difficult and cumbersome to create periodic behavior in Analytics Builder, and it gives more control over counting in general. The following new parameters are available for this purpose:
The counter in question can then loop. Depending on the setting of the corresponding checkbox, the counter either resets its corresponding output port (Count or Number Same) to one, counting the first input after reaching the maximum value, or it stops counting when reaching the maximum value and must then be reset manually. For compatibility, the previous behavior remains as the default. Note that the Reset input port resets both counters. If this is a problem, you must use a separate Counter block for each counter. See the description of the Counter block for detailed information on the new parameters.
Offloading pipelines may fail permanently, for example, due to an invalid offloading configuration or a wrongly configured data lake. In a future release Cumulocity DataHub will automatically stop permanently failing offloading pipelines.
Cumulocity now supports the ability to infer the full certificate chain from an intermediate certificate, enabling devices that are only able to send the device certificate to connect to Cumulocity. For full details refer to Device authentication.
The “Alarm list” widget is used to display alarms in dashboards and other places in the Cumulocity UI. Previously, child alarms were always shown which could lead to information overload for users monitoring many alarms. With this change, a new toggle has been added to the widget configuration which allows showing or hiding the child alarms in the alarm list. This provides users with more flexibility to customize the widget to their specific use case and makes it easier to focus on the relevant top-level alarms.
The Cockpit application has been split into further plugins. This allows admins to tailor the Cockpit application to their needs without any coding effort. They can now easily remove certain plugins and thus certain features which they do not want to include in their Cockpit application. The following plugins are now available:
To enable application developers to more easily select alarms and events in their custom applications, a new reusable alarm and event selector component has been introduced. For details refer to the Cumulocity Codex.
Starting with Q1 2025, the Cumulocity platform enforces name and context-path manifest fields naming restrictions for custom microservice deployments. You can verify the correctness of your microservices by uploading them via the UI or REST API. If this is successful, your configuration is correct. For details on the name and context-path fields, refer to Microservice manifest > Settings.
To improve the documentation around internationalization, the “Internationalization” section of the Cumulocity Codex was updated. The changes provide more detailed information and guidance on how to handle translations and localization in applications. This impacts developers who want to make their applications available in multiple languages, giving them better resources to understand and implement internationalization best practices.
To improve security, user administrators can no longer explicitly set passwords for device users. This change prevents an attacker from having access to all device users, in case the administrator account is compromised. In case of losing the device password, the device must be registered again.
Making Cumulocity more secure we have added a check on upload to ensure microservice settings do not contain any line feed characters such as HttpGet, exec, and TCPSocket of type Probe, aligned with items in the Kubernetes PodSpec.
The documentation of the SNMP device protocol has been moved from the user documentation to the public GitHub repository: cumulocity-examples.
In the Asset model samples page, the “Wind Turbine” and the “Solar Power Plant” sample asset models have been added. These samples serve as an example to help you quickly get started with your own asset modeling.
Improving the security for the Microservice SDK we have decided to restrict the initial configuration of the Spring Boot actuator endpoints (POST access to the /loggers endpoint) to the administrator roles only.
The version numbers for the frontend and backend are no longer displayed in the right drawer of the Streaming Analytics application. Instead, details on all components can now be downloaded via the Download platform details button. This change simplifies the UI for the majority of users.
The link from the Cumulocity UI to the documentation for the Edge component was previously outdated. With this change, the link has been updated to point to the correct location in the documentation. This ensures that users can easily access the relevant information and guidance for using the Edge component without encountering any broken links or navigation issues.
The Service-level agreement for Microservices deployment now provides a more precise definition on what is included in the Microservice Hosting functionality for your custom microservices. It also describes how you can benefit best from the service.
The Home page has been enhanced so that you can investigate the current status of your offloading pipelines. The status includes which offloadings are currently running, which ones have recently failed, and which ones have completed successfully.
The editor for managing additional result columns of an offloading pipeline has been enhanced with convenience tooling for exploring nested data. Using sample data retrieved from the corresponding Cumulocity base collection, you can interactively browse through the structure of the data in order to determine which specific sub-structure you want to offload.
Previously, icons that could not be used when a model was active (that is, in read-only mode) were shown as disabled in the model editor’s toolbar. To improve usability when in read-only mode, icons that cannot be used (such as the save icon) are no longer displayed in the toolbar.
When adding a new model or when editing the name of a model in the Streaming Analytics application, you can now resize the Description field. This is helpful when editing or viewing a longer description, including the case of the samples that have very detailed descriptions.
As published earlier, see release 10.15, Cumulocity has announced the availability of Microservice API version 2 and the deprecation of API version 1 to comply with new security requirements. Microservice API version 2 provides an improved microservice container security context restricting the invocation of privileged Linux Kernel APIs. Today Cumulocity announces the creation of alarms when subscribing a tenant to microservices still using API version 1. In Q3 2024 Microservice API version 1 will be removed from Cumulocity SaaS instances and in the yearly 2025 release. If not done yet migrate your microservices to API version 2. Refer to Microservice migration to API version 2 in the user documentation to understand how to accomplish this. Otherwise your microservices in Cumulocity SaaS instances may stop functioning in Q3 2024 or in environments using the yearly 2025 release.
For the offloading of the measurements collection Cumulocity DataHub offers a TrendMiner mode, which is designed for the specific interaction with TrendMiner. This mode is deprecated and will be removed in a future release as the integration with TrendMiner will be discontinued.
The services component was previously an integral part of the default Device Management application. With this change, the functionality for services has been modularized into a plugin. By default, users will still have access to services within the Device Management application. However, if not needed, the functionality can be removed by deactivating the plugin. This approach offers flexibility for users who may or may not require certain functionalities within the application.
The Advanced Software Management functionality was previously an integral part of the default Device Management application. With this change, the Advanced Software Management service has been restructured to function as a separate plugin. It remains included by default but now offers the flexibility to be added or removed as needed.
Previously, alarms could not be shared as they had no unique link to reference them, for example in mails or chats. With this change, each alarm gets an unique link. This allows to share alarms and navigate between alarms more easily.
In some situations, managed object operations in Cumulocity could take an unexpectedly long time without providing any feedback to the user. For more transparency, an alert is now shown in the UI when a certain operation exceeds a specific duration.
If a user upgraded one of the default web applications (for example, Cockpit) after it had been cloned, it would only include the plugins that the application had offered during the initial clone/installation of the application. If additional self-imported plugins were introduced in the upgraded version, these would not have been present when using the application.
This especially caused issues when features of applications which were previously present as standard Angular modules were migrated to self-imported module federation plugins, as these features were missing until the plugin was manually installed to the application.
To fix this issue, an exclude list for these self-imported plugins has been utilized, in addition to the already existing include list used for the usual plugins.
Previously, the asset selector did not show the currently selected element by default, requiring users to always manually search for and select the desired asset. With this change, the asset selector now automatically displays the selected element when opened. This improvement streamlines the user workflow by eliminating the need to repeatedly locate and select the same asset, saving time and effort.
To provide a better user experience when displaying hierarchical data in a data grid, expandable rows have been introduced. With this change, users can now expand or collapse rows in the data grid to show or hide nested information. This allows for a more compact and organized presentation of data, especially when dealing with complex hierarchies or large amounts of related information. The expandable rows feature seamlessly integrates with the existing data grid component, providing a consistent and intuitive way for users to interact with and navigate through the displayed data.
Documentation has been added on how to style the shell application via plugins. For details, refer to the Cumulocity Codex.
The Codex documentation provides information about developing applications with the Cumulocity platform. To make it easier for users to understand and use dynamic forms in their applications, the Dynamic forms page in the Codex documentation has been extended. For details, refer to the Cumulocity Codex.
A dashboard manager view has been added to streamline the management of device type dashboards. This view aggregates and displays a list of all dashboards assigned to specific device types. From this list, dashboard templates linked to device types can be viewed, edited by navigating to a particular instance and templates can also be deleted if needed.
As announced earlier, a redesign of the alarms feature has been introduced with both visual and functional enhancements.
Visual and UX enhancements:
Functional improvements:
As announced earlier, the report module has been extracted from the Cockpit application and added as a separate plugin.
This is a first step towards removing the reports module entirely and replacing it with the dashboard manager.
This change might be a breaking change as the reports module is no longer a part of @c8y/ngx-components/context-dashboard, but is be part of @c8y/ngx-components/report-dashboard.
This change does not affect the layout and UX of the Cockpit application nor does it add any new functionalities. As a side effect, a performance improvement might be noticed as reports from now on will be loaded lazily (that is, only when users navigate to the Reports page).
To provide more flexibility for configuring applications, Cumulocity now supports loading dynamic options from application-specific paths. With this change, each hosted application will load its dynamic options from a path that includes the application context path. This allows application-specific configurations to be loaded dynamically.
The Cockpit application would now load it’s dynamic options from: /apps/public/public-options@app-cockpit/options.json while it previously did so from: /apps/public/public-options/options.json.
This change was done as a preparation for upcoming changes to the branding manager.