Context: These elements are duplicates of each other. The left was first created, the right side is a duplicate of the left. I find it difficult to understand that the grey nodes are still have alarms/Normal states below it. This makes it very difficult to understand from an users perspective.
https://docs.dataminer.services/develop/devguide/Connector/UIComponentsTreeControlAlarmBubbleUp.html The documentation describes that “There is no alarm for a parameter in “Normal” state, so there will be no bubble-up: parent levels will be displayed in gray/Undefined instead of green/Normal.”
I fail to understand how this is possible and it makes no sense to have no alarm on the top level visible form the start. Because left and right should be the same, but they give a different vision on the user.
Could someone explain the vision after this flow?
As discussed with the product owner of Data-Insights, this can cause misconception in the mind of an user. Therefor documentation will be adjusted to incorporate the findings. This to make sure people will understand the reaction of Dataminer when this option is enabled/disabled.
Alarm bubble-up in the tree control is based on (hidden) properties on alarms. When an alarm is generated, a property is added which contains the primary key of every parent/ancestral row in the path. For example, the critical alarm on interchangeable-data-found should contain a property with the PK of eti-switch and the PK of local-output. The exact property name can be found in the connector of this element. For example:
SL_TREE_INFO_DEMO = “SL_Table_1000,4;SL_Table_2000,1;SL_Table_3000,5”
To investigate this issue, I would first take a look at these properties (using the SLNetClientTest tool, or with a Cube debug session) and also verify if the primary keys of the duplicated data are the same.
The alarm bubble-up should also start working again if the alarm is recreated (e.g. remove/reassign the entire alarmtemplate or enable/disable the rule).
Edit: some additional information on the workings of the bubble-up to explain why “it makes no sense to have no alarm on the top level visible form the start”:
Cube does not subscribe on the full tables that appear in the tree structure. For large (partial) tables this would not scale well (imagine a million cable modems as leaf nodes). Instead, whenever a parent node is expanded, a filtered subscription is made for the child nodes. Cube is only subscribed to the rows that are visible on screen. So if there are only active alarms on leaf nodes, and it takes 5 hierarchical levels between a root node and a leaf node, Cube still needs to be able to display the alarmcolor even if that root node is collapsed. That is why the linking is done based on information present in the active alarms – Cube is already subscribed on that for the global alarmconsole.