Edit Orders v4.0 Support Thread

[Gadgit]

Ok - I think I have come up with a solution to this now. I have done as I suggested and added an extra dimension to the front of the id array which is the $orders_products_id value.

For example - Line 903 in edit_orders.php

echo '<textarea class="attribsTextarea" name="id[' .$optionID[$j] . '][value]" rows="' . $optionInfo['rows'] .
	'" cols="' . $optionInfo['size'] . '" id="attrib-' .
	$optionID[$j] . '" >' . $text . '</textarea>' . "\n";

becomes

echo '<textarea class="attribsTextarea" name="id['.$orders_products_id.'][' .	$optionID[$j] . '][value]" rows="' . $optionInfo['rows'] .
	'" cols="' . $optionInfo['size'] . '" id="attrib-' .
	$optionID[$j] . '" >' . $text . '</textarea>' . "\n";

and then, when this array is read from $_POST on line 276

zen_db_prepare_input($_POST['id']),

becomes

zen_db_prepare_input($_POST['id'][$orders_products_id]),

I have had a quick (but not thorough!) test of this, and it seems to work - can anyone see any reasons as to why this might cause problems elsewhere?


I now seem to have a problem in that the Sub-Total and hence, the Total never update, and they can't be modified manually, so the order totals cannot be changed, only by adding additional total lines (but then these get removed again upon updating the order). Is this expected functionality, have I missed something or is this a bug?

Cheers,
Scott

[Gadgit]

Sorry for the quadruple post, but I think I have solved the above issues, and possibly fixed some bugs along the way. The sub total was updating, it was just me not noticing. There was a problem with the VAT calculation though, it didn't seem to be including the onetime charge VAT. This was due to a stray semi-colon, took me a while to notice that one!

In edit_orders_functions.php around line 818 in eo_get_product_taxes()

$taxAdd = zen_calculate_tax($product['final_price'], $product['tax']) * $product['qty'];
	+  zen_round(zen_calculate_tax($product['onetime_charges'], $product['tax']), $decimals);

has an extra ; on the first line, and should instead be

$taxAdd = zen_calculate_tax($product['final_price'], $product['tax']) * $product['qty']
	+  zen_round(zen_calculate_tax($product['onetime_charges'], $product['tax']), $decimals);

I then found that there was a problem with the subtotal not being calculated correctly when adding and removing a onetime charge. This may have been a known issue, I think I have fixed it, but wanted to see if anyone knows what knock on effects this might have.

Also in edit_orders_functions.php around line 747 in eo_update_order_subtotal()

I have wrapped the $shown_price calculation in a check for whether prices are displayed with tax, and removed the tax calculation accordingly so it is now:

if (DISPLAY_PRICE_WITH_TAX == 'true') {
	$shown_price = zen_round(zen_add_tax($product['final_price'], $product['tax']), $decimals) * $product['qty'];
	$shown_price +=  zen_round(zen_add_tax($product['onetime_charges'], $product['tax']), $decimals);
} else {
	$shown_price = zen_round($product['final_price'], $decimals) * $product['qty'];
	$shown_price +=  zen_round($product['onetime_charges'], $decimals);
}

The next problem that I have found is that I seem to be able to add lines of order total amounts with any name and value, but these do not get added onto the order total, and then get removed upon update. Is this what this point in the readme is referring to?

- Add option to disable automatic order total calculations. This would allow the use of lines which do not have a corresponding order_total.

Cheers

[lhungil]

I seem to have found another problem with attributes, I've searched the thread but can't see anyone else has noticed it.

If I have an order with two different products, which both have the same set of attributes available, but none selected (for example with checkboxes) and then check one box on the first product but leave all on the second product unchecked. When I then save the order, it checks the boxes for that attribute for all subsequent items in the order. It's not just the way it's displayed, it's actually modified the order itself.

I'm now looking in to it to see if I can see what's going on - does anyone have any ideas?

Good eye. I originally planned to wrap the attributes inside the "product_updates" array. So instead of just "id[...]" you would have product_updates[orders_products_id][attr][...]. This requires making sure things are changed for all the product_option_types contained in the switch statement starting on line 845 'switch($optionInfo['type']) {'.

And then before the new product is created for the order we pull "$attrs = $product_update[attr]; unset($product_update[attr]);" and instead of "zen_db_prepare_input($_POST['id'])" you have "$attrs". Doing it this way instead would lend itself to readability :)

