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
It might happen that product is created with wrong variant assignment. Example: Product with key 1: sku 1 Product with key 2: sku 2 Product with key 3: sku 3
At some point external data (CTP project, CSV, XML...) changes to: Product with key 4: sku 1, sku 2, sku 3
Currently this will lead to an error that Product 4 can not be created as sku 1, 2 and 3 are already in use in other products. Handling above scenario manually is time intensive and error prone and it gets very problematic if the change has to be distributed for example from master to multiple another CTP projects.
Expected Behaviour
Product 4 should be created with sku 1, 2 and 3 and all conflicting products or variants deleted.
To clarify
Should product 1,2 and 3 be deleted or only its variants? Consider for example that Product 1 could have also variant assigned with sku 4?
Shall sync decide what to do in this case or rather provide callback so that the user of the library has control?
Consider optional migration of existing data* from deleted variant product 1, sku 1 to recreated one product 4, sku 1 variant.
Existing data: data which might be set only once by another import process and is not available in new variant/product data. Good candidates are prices or other attributes/flags like product approval.
Consider other use cases if above example is inverted.
The text was updated successfully, but these errors were encountered:
At some point external data (CTP project, CSV, XML...) changes to: Product with key 4: sku 1, sku 2, sku 3
At this point it is important to know the intention of the user:
Does he want to delete the products with conflicting SKUs?
Or it was a mistake by the user to give duplicated SKUs for different products, because he didn't know its not possible?
So, to me, it seems it should be decided by the user how he wants to handle such case (as an option):
It should be an option since the sync generally doesn't delete not existing data (unless we want to introduce this?)
By default it should not sync this new product (Product with key 4), but rather trigger the error callback. Since we don't want to delete data in the case it was a mistake by the user.
Need to think if it needs it's specific callback, not the existing errorCallback
Description
It might happen that product is created with wrong variant assignment. Example:
Product with key 1
:sku 1
Product with key 2
:sku 2
Product with key 3
:sku 3
At some point external data (CTP project, CSV, XML...) changes to:
Product with key 4
:sku 1
,sku 2
,sku 3
Currently this will lead to an error that
Product 4
can not be created as sku 1, 2 and 3 are already in use in other products. Handling above scenario manually is time intensive and error prone and it gets very problematic if the change has to be distributed for example from master to multiple another CTP projects.Expected Behaviour
Product 4
should be created with sku 1, 2 and 3 and all conflicting products or variants deleted.To clarify
Should product 1,2 and 3 be deleted or only its variants? Consider for example that Product 1 could have also variant assigned with sku 4?
Shall sync decide what to do in this case or rather provide callback so that the user of the library has control?
Consider optional migration of existing data* from deleted variant product 1, sku 1 to recreated one product 4, sku 1 variant.
Existing data: data which might be set only once by another import process and is not available in new variant/product data. Good candidates are prices or other attributes/flags like product approval.
Consider other use cases if above example is inverted.
The text was updated successfully, but these errors were encountered: