Provide ability to provide Order Total and filter line item types

I too am interested in this: an order total value to be used in Rules as a condition, that only includes the product value total (and not other items such as taxes and shipping).

sub

+1

I am also interested in a similar function - It would be great if we could be able to get the sub total by price component.

Maybe make the commerce-order:order-total:total with different tokens ?
-> commerce-order:order-total:total:(price_component_name)

There's actually a condition in the Shipping module you can use to check to see if an order already includes shipping. You can use this to only make certain types of shipping available if others haven't already been selected. See my comment in #1292524-8: Shipping line items should be deleted on other order statuses, too.

I'll leave the feature request open, though, as we have an API function for totaling line items filtered by type, so there's no reason not to have a Rules condition that does the same thing.

For #4 we have an issue already opened: #1232320: Price components: display and rules integration

#5 detail: commerce_line_items_total() takes a filter of line item type. So turning this into a rules condition would have great value.

Here's a patch to handle the basic concept.
I couldn't find a way to do a few things cleaner (which there may not be), but this should at least be a reasonable starting place.

csevb10++ - Looking forward to reviewing.

This patch builds on csveb10's excellent work by adding another property for product-line-item types only, and then also providing a complete condition for comparing order total, fully configurable for any selection of line item types.

The patch now includes

• Accessing total by line item type using the regular "data comparison" features of Rules.
• Accessing the total of "product" line items (line items of types which have ->product == TRUE). Again, this uses the regular data comparison features of rules
• A condition for comparing a value to the total of line items of user-selectable types. In other words "If the order total is greater than x, less than x, etc.", but with the ability to choose what line item types are included in the total.

So testing can include using a product pricing rule that uses those 3 techniques and verifying correctness. It would be interesting to do it with shipping calculations as well, but it seems to me like product pricing will work fine for testing this out.

Rogue theme included all of drupal core. #1372400: How to Install

#10: commerce.order_total_rules_1245928_10.patch queued for re-testing.

I added to #10 some guidance on how to test the patch.

#10: commerce.order_total_rules_1245928_10.patch queued for re-testing.

Wonder if we could get this in the current round of commits.

Would #1301022: Action: type conversion for numbers, integers, and strings help here?

i think that this patch insn't applying cleanly in the last release... am i right?

thanks

> i think that this patch insn't applying cleanly in the last release... am i right?
Nope, there's no issue of whether or not the patch applies, it's been committed in -dev since #23, so everything after that point in the issue is an unexpected addition to the earlier patch that will be added before the next release.

@mitchell #23?
my post was #18

now i see that you were talking about the other issue...

i'm talking about the patch in #10 in this issue

@brunorios1: whoops.. totally my fault.

I'd recommend people here to try Commerce price by components so you can select the price component to compare in any price.

#10: commerce.order_total_rules_1245928_10.patch queued for re-testing.

Straight reroll of #10

@pccambra: i tried Commerce price by components, but the data selector "commerce-order:commerce-order-total:base-price" only give me the data comparison options "equals" and "is one of" and to offer free shipping based in price, i need the options "is lower than" and "is greater than"...

i'm using this method: https://vimeo.com/32692562

thanks!

@brunorios1 you're right, I've moved the component to be a commerce price instead of a struct, if you get the latest dev, you'll be able to use the amount.

@pcambra: i need to use the data "base-price" with comparison "is greater than" and "is lower than"... is possible?

i updated the module and:

1) i created a condition in my flat rate service "free shipping" using "commerce-order:commerce-order-total:base-price:amount" with "is greater than: 9989"

2) i added a product that costs 99.90 to the shopping cart

3) but the "free shipping" service was NOT displayed

thanks

Hmm. Not sure what went wrong with #25. Trying again; straight reroll of #10.

#30 works cleanly!

@brunorios1, well if you test it and it works for you, please RTBC and maybe we can get it in. Hate to work on something like this and lose it in the queue.

Works perfectly!

I have the same issue.

1. my base price/Sub total was $11.70
   • 
2. I set a rule to "Add a rate for a shipping service to an order" with the price of $0 if commerce-order:commerce-order-total:base-price:amount was greater than 1 (a penny) and it did not show up
   • 
3. Then I changed it to be less than 1 penny (which obviously it's not) and it appeared

@pcambra: Do you know why this is?

Added an issue: http://drupal.org/node/1710166

Reviewed this and need to move it out of RTBC for a few touch-ups:

1. We don't need commerce_line_item_types_options(), b/c we already have commerce_line_item_type_options_list().
2. I'm not sure we need the individual properties along with the condition. The reason I hesitate is that once we put new properties out there we can't take them away, so I want to be very sure before adding new ones (like my debate over the "floated amount" property proposal currently used in Kickstart 2.x). I may just go ahead and commit the condition alone and revisit the pseudo-properties later.

I'm trying to create a total base price comparison in order to appy different discounts to each order's total (total including VAT) but based on order's total base price (total excluding VATs).

But token [site:current-cart-order:commerce-order-total:base-price:amount] is only available for data comparison conditions and when I change the OPERATOR from "equals" to "lower than" or "greater than", I can only select a Data Selector, not type a value myself. How can I compare an order's total base price (excluding VATs or other components, including ONLY the total of products' base prices) to a specific value (with greater than/equals or less than/equals operators)?

