as we all know the payment methods, the shipping methods and the deliverycosts rules must be combined and are dependable eachother.
I learned that the assignment ajax popups operate like this:
-> Assign a deliverycost, country, customergroup, etc. and all other available options are disabled.
-> Assign nothing and all of the options are assigned and activated at a standard behavior without any assignment
Just like a whitelist model.
So far, so good, not very complicate when we understand the system. BUT: [B]Why the f* hell are the paymentmethods operating in a completly different and opposed way?[/B]
It took me hours to find out that I musst assign the country and usergroup to the paymentmethods and drag them to the right windows of the popup to active them. Otherwise the checkout process in the shop breaks in step 3 and does not continue due to any invalid rule. That was very very annoying for me.
Is there any reason for that behavior? I do not see any logical reason for that.
If there should be any bug in the mantis about it i apologize for my post, but i did not expect to look at every bug entry to be succesfull in installing the oxid shopping system in a productive enviroment. The shipping model [U]should [/U]work out of the box!
I did not count the misfits and errors i had to solve from the starting point when we decide to use Oxid but there were a lot. Sometimes i think it would be worth to make a snapshot of a already productive oxid shop, create a fork from it and offer it as a stable and productive release without need for any heavy codefixing. Surely not fair to bring in here in the official forum such thoughts but i hope that the responsible developers wake up about the whole bug situation and the process of solving them.
I am sure that no one of the developers and 3party supporters will be sacked or receive a fewer order volumen when everything runs smoother and will be more stable.
[QUOTE=beme;61145]
It took me hours to find out that I musst assign the country and usergroup to the paymentmethods and drag them to the right windows of the popup to active them. [/QUOTE]
In fact it’s only the usergroups. This is so unlogical. I reported it now: https://bugs.oxid-esales.com/view.php?id=3017
Ich hab nie gedacht das das ein bug ist (übrigens, hier musste nich auf englisch schreiben, das ist das deutsche forum), das ist schon so in fleisch und blut übergegangen. Aber gut das es eingetragen ist, vielleicht wirds ja in irgendeiner version mal berücksichtigt.
Nein, mal ernsthaft: Es mag zwar nicht oder nicht gut genug dokumentiert sein, aber ich könnte mir vorstellen, dass man bei solch sensiblen Teilen wie den zur Verfügung stehenden Zahlungsmöglichkeiten aktiv die gewollten Usergruppen zuweisen können sollte.
Nicht dass dann auf einmal die Blacklist-User oder die aus Singapur auf Rechnung einkaufen können oder so.
War das vielleicht der ursprüngliche Hintergedanke?
Ist eben nun die Frage, ob man die Denke beibehält oder in die eine oder andere Richtung verändert. Für mich wäre es logisch, dass nur das funktioniert was ich explizit erlaube/einrichte. Hätte dann zur Folge, dass wenn nichts zugewiesen wird auch nichts geht. Aber dann eben überall.
Ray, den Gedanken mit spezieller Sicherung für Zahlungsmethoden hatte ich auch, aber im Grunde könnte man das selbe auch bei Versandarten und Versandmethoden sagen. Und wieso sollte es diese Sicherung nur bei Benutzergruppen geben aber nicht bei den Ländern (da gilt nämlich auch bei den Zahlungsarten “nichts zugeordnet ist alles zugeordnet”)?
Gegen die Methode alles immer zuweisen zu müssen sprechen einige Gründe:
Es würde die Einrichtung unnötig verkomplizieren, weil man für die Einrichtung einer simplen Versandart für die Art selber, die Regeln und die Zahlungsweisen jeweils Benutzer und Länder zuordnen müsste. Wenn man die Logik durchzieht müsste man auch noch Kategorien oder Artikel bei den Regeln zuordnen. Wenn dann neue Kategorien dazukommen könnte man erstmal nichts davon kaufen bis es jemand merkt und die Kategorie zuordnet.
Eines der Hauptprobleme beim Einrichten ist, dass die Versandart im Frontend nicht erscheint. Je mehr man zuordnen muss, desto wahrscheinlicher ist dieser Fall, und dann wird erstmal wild überall mehr zugeordnet als notwendig um das Ding überhaupt zum Laufen zu bringen und der “Sicherheitsgewinn” ist dahin.
Die Option “Versandkosten auch für nicht angemeldete Benutzer zeigen” funktioniert nicht, wenn bei der Versandart Benutzergruppen zugeordnet sind.
Und noch ein Grund, der nicht zu vernachlässigen ist: beim nächsten Shopupdate würden schlagartig fast alle bisher eingerichteten Versandarten nicht mehr funktionieren.
Also wäre die korrekte Auflösung dieses Dilemmas wohl entweder die [U]deutliche[/U] Dokumentierung dieser Ausnahme in der Logik, oder das (ebenfalls dokumentierte) Einführen derselben Logik wie bei allen anderen Zuordnungen.
Dokumentation ist alles, und da der punkt mit dem logikbruch nicht in der doku auftaucht scheint es ein Bug zu sein. Wir haben einige komplexe versandoptionen und es lief alles reibungslos, bis ich mal eine neue versandoption hinzugefügt hatte, die aufgrund der zwangszuweisung nicht funktionierte. Danke für das eintragen in den Tracker. Euch nen schönes we.
