Ich habe eben unsere Kunden angeschaut, dabei ist mir aufgefallen, dass auch 2 Kunden mit der Kundennummer 0 dabei sind. Hat das jemand bei sich schon mal beobachet oder weiß woher da kommt? Im Bugtracker hab ich nichts dazu gefunden.
Die Kunden scheinen sich nicht zeitglich registriert zu haben. (War mein erster Verdacht, analog zu dem alten Problem mit der Bestellnummer 0.)
(Haben noch ne alte Version 4.3.1, aber vielleicht weiß ja trotzdem jemand was darüber oder kann das für ne neue Version bestätigen.)
Das Problem tritt sporadisch auch bei uns im Shop auf: Pro Monat habe ich ca. 5 Kundenprofile mit oxcustnr=0.Bei den meisten dieser Datensätze ist zusätzlich oxshopid=’’.
Wir verwenden momentan Version [B]4.7.4[/B] .
Ein Muster kann ich bisher nicht erkennen:
Ein Teil der Profile sind Profile von Bestandskunden, m.a.W. ich kann aus der Bestellhistorie ersehen, welche oxcustnr die Kunden ursprünglich hatten.
Ein Teil der Kunden hat sich über das Shopfrontend registriert und hat bereits bei der Bestellung die Kundennummer 0.
Ein Teil der Kunden wurde im Backend registriert und hat bereits bei der Bestellung die Kundennummer 0.
Das Problem scheinen auch keine parallelen Registrierungen zu sein: oxcreate der benachbarten Datensätze ist jedesmal mindestens 15 Minuten früher bzw. später.
…irgendwelche Ideen, wonach ich suchen / debuggen kann?
Das Thema ist zwar schon eine Weile her, aber vielleicht hilft es ja noch jemanden.
Zu diesem Problem kommt es wenn zunächst händisch ein Nutzer ohne Passwort und danach ein weiterer Nutzer mit der gleichen E-Mail Adresse angelegt wird. Dadurch werden die Daten des zuerst erstellten Users überschrieben und die Kundennummer auf 0 gesetzt. Zusätzlich kann die Kundennummer dann nicht mehr über das Backend geändert werden!
Die problematische Stelle ist in der oxuser.php in der Funktion checkIfEmailExists zu finden:
}
elseif ( $oRs->fields[0] == $iShopId && $oRs->fields[2] ) {
// exists same login (with password) in same shop
$blExists = true;
break;
}
Wenn die Prüfung auf das Feld mit der ID 2 entfernt, tritt das Problem nicht mehr auf.
Ich finde das riecht nach einem Bug?! Der Fehler lässt sich in der aktuellen Version 4.8.6 reproduzieren…