Conversation
MariekeGO
changed the title
| | [Correlation: Grouping method 'By alarm' has been removed [ID 45545]](xref:Cube_Feature_Release_10.6.8#correlation-grouping-method-by-alarm-has-been-removed-id-45545) | DataMiner Cube 10.5.0 [CU17]/10.6.0 [CU5]/10.6.8 | The grouping method "By alarm" is no longer available for correlation rules. | | ||
| | [Dashboards/Low-Code Apps: State timeline component will now use the primary key when requesting timeline data [ID 45600]](xref:Web_apps_Feature_Release_10.6.8#dashboardslow-code-apps-state-timeline-component-will-now-use-the-primary-key-when-requesting-timeline-data-id-45600) | DataMiner Web 10.5.0 [CU17]/10.6.0 [CU5]/10.6.8 | When a dashboard or a low-code app is connected to a DataMiner Agent running version 10.5.0 [CU17]/10.6.0 [CU5]/10.6.8, *State timeline* components will now refer to display column tables using the primary key when requesting timeline data using a `GetReportTimeLineDataMessage`. | | ||
| | [DataMiner Agents will now translate the primary key to the display key when receiving timeline data requests from a client [ID 45579]](xref:General_Feature_Release_10.6.8#dataminer-agents-will-now-translate-the-primary-key-to-the-display-key-when-receiving-timeline-data-requests-from-a-client-id-45579) | DataMiner 10.5.0 [CU17]/10.6.0 [CU5]/10.6.8 | When a client requests timeline data using a `GetReportTimeLineDataMessage`, it sends the primary key when referencing display column tables. However, for this type of table, the DataMiner Agent has to retrieve the data from the database using the display key. From now on, when a DataMiner Agent receives a timeline data request, it will first translate the primary key to the display key before returning the requested data. | | ||
| | [46489](xref:MediaOps_Plan_2.0.0#schedulingworkflow-designer-edit-locks-now-specific-to-each-session-id-46489) | MediaOps 2.0.0 | All lock-aware automation scripts in the Scheduling and Workflow Designer MediaOps apps now require a `Lock ID` input. | |
There was a problem hiding this comment.
MediaOps 2.0 will have other changes that could be considered as a breaking change related to scripts, maybe we need to make this more general. I believe this comes down to the question on what we want to support as being backwards compatible. But something that might be more important IMO, is the removal of the core scripts these could be used with the temp helpers (which we never officially communicated, but some users are making use of it). Not sure if we want to give a full list as this might take some time and we might overlook something that is not as trivial as the input arguments of a script.
There was a problem hiding this comment.
Any changes that potentially break existing setups should be included here. So if there's more in this MediaOps release, I do think we should include them too, but we could simplify them to one entry in the overview: we could add the different IDs for the breaking changes in the first column here, and add a generic description encompassing the different changes in the description column. That way there would be less of an overload of information for the user, but we do make sure everyone is sufficiently informed.
MariekeGO
changed the title
MariekeGO
changed the title
2 participants
Includes RNs 46471, 46472, 46474, 46483, 46489, 46512, 46566, 46573, and 46575