This would also mitigate most of the problems with EO 4.1 not generating uprids for products with attributes (and probably fix another known bug). I'd still like a future version to actually generate uprids, but at least everything would be more functional with this change. Thanks for catching this!

Sorry for the quadruple post, but I think I have solved the above issues, and possibly fixed some bugs along the way. The sub total was updating, it was just me not noticing. There was a problem with the VAT calculation though, it didn't seem to be including the onetime charge VAT. This was due to a stray semi-colon, took me a while to notice that one!

After a more indepth look, this appears to be caused by some differences between Zen Cart 1.5.0 and 1.5.1. Most of the code was originally targeted to Zen Cart 1.5.0 (I remember seeing some reported bugs with VAT / Tax calculation on the forums for ZC 1.5.0). Guess these changes were missed Take a look at the differences found in 'includes/order.php' (especially the cart() function) between 1.5.0 and 1.5.1... I would highly recommend adjusting your changes to the code to match the code in ZC 1.5.1 (the version you have installed) of orders.php. This will keep things consistent w/ the customer side of the cart.

Do you think we can get away with just changing to the updated ZC 1.5.1 code (both in edit_orders.php and edit_orders_functions)? Or will this throw off people running 1.5.0 (and require us to include ZC version checks w/ different running code)?

The next problem that I have found is that I seem to be able to add lines of order total amounts with any name and value, but these do not get added onto the order total, and then get removed upon update. Is this what this point in the readme is referring to?

- Add option to disable automatic order total calculations. This would allow the use of lines which do not have a corresponding order_total.

Exactly the point the README is referring to. In EO 4.1 (unline previous versions), it is not sufficient to simple type in an arbitrary name / value. In EO 4.1 a dropdown was added to "select the order total module" (installed, enabled, not already in use for the order). This solved a number of problems present in EO 4.0 with regards to invalid order_total lines in the database.

The more I think about changing EO to add the option to add arbitrary order total lines, the more I dislike the idea (it sets off some warning bells in my head). I really have not seen any compelling need for such a feature... Allowing such behavior will always break automatic calculations... Doing so may encourage people to edit closed / delivered orders (not desirable for many reasons)... Etc...

If you need additional lines for some reason I would recommend adding / enabling an appropriate "order total module". If you find / feel a custom order total line is absolutely necessary... Please let me know what the purpose of such a line would be and if compelling we could look at including an optional order total module to fit the need (and of course if you want to contribute such an order total module - it would be appreciated). :)

[Gadgit]

I originally planned to wrap the attributes inside the "product_updates" array. So instead of just "id[...]" you would have product_updates[orders_products_id][attr][...]. And then before the new product is created for the order we pull "$attrs = $product_update[attr]; unset($product_update[attr]);" and instead of "zen_db_prepare_input($_POST['id'])" you have "$attrs". Doing it this way instead would lend itself to readability :)

I agree, this would be a better way of doing it, as you say, it would provide better readability and encapsulation.

This requires making sure things are changed for all the product_option_types contained in the switch statement starting on line 845 'switch($optionInfo['type']) {'.

Yeah - I did this with my modifications, although I haven't fully tested yet.

This would also mitigate most of the problems with EO 4.1 not generating uprids for products with attributes (and probably fix another known bug). I'd still like a future version to actually generate uprids, but at least everything would be more functional with this change. Thanks for catching this!

I'm not sure why you need the uprids, as far as I can see at the moment, with these fixes everything seems to work pretty well. Which known issue are you referring to here?

Take a look at the differences found in 'includes/order.php' (especially the cart() function) between 1.5.0 and 1.5.1...

Not sure exactly which file you mean here - my /ADMINAREA/orders.php and /admin/includes/classes/order.php show the same across 1.5.0 and 1.5.1. The only changes appear to be in /includes/classes/order.php and these are tax related, and I've got the latest version in my cart, so should be ok.

Do you think we can get away with just changing to the updated ZC 1.5.1 code (both in edit_orders.php and edit_orders_functions)? Or will this throw off people running 1.5.0 (and require us to include ZC version checks w/ different running code)?

