hä ?? sorry steh jetzt hier echt auf der Leitung, ich hab zumindest in meinen Benutzergruppen keine einzige, die “nicht registrierten” zusteht - Deutschland geht net, Rechnung geht net, kleiner, mittlerer, großer Umsatz geht net, was ist denn “nicht registriert” ??
Gruppe noch nicht bestellt hab ich keine.
Ich habe das gerade im Demoshop nachvollzogen.
Normaler Kunde gehört (nach Accounterstellung) folgenden Kundengruppen an:
customer
domestic customer
medium turnover
Kunden ohne Kudenkonte:
domestic customer
not yet purchased *1
Also die gefährlichen Zahlarten nur den ‘customer’ zuordnen und nicht auch noch den andern beiden.
… und natürlich testen, testen, testen.
Edit: ich habe im Demoshop domestic und not yet purchased aus Kreditkarte rausgeschmissen.
Ergebnis: Kunde mit Konto hat Kreditkarte und ohne Konto nicht.
*1@Martina: Ist das Update nicht richtig gelaufen? Not yet purchased ist im Demoshop vorhanden.
ein nicht vorhandener kunde ist in garkeiner benutzergruppe, sobald man IRGENDEINE benutzergruppe (und seis eine leere) zuordnet gilt das nicht mehr für unregistrierte.
ist schon ein lang von mir geäusserter verbesserungswunsch das es auch gruppen für unregistrierte gibt.
siehste, egal wie mans dreht und wendet, es ist SO jedenfalls nicht korrekt händelbar
hier sollte Oxid UNBEDINGT mal eine vernünftige Lösung für alle bringen, die vor allem kostenschonend und trotzdem gesetzeskonform ist.
Es kann wirklich nicht im Sinne des Erfinders sein, daß bei jeder Bestellung eines unregistrierten Kundens Boniprüfkosten entstehen, gleichfalls kann es nicht wirklich Sinn machen, wenn man diese Unregistrierten nicht von Zahlarten ausschließen kann um dem Kundenkonto ein “pluspunkt” zu bieten.
Hi,
mir bleibt die Spucke weg wenn ich lese, dass der Shop schonmal für mich irgendwelche Daten löscht. Das ganze Shopsystem basiert doch wohl auf der OXID der Usertabelle. Jetzt ist irgend ein Schlaumeier darauf gekommen, diesen wichtige Schlüssel zu ändern - wegen eines Datenlecks.
Kleiner Nebenefekt: diese Verknüpfungen können verloren gehen:
Jetzt diskutieren hier Leute rum, dass ich jeden Kunden, der sich kein Passwort vergeben will unverzüglich aus der oxuser-Tabelle löschen muss. Was ist denn das für ein Blödsinn!? Für mich sind die Einträge diese Tabelle auftragsbezogenen Adressdaten, und es ist mir herzlich egal ob der XT die in der order-Tabelle oder in einer Textdatei speichert. Oxid hat das schon immer so gemacht und das war auch immer in Ordnung so.
Warum geht man nicht anders herum an die Sache ran und versperrt einfach die Ausgabe kritischer Daten (Historie etc.) für Kunden ohne Passwort. Fertig - schon gibt es auch kein Datenleck.
Übrigens: ich kann Martina gut verstehen. Ein Verkaufsargument für die EE war und ist ja immer diese tolle Zugangsmöglichkeit für Callcenter-Agents (rechte und Rollen) etc. Nur was sollen die noch im Backend wenn eh nur noch die Hälfte der Auftragsdaten drin sind…
Sorry, und der Vorschlag, auf die “Bestellen ohne Registrierung” - Funktion zu verzichten haut ja wohl dem Faß den Boden aus. In jedem Usability-Buch für 19,90 EUR steht auf der 2. Seite dass ich dem Kunden den Bestellprozess so einfach wie möglich machen soll.
@Oxid Ich finde es erschreckend, dass hier klammheimlich an solchen kritischen Sachen rumgeschraubt wird. Aber Hauptsache Ihr bringt mit dem neuen Release eine tolle Web3.0 Facebookintegration mit. Als damaliger Betatester der 1.2er PE kann ich nur sagen: hammerhart was aus dieser Firma geworden ist…
Gruß
Alex
[QUOTE=csimon;31883]ein nicht vorhandener kunde ist in garkeiner benutzergruppe, sobald man IRGENDEINE benutzergruppe (und seis eine leere) zuordnet gilt das nicht mehr für unregistrierte.
ist schon ein lang von mir geäusserter verbesserungswunsch das es auch gruppen für unregistrierte gibt.[/QUOTE]
Bitte erst so etwas prüfen. Vlt. war das früher mal so. Im derzeitigen Demoshop ist das anders.
Wenn ich mich im Demoshop im Admin anmelde, ist dort nur ein Kunde in der Kundenliste - der Admin selber.
Sobald ich eine Adresse im Frontend unter Einkaufen ohne Registrierung eingebe, ist dies auch als Kunde im Admin aufgelistet.
Mit Folgenden Kundengruppen:
Domestic - oder Foreign Customer
und not yet purchased.
Wahrscheinlich wird dieser Kunde später gelöscht oder was auch immer.
Es reicht aber diesen Kunden ‘no yet purchased’ ein paar Zahlungsarten nicht zu erlauben.
[QUOTE=laramarco;31884]Es kann wirklich nicht im Sinne des Erfinders sein, daß bei jeder Bestellung eines unregistrierten Kundens Boniprüfkosten entstehen[/QUOTE]
Wenn man den Wunsch des Kunden ernst nimmt, kein Kundenkonto im Shop zu besitzen, ist das eine unausweichliche Folge…
Alles andere wäre eine (bewusste und vorsätzliche) Irreführung des Kunden.
Und, wie schon mehrfach erwähnt, ist die Lösung aller Probleme ganz einfach: man erlaubt keinen Einkauf ohne Kundenkonto.
[QUOTE=avenger;31889]
Und, wie schon mehrfach erwähnt, ist die Lösung aller Probleme ganz einfach: man erlaubt keinen Einkauf ohne Kundenkonto.[/QUOTE]
das ist in meinen Augen die schwachsinnigste Lösung die es gibt :mad:
Wieviele tausende Oxid Shops gibts, und Du glaubst nicht im Ernst daran, daß 5% derer das Einkaufen OHNE Kundenkonto wegen all dieser Verknüpfungs-BUGS weglassen.
Es ging seit Version 1 und zwar seit 2003 gut, wieso soll jetzt nur weil ein Programmierer schläft und nicht die Folgen des “LÖSCHENS” der Daten bis zu Ende durchdacht hat, alles anders sein ???
Ich plädiere erneut hier eine Stellungnahme von Oxid zu erhalten, das ist ein Thema was uns alle angeht.
Sorry Avenger,
aber das ist wirklich die blödeste Lösung. In Bezug auf Usablility und Conversion-Optimierung ist das Einkaufen ohne Registrierung die bevorzugte Lösung. Wir planen sogar, die Anlage des Kundenkontos erst auf der thankyou-Seite durchzuführen. Der Kunde kann sich erst am Ende der Bestellung ein Passwort vergeben.
Ich würde das Speichern der Kundendaten NICHT als eine Irreführung des Kunden betrachten. Für mich gehören die Adressdaten zum Auftrag. Nach der Auftragsabwicklung müssen sie nur gesperrt werden - und das sind sie ja wenn ich dem Kunden keinen Zugriff mehr darauf gebe.
Ich hab übrigens noch eine Idee: wenn ein Kunde ohne Passwort auf “Meine Bestellhistorie” klickt, sollte er darauf hingewiesen werden, dass ihm diese Funktion nicht zur Verfügung steht. An dieser Stelle kann er aber eine Möglichkeit haben, sich ein Passwort zu vergeben. Anschließend muss er seine Email-Adresse validieren.
Das ist aus Shopbetreiber und Kundensicht denke ich eine gute Lösung.
Gruß
Alex
@Avenger: noch was. Du schriebst weiter vorn, dass der XTC bei einer Bestellung ohne Registrierung die Kundendaten in die order-Tabelle schreibt. Wird dieser Order-Datensatz dann auch automatisch gelöscht wenn der Auftrag als erledigt deklariert wurde?
Wenn die Antwort dazu Nein lautet, wäre es ja auch eine Irreführung des Kunden - denn die Adressdaten etc. sind ebenfalls noch permanent gespeichert - nur halt in einer anderen Tabelle.
Ich finde, es ist absolut der falsche Ansatz davon auszugehen, dass “Bestellen ohne Passwort” == “Sofortiges Löschen aller Kundendaten nach Abwicklung” bedeutet.
Gruß
Alex
Ist es nicht sogar sehr gefährlich, die Daten die ich zur Abwicklung benötige (ohne Kundenkonto) einfach zu löschen, ich stelle mir gerade folgendes vor: Ein Shop mit vielen Stammkunden ohne Kundenkonto und irgendwann kommt das FA vorbei und stellt fest, dass mein Shop die Hälfte aller Bestellungen gelöscht hat, da diese ja ohne Kundenkonto waren und überschrieben oder gelöscht wurden.
Welchem Verdacht man sich damit aussetzt will ich mir im Moment gar nicht ausmalen.
Meiner Meinung nach gehören die Kunden mit Konto in die Users und die ohne Konto nur zu der Bestellung (oxorder). Wie das sauber und rechts-sicher gelöst werden soll müssen aber meines Erachtens die Experten entscheiden. Hier sehe ich Oxid in der Pflicht.
Für laramarco sehe ich nur die Optionen im Subshop den Mindestbestellwert für Rechnung auch im Subshop auf 30 € zu bekommen oder den Rechnungskauf auf Kunden mit Kundenkonto einzuschränken.
Es ist ja wirklich so, dass der Kunde nun einmal kein Kundenkonto wünscht. Also musst du entweder jedesmal die Boni-Prüfung bezahlen, oder deinen Kunden beibringen sich ein Konto anzulegen (wenn Sie auf Rechnung kaufen wollen).
Die Benutzergruppe heißt in Deutsch “Noch nicht bestellt”
Immerhin, wenn man das Facebook-Feature aktiviert sind das hier auf Datenschutzsicht nur noch Peanuts.
CYA
Frohe Pfingsten
[QUOTE=Firefax;31897]
Die Benutzergruppe heißt in Deutsch “Noch nicht bestellt”
[/QUOTE]
hab ich keine - also so ne Benutzergruppe
[QUOTE=MBa;31887]Bitte erst so etwas prüfen. Vlt. war das früher mal so. Im derzeitigen Demoshop ist das anders.
Wenn ich mich im Demoshop im Admin anmelde, ist dort nur ein Kunde in der Kundenliste - der Admin selber.
Sobald ich eine Adresse im Frontend unter Einkaufen ohne Registrierung eingebe, ist dies auch als Kunde im Admin aufgelistet.
Mit Folgenden Kundengruppen:
Domestic - oder Foreign Customer
und not yet purchased.
Wahrscheinlich wird dieser Kunde später gelöscht oder was auch immer.
Es reicht aber diesen Kunden ‘no yet purchased’ ein paar Zahlungsarten nicht zu erlauben.[/QUOTE]
Das ist komisch, normalerweise ist die oxid verfahrensweise überall: keine gruppe zugeordnet -> gilt auch für unregistrierte, sobald eine zugeordnet ist gilts nicht mehr für unregistrierte. Da interessiert mich jetzt auch mal der quelltext, weil wenn kein user angemeldet ist existiert ja auch kein oxuser objekt, also kann man garnicht prüfen ob ein unregistrierter benutzer in der gruppe “not yet purchased” ist. und da diese gruppenprüfung auf dem oxuser objekt stattfindet, würde das ja heissen das oxid irgendwo noch eine überprüfung drin hat die sagt “wenn oxuser == null dann in gruppe ‘not yet purchased’”.
Das es bei unregistrierten Benutzern kein oxuser Objekt gibt ist ja mein kritikpunkt, wenns das gäbe könnte man kinderleicht unregistrierten usern irgendwelche gruppen zuordnen, das geht aber nicht.
Ich hab übrigens noch eine Idee: wenn ein Kunde ohne Passwort auf “Meine Bestellhistorie” klickt, sollte er darauf hingewiesen werden, dass ihm diese Funktion nicht zur Verfügung steht. An dieser Stelle kann er aber eine Möglichkeit haben, sich ein Passwort zu vergeben. Anschließend muss er seine Email-Adresse validieren.
Nein, das Datenleck ist anders:
Nehme mal an du bestellst als “hupi” unregistriert. Ich kenne deine email adresse “[email protected]”. Ich registriere mich in dem shop mit “[email protected]” und kann daraufhin alles einsehen was du bei deiner letzten bestellung bestellt hast. das würde passieren wenn man die datensätze so lassen würde und nicht löschen.
Eine andere möglichkeit, wäre eine gezwungene aktivierungsmail bei registrierungen, sodass jedes kundenkonto erstmal vom benutzer per klick auf einen link in der mail aktivieren müsste. dann kann man die datensätze von unregistrierten benutzern auch als verkehrsdaten in der datenbank lassen und hätte das problem nicht, da ja jeder benutzer erstmal verifiziert wird.
https://bugs.oxid-esales.com/view.php?id=1489
sollte in der oxid 4.3.0 eigentlich behoben sein. wobei ich seh grad, die gruppe gibts in der EE immer noch nicht, siehe kommentar vom entwickler.
und wir drehen uns weiter im kreis, menno mir wird schon schwindlig
[QUOTE=laramarco;31901]und wir drehen uns weiter im kreis, menno mir wird schon schwindlig[/QUOTE]
Ich nehm alles zurück bzgl des bugs: im ee-demoshop von oxid gibts diese gruppe, der bug wurde doch so behoben das es die gruppe nun gibt.
Hi,
ich will nochmal zusammenfassen:
Ausgangssituation:
[email protected] bestellt bei Martina ohne Passwort. Mein böser Nachbar sieht nun, dass ich von Martina Wolle geliefert bekommen hab und möchte da mehr wissen. Er bestellt bei Martina unter dem Namen Donald Duck mit Email-Adresse [email protected]. Unmittelbar danach sieht der die Historie und andere nette Sachen. Das ist natürlich ein Datenleck.
Mein Lösungsvorschlag:
Da [email protected] kein Passwort hat, kriegt er keinerlei Zugriff auf irgendwelche Daten (Historie, Reviews…). Er bekommt nur eine Meldung angezeigt: “diese Funktion steht Ihnen nicht zur Verfügung. Hier können Sie ein Kundenkonto eröffnen…” Wenn er sich dann [B]nachträglich[/B] (aber auch nur dann!!!) ein Passwort vergibt muss er die Email-Adresse verifizieren. Erst dann kriegt er Einblick in historische Daten.
Ich find das ist ne simple Sache und entspricht auch dem Datenschutz. Wo dann die User-Daten abespeichert werden ist eigentlich egal. Ob user oder order-Tabelle, gespeichert ist gespeichert.
Gruß
Alex
Habe auch nochmal recherchiert.
Die Kundegruppe not yet purchased geht zwar nun, aber leider ist da noch ein Bug. Zumindest halte ich es für einen.
Und zwar sobald man als Gast eine Bestellung bestätigt, ist dieser Gast nicht mehr in der Kundengruppe not yet purchased. Er hat ja bestellt.
Also kann er mit der aktuellen Browsersession eine weitere Bestellung als normaler Kunde machen.
Ergo kann jemand eine Kleinigkeit als Gast bestellen und danach eine weitere Bestellung, die richtig reinhaut.
Generell finde ich, dass ein Kunde (nicht nur Gäste) erst aus der Kundengruppe not yet purchased rausfliegen soll, wenn die Bestellung komplett abgeschlossen ist. Also bezahlt, geliefert und Widerruf abgewartet ist.
[QUOTE=Firefax;31800]Man könnte jetzt aber manuell über phpmyadmin in der OXORDER die OXID des neuen OXUSERS eintragen und somit die Verknüpfung wieder herstellen.
Das [B]muss!!![/B] man ja sowieso machen, wenn falls man den Auftrag noch nicht abgeschlossen hatte, als der Kunde sein Kundenkonto angelegt hat. Ansonsten verschindet ja die Adresse bei jeder Änderung (z.B. Kunde hat bezahlt setzen) im Auftrag.
[/QUOTE]Ist das tatsächlich noch so? Ich konnte das mit 4.3.0 nicht mehr reproduzieren, oder hab ich was falsch gemacht?
[QUOTE=Hupi;31904]
Ich find das ist ne simple Sache und entspricht auch dem Datenschutz.[/QUOTE]
Da wäre ich mir nicht so sicher, die Mailadresse wurde bei der Bestellung ohne Kundenkonto nicht verifiziert, also weiß man auch nicht ob die Benutzer wirklich identisch sind.
[QUOTE=leofonic;31914]Ist das tatsächlich noch so? Ich konnte das mit 4.3.0 nicht mehr reproduzieren, oder hab ich was falsch gemacht?[/QUOTE]
also ich habe gerade die letzten 2 Tage einen Fall beobachtet, konnt ich mir grad gut merken, weils ein “alter Inkassokunde” ist und jetzt zum “Neukunden” wurde
ich hätte also für diesen Kunden, der innerhalb 3 Tage 2x bestellt, 1x mit PW und 1x ohne 2x Boniprüfungsgebühren bezahlt, plus 2 Datev Konten beim Steuerbüro plus plus plus
(hätte = weil Paypal ohne Prüfung, hatte ich zumindest in dem Fall Glück)
gelöscht bleibt der eine Kundeneintrag trotzdem und gerade in solchen “Inkasso” Fällen bin ich ziemlich pingelig (hab sogar Privatinsolvenzen aus sehr alten Jahren noch aufgegriffen, weil Kunde immer und immer wieder neu versucht zu bestellen).