Edit Orders v4.0 Support Thread

OK..

I think I found a solution to this, in case anyone else has the Optional Shipping Insurance with Edit Orders 4.1.4 and ZenCart 1.5.4..

In the file..
\My_Admin_Folder\edit_orders.php

Near line 437 after ..

Code:

---

// TODO Special processing for some modules
        if(zen_not_null($order_total['title']) && $order_total['title'] != ':') {
                switch($order_total['code']) {

---

I added...

Code:

---

case 'ot_insurance':
        $_SESSION['opt_insurance'] = true;
        break;

---

so the code looks like this now...

Code:

---

// TODO Special processing for some modules
        if(zen_not_null($order_total['title']) && $order_total['title'] != ':') {
        switch($order_total['code']) {
                case 'ot_insurance':
                        $_SESSION['opt_insurance'] = true;
                        break;
                case 'ot_shipping':
                        $GLOBALS['order']->info['shipping_cost'] = $order_total['value'];
                        $GLOBALS['order']->info['shipping_module_code'] = $order_total['shipping_module'];
                        break;
                case 'ot_tax':

---

This seems to give the ot_insurance code the variable it needs to add the insurance to the order total correctly.

Let me know if anyone else tries this and has success or problems..

-Andy

May want to double check to ensure your change does not FORCE insurance on all orders when updated via edit orders (including when saving an order where the customer did not request insurance). The above runs a good likelyhood of also flipping insurance for any subsequent order as you are adding the change into the Store Admin's login session (persists beyond a single admin page / request).

May be better to update ot_insurance.php to check if the module was already part of the order and loaded via admin (and if both are true, flip the flag instead of adding to the session).

Quote:

---

Originally Posted by lhungil

May want to double check to ensure your change does not FORCE insurance on all orders when updated via edit orders (including when saving an order where the customer did not request insurance). The above runs a good likelyhood of also flipping insurance for any subsequent order as you are adding the change into the Store Admin's login session (persists beyond a single admin page / request).

May be better to update ot_insurance.php to check if the module was already part of the order and loaded via admin (and if both are true, flip the flag instead of adding to the session).

---

Thanks lhungil,

I was pondering those same possibilities. So far my testing has not produced any problems with unintended application of insurance, both in the Admin Edit Orders or with customers regular shopping cart. I will keep testing, but so far this seems to work for me.

I appreciate your taking time to look at it.

Andy

Has anyone reported calculation problems with zc 1.5.4 and php 5.5.25? I moved the site from one server to another so no change to the site, just the new php version. On an order with about 40 items it should add up to 268 but instead is totaled 270 once the order was edited. Not much difference but still an indication that something isn't working exactly correct.

Hi,
Does anyone know the reason for the 'Advanced Attributes Editor' being removed from Edit Orders 4.1.x ?
I've looked around and can't seem to find reference to it here in the Forum nor in Logs etc.
I just wondered if there was a specific reason I should know about before I go about butchering it back in place.
Many Thanks

Edit Orders 4.0 did all the math internally. Edit Orders 4.1 lets functions from the Zen Cart customer checkout and order total modules do most of the math.

Edit Orders 4.1.x currently allows changing attributes (as long as the attributes exist and are assigned to the product - so if the attribute shows on the customer side it shows on the admin side - if not on the customer side it is not an option on the admin side).

The "advanced" attribute editor allowed adding attributes which do not exist in the database to products. This led to an inconsistent customer experience. Also in some edge cases handling products or attributes not in the database can result in unintended side effects (and calculation errors).

Quote:

---

Originally Posted by lhungil

May want to double check to ensure your change does not FORCE insurance on all orders when updated via edit orders (including when saving an order where the customer did not request insurance). The above runs a good likelyhood of also flipping insurance for any subsequent order as you are adding the change into the Store Admin's login session (persists beyond a single admin page / request).

May be better to update ot_insurance.php to check if the module was already part of the order and loaded via admin (and if both are true, flip the flag instead of adding to the session).

---

Hey Andy_M,

thanks for posting a solution to using the Optional Insurance module.

Just a question, have you picked up any issues up to now on your implementation?

Does it calculate correctly and avoid globalizing the insurance onto orders that were not originally selected for insurance?

Hello,

I successfully added Admin New Customer 3 this week to a functioning v1.5.3 ZC install.

Today I installed Edit Orders 4 and it appeared to go fine but when using the Update button to submit form on /edit_orders.php?page=1&oID=11435&action=update_order I get "WARNING: An Error occurred, please refresh the page and try again."

The error being logged by these is

PHP Fatal error: 1054:Unknown column 'p.products_quantity' in 'field list' ::
SELECT `p`.`products_quantity` FROM `products` WHERE `p`.`products_id` = '153' ==>
(as called by) /[snip]myadmin/includes/functions/extra_functions/edit_orders_functions.php on line 1028
<== in [snip]/includes/classes/db/mysql/query_factory.php on line 155

On checking the referenced line I found that the query did not supply the alias p for the table...

$check = $db->Execute(
'SELECT `p`.`products_quantity` FROM `' . TABLE_PRODUCTS . '` ' .
'WHERE `p`.`products_id` = \'' . (int)$query->fields['products_id'] . '\''
);

After changing the above code to TABLE_PRODUCTS . '` p ' . the error was resolved.

Since editing an order occurs post sale should I assume that order total and weights/shipping amounts will not be affected by edits?

Thanks!

David

Quote:

---

Originally Posted by jerrygarciuh

...
The error being logged by these is

PHP Fatal error: 1054:Unknown column 'p.products_quantity' in 'field list' ::
SELECT `p`.`products_quantity` FROM `products` WHERE `p`.`products_id` = '153' ==>
(as called by) /[snip]myadmin/includes/functions/extra_functions/edit_orders_functions.php on line 1028
<== in [snip]/includes/classes/db/mysql/query_factory.php on line 155
...

---

Glad you were able to solve the issue you were experiencing. The issue (and solution) previously posted is very similiar (just a bit more explicit).

If you are not already, I've found adding "site:zen-cart.com" to the end of search queries on Bing and Google to be very helpful when searching this site (forums, wiki, plugins, etc). I've found it especially helpful (and time saving) when searching for specific error messages or bugs / bugfixes.

Quote:

---

Originally Posted by jerrygarciuh

...
Since editing an order occurs post sale should I assume that order total and weights/shipping amounts will not be affected by edits? ...

---

Yes and No.

Nope. When you add / remove / update items (or totals / addresses) in an order the Zen Cart code for processing order totals is run again, so order totals will be updated (unless the order total module is not compatibble with being loaded from the admin and interacting directly with $order).

Yes. The shipping module code to generate a shipping quote is not called, so shipping is not recalculated and will appear in the admin as the customer selected (as long as they are not changed - and the shipping module is enabled).

Quote:

---

Originally Posted by lhungil

Nope. When you add / remove / update items (or totals / addresses) in an order the Zen Cart code for processing order totals is run again, so order totals will be updated (unless the order total module is not compatible with being loaded from the admin and interacting directly with $order).

---

Thank you for the reply! I am using Local Sales Tax but otherwise I believe my Order Total process is default one for v1.5.3.

When I update order items I am seeing taxes calculated correctly for the new order total but the sub-total is coming up $0.00. The completed order total is being calculated a $0 for subtotal and then correctly adding current shipping amount and tax.

In this example I have deleted a hat which was only item in a real order after using Edit Orders to add two cases of hot sauce.

Attachment 15518

Do you have any advice on sub-total issue or should I dig into code and see what I can find?

Appreciate the help!