You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vision 9.7 introduced GUID instead of Number/Subnumber as identification of objects.
Currently we handle these new Vision excels by internally converting the GUID kolom to a Number/Subnumber. This way the users can still use the old yaml files. The issue with this is that users of Vision 9.7 still need to have Number/Subnumber within their mapping files, even though they have never heard of these name. We need to implement the handling of GUID in a more meaningful way, without magic happening in the backend
The text was updated successfully, but these errors were encountered:
In the yaml configuration files, make the key field something like:
key:
- Number
- GUID
Users can leave this as is or remove one of them if they are certain. Internally, we do not do magic check on behalf user for GUID and instead crash on bad input.
Vision 9.7 introduced GUID instead of Number/Subnumber as identification of objects.
Currently we handle these new Vision excels by internally converting the GUID kolom to a Number/Subnumber. This way the users can still use the old yaml files. The issue with this is that users of Vision 9.7 still need to have Number/Subnumber within their mapping files, even though they have never heard of these name. We need to implement the handling of GUID in a more meaningful way, without magic happening in the backend
The text was updated successfully, but these errors were encountered: