Situation We encountered an issue during tag imports from our PROD to DEV Ignition servers, where tag instances were not retaining their own property values. Instead, they were inheriting the corresponding properties from their UDT Definitions. The situation occurs as follows: A user creates a new UDT Definition. The user then creates a UDT Instance based on that definition. The alarm is overridden on the instance, but not all alarm properties are changed — for example, Priority remains the same as in the definition. Later, the user updates the Priority in the UDT Definition. After exporting and importing tags, the instance alarm now takes on the updated Priority from the definition instead of maintaining its intended instance-level behavior. This has caused some of our alarm priorities to shift unexpectedly (e.g., from Low to Critical) because the Priority property was never written into the instance’s JSON. This also impacts the WebDev module, as the missing property in the JSON results in a null value being returned, even though the actual property on the instance should be Low. The underlying issue is that when alarms are overridden, not all alarm properties are serialized into the instance JSON. We will be updating all alarm configurations on our side moving forward to ensure that all relevant properties are explicitly set when overrides are applied. Feature Request We would like to request a feature that visually indicates which alarm properties are truly overridden at the instance level versus those still inherited from the UDT Definition. This would help integrators clearly identify which properties will appear in the instance JSON and which will continue to reference the UDT Definition values, reducing confusion and preventing unintended configuration changes during export/import operations.
