View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001469 | OXID eShop (all versions) | 1.03. Basket, checkout process | public | 2009-11-11 19:06 | 2012-12-10 13:23 |
| Reporter | joshua | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | 4.2.0 revision 23610 | ||||
| Summary | 0001469: shippingtype not saved : Bug from 0001249 still not resolved | ||||
| Description | the same effect as described in bug 0001249 https://bugs.oxid-esales.com/view.php?id=1249 still exists in OXID EE 4.2.0 rev 23610 and is not resolved yet. Now with the new constants used for marking order state the user will be redirected to payment page saying "chosen payment type is not available". | ||||
| Tags | Order | ||||
| Theme | |||||
| Browser | All | ||||
| PHP Version | 5.2.6 | ||||
| Database Version | 5.0.33 | ||||
|
|
Reminder sent to: joshua Does it happen while doing regular order process, when all deliveries, delivery sets and payments are allready set-up? There is something strange ... i created exact copy of 'oxidstandard' delivery set (excl. its oxid), deleted 'oxidstandard' from db (as its impossible from admin) and everything went smooth. Can you PLEASE describe precise TODOs steps to reproduce problem? |
|
|
Hi there, yes everything is setup correctly, deliveries, delivery sets and payment methods are correctly defined. If you enable debug mode = 5, you can see the correct delivery set on screen, but this output comes from the payment class, our problem relies on the oxbasket class. If you put an debug output on line 1493 in oxbasket.php saying "print $this->_sShippingSetId;" you can see that even if there is no delivery set with an id "oxidstandard" in this shop, "oxidstandard" is used. This leads to the problem that a user who accesses the payment screen and doesn't change the shipping, there is no change in delivery set and the key "oxidstandard" is preserved. Finally the conistency check in oxorder fails and the user is redirected to payment page. BTW: If you're using OXID EE you dont' have to delete oxidstandard from database because in every subshop one can add own delivery sets which have a generated oxid... |
|
|
Reminder sent to: joshua You wrote: "This leads to the problem that a user who accesses the payment screen and doesn't change the shipping, there is no change in delivery set and the key "oxidstandard" is preserved." Cant agree with you about that. In payment.tpl there is a form with select named "sShipSet". When you open payment screen select list is filled with delivery sets that matches your basket. When you click on button to proceed to next step function "changeshipping" is called AND value of select list is written to session, basket is reset and forced for recalculation. See: public function changeshipping() { $mySession = $this->getSession(); oxSession::setVar( 'sShipSet', oxConfig::getParameter( 'sShipSet' ) ); $oBasket = $mySession->getBasket(); $oBasket->setShipping( null ); $oBasket->onUpdate(); } |
|
|
"When you click on button to proceed to next step function "changeshipping" is called AND value of select list is written to session, basket is reset and forced for recalculation." I don't think so. I can see two different forms with different names and hidden fields. The shipment form calls the "changeshipping" method, the payment form calls the "validatepayment" method. By clicking the button "continue to next step" the payment form is submitted, not the shipping form. Therefore the method "changeshipping" is not called the code not executed. |
|
|
Reminder sent to: joshua ah, sorry wrong form... still in payment.tpl payment::getPaymentList() is called, which loads delivery set info ACCORDING to basket. |
|
|
Yes that's right, but that's not the problem...all delivery sets are displayed correctly! The problem is that the delivery set in basket is not changed when the user just selects his payment method and proceeds because the code you provided is not executed... |
|
|
I just tried to reproduce this on demoshop http://demoshop.oxid-esales.com/professional-edition/ and everythings seems to be fine... Maybe it's just a bug in EE? Or can you tell me which changes are being made when this bug was resolved? |
|
|
Reminder sent to: joshua "payment.tpl payment::getPaymentList() is called" means: ... list( $aAllSets, $sActShipSet, $aPaymentList ) = oxDeliverySetList::getInstance()->getDeliverySetData( $sActShipSet, $this->getUser(), $oBasket ); oxSession::setVar( 'sShipSet', $sActShipSet ); ... so fitting, existing and active deliveryset is set into session. |
|
|
Reminder sent to: joshua IF you CAN reproduce problem locally can you make a module for payment::getPaymentList() method with this source: public function getPaymentList() { if ( $this->_oPaymentList === null ) { $this->_oPaymentList = false; $sActShipSet = oxConfig::getParameter( 'sShipSet' ); $oBasket = $this->getSession()->getBasket(); // load sets, active set, and active set payment list list( $aAllSets, $sActShipSet, $aPaymentList ) = oxDeliverySetList::getInstance()->getDeliverySetData( $sActShipSet, $this->getUser(), $oBasket ); oxSession::setVar( 'sShipSet', $sActShipSet ); $oBasket->setShipping( null ); // calculating payment expences for preview for each payment $this->_setDeprecatedValues( $aPaymentList, $oBasket ); $this->_oPaymentList = $aPaymentList; $this->_aAllSets = $aAllSets; } return $this->_oPaymentList; } IF yes - please do so and test, Thnx |
|
|
I'm currently working on a EE 4.2.0 and I can't find the line "$oBasket->setShipping( null );" in the code which seems to do exactly what we need... what do you mean? |
|
|
Reminder sent to: joshua i just pasted a code for you which maybe fixes problem which occurs on your side, but cant be reproduced on demo shop.. yes, exactly code line you pasted was added |
|
|
hmmm... I disabled all modules in shop but the effect still comes up. As I've seen in demoshop that it is working correctly I even more believe that it has something to do with out shop installation. Therefore I think you can close this ticket...and thanks a lot for your support! |
