Hi
We are in the process of uplifting from Pro 2.7 to Pro3.1 and have found contingent values are working differently and changing the selected asset type. We have a large number of contingent values and in many cases have configured the rule to use "<ANY>" for the Asset Type.
When we select a new asset to create and populate the value with contingency on it, the asset type is changed based on the first value found in the list where the asset type is not <ANY>.
Below is a snip of the rules and example. I selected a new asset of Underground Low Voltage, needing to populate the "nominal voltage", "Phasing" and "number of conductors". When a voltage of 415V is selected, the asset type changes to Overhead service cable low voltage - the first named asset type for 415, ignoring the <ANY> classes.
This is not the behaviour in Pro2.7 and although we can manually reset the asset type after populating these fields, is this really the expected bahaviour in pro3.1?
Accepted Solutions
We have been working with professional services on this one. They have created BUG-000171403 for this issue. Its a pretty buried config.
According to the product engineer, the CAV issue is ‘as expected’. This is expected behaviour because of the Auto-Apply option on the layer's table- screenshot below.
Behaviour is repro at 3.1.7 and 3.4 when the option is checked and not repro when the option is unchecked.
Prior to 3.2, this option was checked by default. At 3.2, the default was changed to be unchecked b/c of this unexpected behaviour. Which is why we don’t reproduce this on 3.3.
We have been working with professional services on this one. They have created BUG-000171403 for this issue. Its a pretty buried config.
According to the product engineer, the CAV issue is ‘as expected’. This is expected behaviour because of the Auto-Apply option on the layer's table- screenshot below.
Behaviour is repro at 3.1.7 and 3.4 when the option is checked and not repro when the option is unchecked.
Prior to 3.2, this option was checked by default. At 3.2, the default was changed to be unchecked b/c of this unexpected behaviour. Which is why we don’t reproduce this on 3.3.
