The order is optional and must be passed as an "order" key in "$args".
If present, the order customer will be passed to "WC_Tax::get_rates"
in order to calculate the taxes to substract (provided that
"$product->is_taxable() && wc_prices_include_tax()")
Also "WC_Abstract_Order->add_product" and "WC_AJAX::maybe_add_order_item"
are modified to pass the order being processed so that ultimately
"wc_get_price_excluding_tax" uses it.
This prevents the base tax location to be wrongly used instead of the
customer location when the "woocommerce_adjust_non_base_location_prices"
hook is set to return false.
This method will prioritize getting rates from billing/shipping address instead of `WC()->customer` which in irrevelant in context of editing order from admin screen.
We were not passing tax location while computing discount in orders, hence it was defaulting to shop's base address resulting in incorrect tax calculation.
This commit refactors `get_rates` method into another method that allows getting rates from location directly.
There's a number of places in the WooCommerce codebase where the
built-in function 'round' is executed passing a non-numeric value
(not a number and not a string that can be parsed as a number),
for example round(''). In PHP 7 this yields a value of 0, but in
PHP 8 this throws an error.
This commit adds a 'NumberUtil' class with a static 'round' method,
this method checks if the passed value is numeric and if so it just
executes the built-in function, otherwise it returns 0. And all the
calls to 'round' in the codebase are replaced with 'NumberUtil::round'.
We round in `get_subtotal` because its a front-end method. If more precision is required then `get_cart_subtotal_for_order` needs to be called. Also use same `get_cart_subtotal_for_order` method here as well for consistency.
We were calculating subtotal to display slightly differently then we would have calculated subtotal in the cart. This was affecting subtotal value in invoices and in order confirmation screen.
This patch updates how we calculate subtotal to display such that we calculate in same way.
We added a trait to move shared logic betweem Orders and Cart. This commit refactors Order class to use that shared logic.
Also adds a test for a failing case.
`WC_Abstract_Order` and `WC_Cart_Totals` have their own logic to calculate totals. This means that we would have to fix in two places. This commit adds a trait which can be used to place shared logic between above two classes.
When we refund fee and some other line item whose value is more than fee in a single requst, value of line item will overwrite refund fee.
This is because where we check to make sure that we do not discount more than total possible value (to prevent negative total), we do not account for the fact that sometimes the cart could contain refund items. In those cases max_discount * -1 will always be larges then fees total.
This commit adds a check to make sure that max discount * -1 is indeed negative before overwriting fee total.
* fix the coupon usage limit issue
* fix the if condition for the usage limit
* fixed coding standard
* fix the if conditions for coupon usage limit per user
* Add functionality to wp-admin order to check for coupon usage based on email addresses, similar to how WC_Cart handles this seperately, included unit tests.
* Only do the coupon by email usage check if order is from a guest. Fix issue with unit test.
Nestor Soriano
James Allan
roykho
Claudio Sanches
Gregory Karpinsky
vedanshujain
Nestor Soriano
Daniel Morell
Rodrigo Primo
Peter Fabian
Francesco Leanza
David Levin
Matt Harvey
Jared Burke
Ajay Ghaghretiya
Gerhard Potgieter
Boris Djemrovski
James Allan
Daniel Bitzer