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
When opting for the "merge" mode for a Sync Rule, only non-null source values are being applied. I do not consider this being the correct behavior, null from Sync should still "win" over an existing properties. Only properties which have not been defined in the Sync Rule should be preserved on the original object.
The text was updated successfully, but these errors were encountered:
I do not consider this being the correct behavior, null from Sync should still "win" over an existing properties.
I strongly disagree with this thought.
We are extensively using the feature that null properties don't overwrite existing values.
Our properties mostly come from subkeys of json data from external source. In that case, when the key in json is not defined, it yields null in the property value, but giving this (non existent) value precedence makes no sense.
I think there should be a possibility to configure the precedence. Maybe by honoring Merge policy?
Replace - incoming null value has precedence
Merge - existing value is not replaced
@jiri-lunacek: this initial fix had a problem, that has been fixed later on. Which version are you using, and could you please provide a simple example showcasing your issue? Anonymized JSON-Export for your Import Source (just 2-3 rows), and a Director Basket with the related Sync Rule definition would be great.
Expected Behavior
When opting for the "merge" mode for a Sync Rule, only non-null source values are being applied. I do not consider this being the correct behavior, null from Sync should still "win" over an existing properties. Only properties which have not been defined in the Sync Rule should be preserved on the original object.
The text was updated successfully, but these errors were encountered: