Handle product deletions and variant assignments
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Es werden keine Dateien, Tests oder Einstiegspunkte genannt. Beginne damit, den Synchronisierungsablauf für Produkte und Varianten sowie seine Behandlung von SKU-Konflikten nachzuverfolgen, und kläre anschließend, ob Produkte oder nur Varianten gelöscht werden, ob Callbacks das Verhalten steuern und ob bestehende Daten migriert werden. Als abgeschlossen gilt die Aufgabe, wenn das gewählte Verhalten spezifiziert, implementiert und für die beschriebenen und die invertierten Fälle abgedeckt ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Java
- Sterne
- 41
- Forks
- 41
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus commercetools/commercetools-sync-java
-
Dependency DashboardOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 20/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 52/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 32/100
commercetools/commercetools-sync-java#1201 · 4 Kommentare ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
Alle Issues in commercetools/commercetools-sync-java
Ähnliche Issues
-
pdfium-drift
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Stirling-Tools/JPDFium#188 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
openremote/openremote#3487 · 1 Kommentar ·
-
Type/Bug U2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
wso2/product-is#28675 ·
Maintainer antworten meist innerhalb von 1 Tag
-
a:bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
erupts/erupt#460 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag