Handle product deletions and variant assignments
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
No se nombran archivos, pruebas ni puntos de entrada. Empieza siguiendo el flujo de sincronización de productos y variantes y su gestión de conflictos de SKU; después, determina si se eliminan los productos o solo las variantes, si los callbacks controlan el comportamiento y si se migran los datos existentes. Se considera terminado cuando el comportamiento elegido está especificado, implementado y cubierto para los casos descritos y los invertidos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Java
- Estrellas
- 41
- Forks
- 41
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de commercetools/commercetools-sync-java
-
Dependency DashboardAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
commercetools/commercetools-sync-java#1201 · 4 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
Todos los issues de commercetools/commercetools-sync-java
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
github/copilot-sdk#2793 ·
Los mantenedores suelen responder en 1 día
-
Unify jpa4 into orm8Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
enhancement good first issue
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100