Edit Orders v3.0 for ZC 1.3.9 [Support Thread]

Address Editing
This works really well from what I have observed. During integration I have noticed Edit Orders directly modifies the addresses in the order table. This makes complete sense as changes a customer may make to their address book will not affect the address information supplied for the order (also supports better order address history).

Request
However it would be "nice" to have the option of selecting an address from the customer's address book to overwrite these fields. This would save some administrative time if the customer contacts the store to change the shipping address of the order (prior to the order shipping). I'm sure there are a few other cases where this could be useful.

Scenario

1. Customer (or admin) places an order.
2. Customer receives confirmation email and notices they have the wrong address.
3. Customer updates address in their address book.
4. Customer contacts store and requests the order be sent to the updated address.
5. Order Manager updates shipping address on the order (if not already shipped).

Notes
This is just a feature request, not a bug / issue. The current Edit Order module already supports changing the addresses for the order by manually typing in the new address information. It would just be nice in some cases to also be able to select the new address from the customer's address book.

After taking a little longer look, the patch "a (edit_orders_defines)" is not needed and is already included correctly in this module. Only patch "b (init_eo_config)" is needed to correct the admin profile issue.

I will be adding a new patch shortly with corrections. Please disregard Edit-Orders-4.02-patch2.zip

Alright, here is the admin profiles patches with corrections. Two files were modified in this patch. I've included both the patches and copies of the files I used when testing the changes.

Enjoy!

So I have searched several ways in the thread and haven't found if the attributes bug from the older version was ever fixed. This is the bug where if you are adding a new product and it has attributes and the "use specials/sale price" box is checked it will add the original price plus the sale price to give the wrong price.

Quote:

---

Originally Posted by lankeeyankee

So I have searched several ways in the thread and haven't found if the attributes bug from the older version was ever fixed. This is the bug where if you are adding a new product and it has attributes and the "use specials/sale price" box is checked it will add the original price plus the sale price to give the wrong price.

---

None of the tax or attribute bugs were addressed at all.. In my announcement post I list out the fixes/changes made..

I saw that but also noticed other folks chipping in bits here and there so thought I'd search first and ask after. Thanks, guess I will have to finally have a crack at it, I'm training new people on certain functions, editing orders being one, and it's a pain to have to teach them about this bug and workaround and that bug and workaround....:blink::shocking::laugh:

Quote:

---

Originally Posted by lankeeyankee

I saw that but also noticed other folks chipping in bits here and there so thought I'd search first and ask after. Thanks, guess I will have to finally have a crack at it, I'm training new people on certain functions, editing orders being one, and it's a pain to have to teach them about this bug and workaround and that bug and workaround....:blink::shocking::laugh:

---

Nope.. I had someone who volunteered to work on the attributes bugs for this release.. He started like gangbusters, then sadly his work got sloppy and he clearly wasn't testing the code he was writing nor did he seem to have a grasp on the attribute issues with this add-on (despite my providing LOTS of documentation and mockups). He eventually bailed out of helping with this update and left me with the MESS of having to excise all his half working code out.. **sigh** It is WAY over my head to fix the attributes and tax bugs with Edit Orders.. So I targeted the low hanging fruit of making sure this add-on was v1.5 ready and a few minor changes that I could easily make..

OK, I *think* I have the attributes bug fixed when adding new products with attributes. At least it's working for me with a variety of scenarios, but there could be problems from the way other users have their attributes set up. Mine are all priced by attributes, this may or may not affect this functionality. So, hopefully some folks will try this out and report back their results.

To reiterate, the problem I was having was when adding products with attributes and the products are using the sale/special price and that checkbox is selected on the finial step when entering quantity. It was adding up prices incorrectly, really large prices as if combining the sale price with the regular price.

Here's what I did:

in admin/edit_orders.php on line 1294 of an unaltered file find:

PHP Code:

---

or die("Failed to connect database: ");
                while($row10a=mysql_fetch_array($result10a, MYSQL_NUM)) { 
                                        if ($row10a[2] == 1 && $_POST[applyspecialstoprice])
                                            $newpricechange = zen_get_discount_calc($add_product_products_id, $row10a[3], $row10a[0], $add_product_quantity); 


---

and change it to this:

PHP Code:

---

or die("Failed to connect database: ");
                
    $new_attributes_price= '';
    $attributes_values = $result10a;
    $attributes_price_final = zen_get_attributes_price_final($attributes_values->fields["products_attributes_id"], 1, $attributes_values, 'false');
    $attributes_price_final_value = $attributes_price_final;
    $attributes_price_final = $currencies->display_price($attributes_price_final, zen_get_tax_rate(1), 1);
  if ($attributes_values->fields["attributes_discounted"]) {
    $new_attributes_price = zen_get_attributes_price_final($attributes_values->fields["products_attributes_id"], 1, '', 'false');
    $new_attributes_price = zen_get_discount_calc($add_product_products_id, true, $new_attributes_price);
    if ($new_attributes_price != $attributes_price_final_value) {
      $new_attributes_price = $currencies->display_price($new_attributes_price, zen_get_tax_rate(1), 1);
    } else {
      $new_attributes_price = '';
    }
  }
                while($row10a=mysql_fetch_array($result10a, MYSQL_NUM)) { 
                                        if ($row10a[2] == 1 && $_POST[applyspecialstoprice])
                                            $newpricechange = $new_attributes_price; 


---

If anyone else wants to try it out and let me know what you experience I will try to fix any problems that arise. Hopefully it won't cause any problems and it will all work the way it should in every scenario.:smile:

scratch that, it only works if there is one attribute with a price, if you have more than one attribute that adds to the price this won't work. This is what happens when you have been working on the computer all day and you start digging into code after 1am and forget the basic principals of testing thoroughly before opening your big mouth.:blush::laugh:

I will give it another whirl tomorrow when I am fresher and more on the ball.:smile:

Quote:

---

Originally Posted by lankeeyankee

scratch that, it only works if there is one attribute with a price, if you have more than one attribute that adds to the price this won't work. This is what happens when you have been working on the computer all day and you start digging into code after 1am and forget the basic principals of testing thoroughly before opening your big mouth.:blush::laugh:

I will give it another whirl tomorrow when I am fresher and more on the ball.:smile:

---

:laugh: I get it.. go to bed.. I have a software demo to conduct tomorrow morning and I need to hit the rack myself..