Patch in #30 works nicely for me to add a "Order total comparison" condition, where I can select just Products to get the order total without shipping being included.

If you could add just that new comparison, then "Free shipping for orders over £xxx" becomes possible.

The patch in #30 works well.

An alternative is to add a PHP code condition to your shipping rules.

For example, if you wanted free shipping for orders over $25.00, calculated on product types only, excluding taxes and shipping, add an "Execute custom PHP code" condition on your shipping rule page, and add the following code:

$threshold = 2500;
$wrapper = entity_metadata_wrapper('commerce_order', $commerce_order);
$line_items = $wrapper->commerce_line_items->value();
$product_line_item_total = commerce_line_items_total($line_items, array('product'));
$total = $product_line_item_total['amount'];
return $total >= $threshold;

Make sure there are no tags around the code. I added those above for syntax highlighting.

but, execute custom php code is a very bad practice

#39: More info needed.

(...) Through the PHP filter, users with the proper permission may include custom PHP code within a page of the site. While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user. (...)

more info: http://drupal.org/documentation/modules/php

I think you're talking about another issue entirely, which is user access.

@jmljunior,

you're right...
sorry!!!

What's the status on this?

As far as I can tell, everyone who is trying to implement free shipping over a certain amount and does not use a custom defined rules event but the standard "Order balance comparison" rule (as recommended in various documentation articles), will be guilty of providing free shipping if you manage to have the shipping cost offset the free shipping threshold?

It's an edge-case bug, but pretty serious I'd say since you are giving away unwillingly, unless I am missing something...

Patch in #30 still applies OK, albeit with some offsets, to commerce-7.x-1.8.

It would be nice to get this patch into the module.

#38 works well for me but still - something like that should be in Commerce

I'm using jmljunior's code in #38 to get shipping rules based on order totals and it works great except when using percentage coupons.

Here's the code I'm using:

$max = 50000;
$min = 20000;
$wrapper = entity_metadata_wrapper('commerce_order', $commerce_order);
$line_items = $wrapper->commerce_line_items->value();
$product_line_item_total = commerce_line_items_total($line_items, array('product'));
$total = $product_line_item_total['amount'];
return ($total >= $min && $total < $max);

Is it possible to get the order subtotal without using line items?

Any help would be really appreciated! Thank you!

This is probably the third or fourth time I have had to re-roll and re-apply this patch to drupal commerce, starting back at 1.6, then 1.7, 1.8 now 1.10. Yes, it would be really, really good to finally get this in.

and...now having to re-apply for 1.11. Going on almost 4 years...

Per #49 perhaps we need to set the status to Needs Review. I'll set it to 1.11 since this is related to / affects the latest stable Commerce release.

I'll set this back to Needs work per Ryan's comments in #35.

@meecect: Are you a coder? Are you able to address his comments? For example:

Reviewed this and need to move it out of RTBC for a few touch-ups:

1. We don't need commerce_line_item_types_options(), b/c we already have commerce_line_item_type_options_list().
2. I'm not sure we need the individual properties along with the condition. The reason I hesitate is that once we put new properties out there we can't take them away, so I want to be very sure before adding new ones (like my debate over the "floated amount" property proposal currently used in Kickstart 2.x). I may just go ahead and commit the condition alone and revisit the pseudo-properties later.

Re-rolling the patch based on these comments, or at least discussion of these points, would help more in getting this patch committed than just leaving comments about how long it has taken to get it committed.

I am, but I'm not sure I have the bandwidth right now. Let me take a look at it and see what needs to be done.

well, I can address #1 and fix up a patch.

For #2, I would prefer keeping the properties. The reason being that just having the condition would work well for getting the order product totals _as a condition_, but there are other times when you want to do calculations on totals of other types of products.

For example, you need calculate a percentage off shipping costs, or you need to apply a fee based on the total shipping costs, or calculate a coupon effect the order subtotal and adjust taxes, etc. Not to mention that taking out the properties breaks 49 different shipping rules on my production site ;-)

To Ryan's point, yes, since the properties were there, and if they are committed, then no, we can't take them away anymore, however, the only reason I'm using this patch is because those properties are there.

I think they are useful properties, for what it's worth.

Hey everyone! Are there any updates for this issue? I've a shipping method which sets free shipping if you reach 99$ Cart-Content. If you go with e.g. 99$ to the checkout it adds the shipping fee and you come over 99$. So with a simple back and forward in your browser it is possible to get free shipping because the system "thinks" that you are over 99$. The recaluation does not fire again.

Would be awesome if there were any news about the patch from #30 to use order total without shipping costs

cheers!