Hmm, I'm not sure about this, although as far as I can see, the onetime price tax calculations in 1.5.0 (line 530 in /includes/classes/order.php) were just wrong so, surely using the correct ones from 1.5.1 couldn't hurt (I assume these are the ones you mean).

If you find / feel a custom order total line is absolutely necessary... Please let me know what the purpose of such a line would be and if compelling we could look at including an optional order total module to fit the need (and of course if you want to contribute such an order total module - it would be appreciated). :)

Probably not really, I just thought that this may be something that my client would like to be able to do perhaps for example if they want to subtract a 'goodwill gesture' type discount, or an additional fee for arbitrary order additions (not likely).

I think then, perhaps without that functionality then the field should be hidden if there are no options available in the select. This shouldn't be too hard to do.

I'm happy to do a bit of testing/dev on the module if you like, would perhaps be easier to PM?

Cheers again

[lhungil]

I'm not sure why you need the uprids, as far as I can see at the moment, with these fixes everything seems to work pretty well. Which known issue are you referring to here? ...

Without the uprids some catalog side functionality (such as the links to products) will not contain the extra data which is required by some other plugins... More of a detail to be consistent with the catalog side of the cart (for example what a customer sees on the order history pages)...

I was referring to issues when a product is added more than once w/ different attributes to the order (this fix should fix that one as well).

... Hmm, I'm not sure about this, although as far as I can see, the onetime price tax calculations in 1.5.0 (line 530 in /includes/classes/order.php) were just wrong so, surely using the correct ones from 1.5.1 couldn't hurt ...

Similar to my thoughts... (I typically say '/includes/' for stuff on the catalog side and '/admin/includes' when on the admin side, so guessed right).

... I just thought that this may be something that my client would like to be able to do perhaps for example if they want to subtract a 'goodwill gesture' type discount, or an additional fee for arbitrary order additions (not likely).

I think then, perhaps without that functionality then the field should be hidden if there are no options available in the select. This shouldn't be too hard to do.

Yeah, I originally thought about the extra line as well for those two purposes... But then remembered they can always just modify the product / shipping prices and add a comment to the order status (history)... But I could see the possibility of a "dummy" order total module or two...

I also agree with your thought of hiding these fields when no additional order total lines are available. As you can tell EO 4.1 still needs to add some UI touches :) (for example javascript to toggle the display of the shipping module selection when the "shipping" is selected for addition).

I'm happy to do a bit of testing/dev on the module if you like, would perhaps be easier to PM?

My PM inbox is mostly full here... But the help is definitely welcome as is another pair of eyes :)

[DivaVocals]

Without the uprids some catalog side functionality (such as the links to products) will not contain the extra data which is required by some other plugins... More of a detail to be consistent with the catalog side of the cart (for example what a customer sees on the order history pages)...

I was referring to issues when a product is added more than once w/ different attributes to the order (this fix should fix that one as well).


Similar to my thoughts... (I typically say '/includes/' for stuff on the catalog side and '/admin/includes' when on the admin side, so guessed right).


Yeah, I originally thought about the extra line as well for those two purposes... But then remembered they can always just modify the product / shipping prices and add a comment to the order status (history)... But I could see the possibility of a "dummy" order total module or two...

I also agree with your thought of hiding these fields when no additional order total lines are available. As you can tell EO 4.1 still needs to add some UI touches :) (for example javascript to toggle the display of the shipping module selection when the "shipping" is selected for addition).


My PM inbox is mostly full here... But the help is definitely welcome as is another pair of eyes :)

Can't help a LICK with coding , but you know as always I am happy to help you with testing and user docs.. So if you need another "set of eyes" from this perspective ya know how to find me..

[dw08gm]

I got lost when they started talking about uprids.

[DivaVocals]

I got lost when they started talking about uprids.

Uh huh.. So I'm sticking with what I DO know..

[dw08gm]

Updated Installation Page in readme.

cheers

[lhungil]

...
Also in edit_orders_functions.php around line 747 in eo_update_order_subtotal()

I have wrapped the $shown_price calculation in a check for whether prices are displayed with tax, and removed the tax calculation accordingly ...

Found some other potential issues related to the tax calculations. As a temporary work around (until I can dig into the needed changes more extensively) you will also want to make sure DISPLAY_PRICE_WITH_TAX and DISPLAY_PRICE_WITH_TAX_ADMIN are both set to the same value ('True' or 'False').