Condition based on order subtotal instead of order total

Marked #2934747: Create OrderSubtotalPrice condition and #2993928: Add promotion condition for order total with and without shipping as duplicate.

My gut feeling is that we're better off adding a setting than a separate condition, but let's see what the others say.
Also, open question if subtotal/total is enough of a distinction, VS being specific about which adjustment types should be included in the compared total.

Here's a working patch for 8.x-2.13

I prefer to have an option instead of an additional condition plugin.

I updated the patch to work with Drupal Commerce 2.14

Just a reroll (since the patch from #6 doesn't apply), this needs tests, and I'm also wondering if we should expose an "adjustments" setting that'd let people choose which adjustments should be included in the total calculation. (If you'd like to exclude promotions for instance from the subtotal).

I'm still unsure what makes more sense between this approach and a separate condition.

From a user experience standpoint, I think differentiating at the point of condition selection between "order total" vs. "order subtotal" makes more sense. +1 for the new condition approach, which leaves "order total" checks simple and could also let us do something like:

• Current order subtotal
• Include the following prices in subtotal calculation:
  • Order items
  • Shipping
  • Taxes

The idea being a "subtotal" is loosely defined ... it makes room for us to include not just the order item subtotal but other adjustments in the sum that we're comparing against. I always wanted promotions to support this in Commerce 1.x, would love to see such a condition land in 2.x.

Ok, here's POC (no tests included) of adjusted total price condition plugin, based on order_total_price, that simply subtracts adjustments of certain types (configurable) from the order total. Obviously, this could also go the other way (subtotal + selected adjustments) but one of the use-cases mentioned above is making free shipping available only if order total excluding current shipment amount is not greater than a certain amount.

#11 fixes the issue I was having when the user selects a shipping method that made the order total get over the limit to have the free shipping promotion, then he would go back and because the order total now was over the shipping limit he would checkout with free shipping (shouldn't happen.

The UI was very clear to me how to setup.

Thanks!

#11 is working for me. Setting it to RTBC. BTW, I have also added the related patch for the commerce currency resolver here https://www.drupal.org/project/commerce_currency_resolver/issues/3162601...

One condition in my opinion seems maybe a better solution. (landing from a linked issue here)

Two conditions - order subtotal and total, even if that seems user friendly but could lead to having both selected at once? And on top, we are going just to make derivate of the existing order total code.

I like more idea to have one condition which would be generic, named Order amount.
Where a person could choose between:
Order total and order subtotal, and in addition if order total is chosen, then adjustments could be filtered.

That condition should cover 99% of cases, and avoid potentially selecting two similar conditions.

The patch in #11 doesn't work at the moment. If you select some adjustment types then it's impossible to remove them again. Not sure how to fix this properly as I'm unfamiliar with this type of implementation. My quick and dirty fix is to unset the adjustment types before they are saved to the configuration like this:

foreach ($values['adjustment_types'] as $adjustment_type => $val) {
  if ($val === 0) {
    unset($values['adjustment_types'][$adjustment_type]);
  }
}

Also I agree with #14 that offering both these conditions at the same time is a no go, but I don't see why we need to ever offer the old one when this one does all it does and more. Also I don't think "subtotal" is a defined concept in Commerce 2 so we can't have that as an option. Like you describe subtotal as without tax, but I would define it as with tax. Letting the user choose is probably the only sensible option?

I would be happy if these changes were made:

1. The inability to select which adjustment types are subtracted needs to be fixed obviously.
2. Add these extra features to the existing "Order total" condition rather than add this as a separate condition.
3. Reword the title and description for the adjustment type section to make it clear that these are optional "advanced" options if you want or need them.

The patch in #11 is working properly for my use case.
I did not encounter bug reported in #15 while setting up my shipping methods.

Patch from #11 works great for our site using Drupal 9.3.9 and Commerce 2.29.0 .

I'm not having the problems from #15, but agree with @Twiik, that we won't need OrderTotalPrice.php and OrderAdjustedTotalPrice.php at the same time. The old condition could just be ditched, when changes from #11 are merged into OrderTotalPrice.php.

Patch #11 is working on our site.

Just a small bug when editing an existing condition:

1. Add a shipping method
2. Enable "Adjusted current order total"
3. Setup the condition and check "shipping cost" under "Substracted adjustments"
4. Save shipping method
5. Now edit the same shipping method
6. Now also check "fees" under "Substracted adjustments".
7. Save shipping method
8. Now the bug: The "Substracted adjustments" hasn't been updated (it only has "shipping cost" checked and not "fees"). The only way I can make it change is by also changing the price, then it does update.

sorry I'd like to delete that comment. I found out I had an unrelated bug in my composer patcher.

#11 works on my end too

The patch in #11 works for me as well.

But I have one remaining issue. When using this for a promotion that gives a discount on the shipping fee, the promotion is only applied after saving the order. Hence when continuing in the checkout flow to the next step. This is a problem when using AJAX to recalculate shipping costs. The order totals fetched via AJAX don't apply the promotion correctly, but after clicking the "Continue" button, the promition is applied correctly.

After reviewing this with jsacksick today in the context of a client using the patch in #7. I actually can't remember why I thought it would be better for us to have a separate condition as zaporylie implemented for us in #11. The issue I have with it in hindsight is that it's now ambiguous - which one should I be using? Is the regular "Order total" condition somehow not a current order total?

Additionally, I think I may have introduced some scope creep in responding to bojanz re: how to accommodate different adjustment types. Sufficient for the day is its own trouble ... we could have just landed a patch that differentiated between the current order total vs. order item subtotal a while back and figured out how to further subdivide in a follow-up issue.

I propose we go back to jsacksick's patch for now with some slight adjustment to the labels:

Total to compare against

1. Order total
2. Sum of order item totals

Totals used may include prior price adjustments.

The point of the description is to try to make it clear what "current" means ... the problem is these conditions are used in multiple contexts, and "current" isn't terribly descriptive. Then we can create a follow-up issue to add a third option that would let us get to some sort of price + adjustments selection widget.

Added slight adjustment for label and tests

Fix for failed tests

One thing that was forgotten including in the patch from #7 is the schema update (commerce_order.schema.yml) we need to add the new setting there.

Committed, thanks!