View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001605 | OXID eShop (all versions) | 1.03. Basket, checkout process | public | 2010-01-18 09:48 | 2012-12-10 14:13 |
| Reporter | MichaelZ | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.2.0 revision 23610 | ||||
| Fixed in Version | 4.3.0 revision 26948 | ||||
| Summary | 0001605: Displayed delivery set not changed on order view | ||||
| Description | This bug occurs, when the selected delivery set automatically changes due to another change in the order (e.g. the customer changes her address which leads to another delivery set selection). To reproduce: - Create two delivery sets one for "Inland", the other one for "Abroad". - Make them usable in the shop (i.e. create delivery cost rules and payment methods and assign them accordingly). You should create two different delivery cost rules for each of them so that you can detect which one was selected in the order. - Assign the country "Germany" to the "Inland" delivery set and all the other available countries to the "Abroad" delivery set. - Put something in your shopping cart and proceed through the ordersteps withough finishing the order. Make sure to select "Germany" as your country and remember the displayed delivery set in the last step. - Now go back to step two and change your country to something else. - Proceed to step 3 and pay attention to the delivery set selection. It should show "Abroad" instead of "Inland" as it did previously. - Proceed to step 4. The delivery costs should be updated according to the cost rule that was assigned to the "Abroad" delivery set. However the box that displays the selected delivery set still displays "Inland" as the selected delivery set. | ||||
| Tags | No tags attached. | ||||
| Theme | |||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
Reminder sent to: MichaelZ Thank you for very detailed description. I was able to reproduce this easily. Best regards, |
|
|
latest code does not contain problem any more, so problem is fixed! |
|
|
I noticed another bug which might be associated with this one so I post it here: When the user procedes to the last order step and then goes back to the second step to change her delivery address (which in our case also causes an automatic change of the delivery set) the delivery set saved to the database is the one which was initially selected. In our case the client was located in switzerland which caused the delivery set "abroad" to be selected. Later she specified a delivery address in germany and the delivery set was automatically changed to "inland" (we noticed this as the delivery costs were updated). The delivery set saved to the database was the one for abroad countries. When I proceed through the order steps without changing anything, the delivery set is saved correctly. Can you please confirm that this new issue is related to this one? I also would be interested in a bug fix as this whole thematic is very important for one of our clients planning to put the shop online next week... |
|
|
Try to write a module for payment::getPaymentList(): /** * Template variable getter. Returns paymentlist * * @return object */ 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( $sActShipSet ); // calculating payment expences for preview for each payment $this->_setDeprecatedValues( $aPaymentList, $oBasket ); $this->_oPaymentList = $aPaymentList; $this->_aAllSets = $aAllSets; } return $this->_oPaymentList; } I can't assure that this is a full fix (we did not fix exact problem you mention, just SVN code does not have this problem). Please test and write us results. If problem is gone - please close a bug entry. Thnx! |
|
|
This seems to fix the reported issue! Thanks a lot for your uncomplicated help! This bug can be closed as far as I am concerned. |
