[BUG] Moving UDT location resets all overwrites


We’ve came across something annoying.
Whenever we move a UDT type from one folder to another, all instances of this UDT lose all of their overwrites, the UDT is completely reset.

We don’t think this should be needed, since renaming keeps all of the earlier configurations.


What Ignition version?
By moving, you mean you’re dragging and dropping the tag from one place to another?


Yes, f.e. I have two folders with an udt in:
I change myUDT to Folder2.

The consequence is that I need to delete my udtInstances and create them again, with all my overwrites gone. I don’t even have the choice to change the udt path myself.
With a rename, it all changes automatically, so I would think a re-organise would also be possible.

This should have been fixed in 8.1.12. That field should have a dropdown and even a binding menu in it.

Are you sure you are on 8.1.13? Also, by chance is this a zip install? I imagine it’s possible this could occur because the lib folder was not deleted prior to a version upgrade like described in the readme.

1 Like

Following up on Oscar’s comment, what you are describing is a legitimate issue that has been present in all 8.x versions of Ignition and a bug has been opened. What is happening is due to the UDT being moved, the ID of the UDT is changing and a cleanup process is removing the linked overrides in the UDT Instances. We shouldn’t be doing that, but I don’t think it has been caught until now because 8.1.12 was the first time we supported this via the Ignition UI.

There still seems to be an issue with what your screenshots are depicting and the version you are on. When using a 8.1.12+ version of Ignition, you should be able to change the Parent Data Type within the root of a UDT Instance and there should be a dropdown/editable field for that row in the Tag Editor.



Thanks for the replies.

Maybe good to note, we are using docker containers with a volume linked to /usr/local/bin/ignition/data, all just as described in the documentation.

But apart from that volume, 8.1.13 was a fresh docker install…