Hallo miteinander,
ich frage mich gerade, ob es nicht sinnvoll ist, die ganzen verschiedenen Probleme hier diskutierend zusammenzufassen, die den Bereich "order recalculation" im Admin betreffen? Da scheint ja ziemlich der Wurm drin zu sein, und man sollte es wohl ganzheitlicher betrachten, als immer nur Bruchstücke mit Hotfixes zu versehen, die überall verteilt liegen. Ich hatte schon meine Mühe, nur die ganzen Bugtracker-Relations dazu zu durchforsten, und wüsste nicht wirklich, wo man sich da am besten einklinkt in eine übergeordnete Debatte. Ich versuche mich mal an einem Überblick (alles auf den Admin bezogen):
1. Es besteht das generelle Problem, dass beim Neuberechnen der Bestellungen (order_main + order_articles) die aktuellen Artikel-Daten genommen werden, z.b. Preise, Discount, etc. und dadurch evtl. eine alte Bestellung ungewollt verändert wird.
Dazu gibt es mehrere Ansätze und vor allem dieses Jabommi-Modul, welches es wohl am besten vereint. Der Code macht für mich zumindest einen sinnvollen Eindruck. Am Ende dieses Eintrags kommt noch eine interessante Note von leofonic:
Damit hat er natürlich nicht ganz unrecht und verweist auch gleich auf ein anderes Modul, welches dies ermöglicht.
2. Das speziellere Problem mit den Auswahllisten (selectlists), welches entsteht, wenn man diese mit Varianten mischt. Die gewählten Values werden nämlich hintereinander (mit Leerzeichen getrennt) in oxorderarticles__oxselvariant gespeichert. Da für die Neuberechnung aber der String erst an "," und dann an ":" getrennt geparst wird, hat man am letzten Selectlist-Value die Variante kleben. Also werden evtl. Aufschläge nicht berücksichtig, da kein passender Value gefunden wird.
Dazu gibt es z.b. diesen Bug-Eintrag, wo auch ein Bugfix von Aggrosoft dranhängt. Der sorgt dafür, dass die Variante mit "," angehängt wird. Das ist eindeutig besser, aber auch noch nicht das Gelbe vom Ei, finde ich. Man darf an der Stelle eigentlich keine Varianten mit Selectlisten vermischen, also am besten auch gar nicht erst in oxorderarticles__oxselvariant speichern, oder mit einem eindeutigen Trennzeichen, was beim Parsen abgeschnitten werden muss/kann. Am konsequentesten wäre wohl ein eigenes DB-Feld.
3. In die gleiche Kerbe (nur ohne Varianten) schlägt eine Sache, die ich kürzlich selbst herausfand und bisher noch nicht meldete: Wenn man nämlich mal eine deutsche/englische Auswahlliste anlegt (mit abweichenden Values!) und damit einen Artikel im englischen Frontend bestellt, dann darf man nicht per deutschem Admin diese Bestellung aktualisieren, sonst wird es wirr, und die Auswahl kann sich ändern. Es wird dort also irgendwo nicht korrekt die Order-Language zum Vergleichen genutzt, sondern Tpl- oder Base-Language. Dadurch kann das "innerste" if in getOrderArticleSelectList() niemals greifen:
4. Nochmals ergänzend dazu greift dieses "if" von eben auch nicht, wenn in den Auswahllisten z.b. Aufschläge hinterlegt sind. Das wird dann nämlich hinter den Values auch in oxorderarticles__oxselvariant gespeichert, z.b. "+1,00 €", was ich ebenso für falsch, bzw. überflüssig halte. Dieses Feld ist so überfrachtet, dass man es insgesamt kaum noch sinnvoll parsen kann, und ich denke, da sollte man zuerst ansetzen.
5. Eine weitere Sache die mir auffiel ist, dass Artikel-Bundles einfach gelöscht werden (also die Zusatzartikel), wenn man Bestellungen aktualisiert. Dies hielt ich eindeutig für einen Bug und habe ihn auch hier eingetragen. Erst durch die dortige Relation wurde ich auf den ganzen Berg an weiteren Problem aufmerksam und entschloss mich, es hier zu sammeln.
So, das müsste es wohl erstmal gewesen sein. Wer macht nun einen kompakten (zweizeiligen) Bug-Eintrag daraus? ;) Im Ernst: was fängt man nun am besten mit diesen Erkenntnissen an? Jede Resonanz und Ergänzung ist herzlich wollkommen!
Mitmacher
ich frage mich gerade, ob es nicht sinnvoll ist, die ganzen verschiedenen Probleme hier diskutierend zusammenzufassen, die den Bereich "order recalculation" im Admin betreffen? Da scheint ja ziemlich der Wurm drin zu sein, und man sollte es wohl ganzheitlicher betrachten, als immer nur Bruchstücke mit Hotfixes zu versehen, die überall verteilt liegen. Ich hatte schon meine Mühe, nur die ganzen Bugtracker-Relations dazu zu durchforsten, und wüsste nicht wirklich, wo man sich da am besten einklinkt in eine übergeordnete Debatte. Ich versuche mich mal an einem Überblick (alles auf den Admin bezogen):
1. Es besteht das generelle Problem, dass beim Neuberechnen der Bestellungen (order_main + order_articles) die aktuellen Artikel-Daten genommen werden, z.b. Preise, Discount, etc. und dadurch evtl. eine alte Bestellung ungewollt verändert wird.
Dazu gibt es mehrere Ansätze und vor allem dieses Jabommi-Modul, welches es wohl am besten vereint. Der Code macht für mich zumindest einen sinnvollen Eindruck. Am Ende dieses Eintrags kommt noch eine interessante Note von leofonic:
Quote:
|
imho it is better to actually prevent recalculation than to fix it. |
2. Das speziellere Problem mit den Auswahllisten (selectlists), welches entsteht, wenn man diese mit Varianten mischt. Die gewählten Values werden nämlich hintereinander (mit Leerzeichen getrennt) in oxorderarticles__oxselvariant gespeichert. Da für die Neuberechnung aber der String erst an "," und dann an ":" getrennt geparst wird, hat man am letzten Selectlist-Value die Variante kleben. Also werden evtl. Aufschläge nicht berücksichtig, da kein passender Value gefunden wird.
Dazu gibt es z.b. diesen Bug-Eintrag, wo auch ein Bugfix von Aggrosoft dranhängt. Der sorgt dafür, dass die Variante mit "," angehängt wird. Das ist eindeutig besser, aber auch noch nicht das Gelbe vom Ei, finde ich. Man darf an der Stelle eigentlich keine Varianten mit Selectlisten vermischen, also am besten auch gar nicht erst in oxorderarticles__oxselvariant speichern, oder mit einem eindeutigen Trennzeichen, was beim Parsen abgeschnitten werden muss/kann. Am konsequentesten wäre wohl ein eigenes DB-Feld.
3. In die gleiche Kerbe (nur ohne Varianten) schlägt eine Sache, die ich kürzlich selbst herausfand und bisher noch nicht meldete: Wenn man nämlich mal eine deutsche/englische Auswahlliste anlegt (mit abweichenden Values!) und damit einen Artikel im englischen Frontend bestellt, dann darf man nicht per deutschem Admin diese Bestellung aktualisieren, sonst wird es wirr, und die Auswahl kann sich ändern. Es wird dort also irgendwo nicht korrekt die Order-Language zum Vergleichen genutzt, sondern Tpl- oder Base-Language. Dadurch kann das "innerste" if in getOrderArticleSelectList() niemals greifen:
Code:
if ( $oStr->strtolower($oSel->name) == $sOrderArtSelValue ) {5. Eine weitere Sache die mir auffiel ist, dass Artikel-Bundles einfach gelöscht werden (also die Zusatzartikel), wenn man Bestellungen aktualisiert. Dies hielt ich eindeutig für einen Bug und habe ihn auch hier eingetragen. Erst durch die dortige Relation wurde ich auf den ganzen Berg an weiteren Problem aufmerksam und entschloss mich, es hier zu sammeln.
So, das müsste es wohl erstmal gewesen sein. Wer macht nun einen kompakten (zweizeiligen) Bug-Eintrag daraus? ;) Im Ernst: was fängt man nun am besten mit diesen Erkenntnissen an? Jede Resonanz und Ergänzung ist herzlich wollkommen!
Mitmacher