My designer just had some connection issues and somehow I ended up replacing a UDT definition with a folder with the same name while trying to copy the JSON of a View component and paste it... (this is another issue in itself, but one I'm sure no one will be able to reproduce).
Anyway, this was a TEST environment and I copied the UDT definition back from PROD. I noticed however that all instances of the UDT had their tag property overrides (excluding UDT parameters) removed! (Very bad!)
This also affects changing the UDT type of a UDT Instance; all tag prop overrides will be removed, regardless if the old tags still exist in the new UDT definition.
In v8.1.18, changing the UDT type would retain prop overrides!!! I will try to check earlier versions as I'm sure removing the UDT def never use to wipe this config.
This has created a lot of frustrating work to fix this up, as along with the accidental deletion of a UDT definition, I've also changed a number of UDT instance types to slightly different versions of the same thing (which should still have the same, if any, overrides applied)!
Sorry about the inconvenience. Unfortunately, deleting a UDT Definition has always had that behavior. Overrides aren't based on paths (tag names) from the UDT Definition, they're based on IDs of the members from the UDT Definition. If you delete a UDT Definition and add it back those original IDs are lost. Changing a UDT Type will retain overrides so long as the UDT Definition still exists.
This part isn't what I saw in 8.1.22 compared to 8.1.18. In 22, changing udt type wiped the tag prop overrides, where in 18 the overrides were retained.
Update:
I just tested this with a UDT Definition with nested UDT instances (of other UDT definitions). I had to change some nested UDT instance Type IDs, and some instances of the top level UDT definition's instances have overrides on the enabled prop of these nested UDT instances. I made the Type changes to the nested UDT instances, expecting the enabled prop overrides to disappear, but they didn't.
This only appears to be an issue when the top level UDT Instance (in the tag browser "Tags" tab, not the "UDT Definitions" tab) Type Id is changed. Not when the change is made to the Type Id of nested UDT instance within the UDT Definition.
it also happens that if I modify a instance parameter in a udt that is a nested of another udt, and therefore shown with a green dot, I can no longer remove it.
i need to recreate the instance from scratch.