Hi,
I want to code a script to correct an issue in which children objects (Amplifiers) are incorrectly Masked in the system after their respective parent objects (CMC) are unmasked (operationally when a user masks a parent object, all children objects are masked as well).
Using the GetMaskedDMAObjectRefTrees call I'm able to get a hold of all the masked objects in the system, and with a lambda query, I'm able to extract all objects of type "amplifier". However, I'm not able to map each amplifier to its respective CMC (to be able to inspect this object's masked status and act accordingly).
List<CPETopologyItem> maskedAmps = tree.Select(item => (CPETopologyItem)item.Data).Where(data => data.SystemType.Contains("amp")).ToList();
List<DMAObjectRefTree> result = _cpeCollectorHelper.GetLinkedDMAObjectRefTreesThroughTopologyBulk(maskedAmps);
The result collection has a property called "Ancestors" that is returning an empty ObjectRef collection.
Do we have a way of easily inspecting the topology tree from the leaf to its node to map all the masked children to their respective AMPs?
Thanks Alberto, but I’m afraid the context is a bit different here. We’re talking about CPE objects, which are not holding any direct polling IP relationship between one another. The only link between these lies in the topology (incidentally, these links are built via Foreign Key relationships in CPE Manager tables, but those would be too complex and time-consuming to explore programmatically on an automation script). Hence the GetMaskedDMAObjectRefTrees calls, to simplify this operation.
The issue related to the masking of CPE items is solved in version 10.1 CU12 main release and 10.2.3 feature release
More information can be found in the following release note:
Parent EPM item unmasked while still containing masked sub-items [ID_32179]
General Feature Release 10.2.3 | DataMiner Docs
Not sure if this can help, Bruno
but would it be viable to run the check for elements with the same polling IP?
If so, you could possibly force the “unmasked” from the parent to all the child elements with the same polling IP?
This could be of use only if the alarm template is assigned to the parent element though – but I guess that if the alarm templates are assigned at children level, then you could indeed have masked children and unmasked parents as the expected behaviour