Problem/Motivation
With the changes to the Discount UI, the name property in the discount's price component, which had consistently held the value "discount", can now take on any user defined value. This makes it impossible to reliably identify through the name property those price components that are discounts.
This change broke my custom module, but I based my module on the commerce_discount_date and commerce_discount_usage modules, so I suppose those modules may not function correctly now if the name value is changed by a user.
I think the only way to reliably identify a discount now is indirectly, by inspecting the $component['price']['data'] array to see if it contains a key called "discount_name".
Proposed resolution
An explicit method of identifying any type of price component would be a good idea, imho.
Price components could have a price_component_type identifier in addition to the name, price and included fields.
Alternatively, the name fields could be removed/hidden from the UI so the end user would not be able to modify the value.
Related Issues
This is somewhat related to this issue regarding component titles: https://drupal.org/node/2034685
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | commerce_discount-help_identifying_discount_component_price-2053807-7.patch | 593 bytes | jkuma |
| #2 | discount_price_component_name_set_incorrectly-in-price-calc-rules-2053807-1.patch | 665 bytes | vuzzbox |
Comments
Comment #1
jkuma commentedHi vuzzbox,
Thanks for your very accurate post! I was encountered the same issue when I was implementing that feature request #2034685: Discount component price names. Unfortunately, we can't change the component price system, so that's why I took the decision to alter the component price name for two reasons:
Regarding your proposals, here are my answers:
Yes, it could be definitively very useful for your custom_module and others modules. So, if you want to take that way in order to solve your issue, please let me know and i'll create a patch for it.
This issue is not related with commerce_discount, but it's dependents of commerce module. Feel free to open an issue in commerce and you can link that post as an example of implementation.
No. This feature request was long-awaited by merchants and helps user to identify which discounts are currently applied on order. From my perspective, Merging every discount component price in the same container is not relevant for customers.
Comment #2
vuzzbox commentedThanks for your reply goldorak.
I completely understand and agree with your points. However, I've looked into it a little deeper and I think that something unexpected is happening, a bug really. I'm changing the title of the issue to make it more accurate, changing the category to bug report and providing a patch.
It turns out that Commerce core (or Commerce Pricing) already defines price component types and when calculating the sell price, it stores the name of the component type in the "name" property of the component (why not call it "type"??)
I think the commerce_discount module is inadvertently setting that name value (i.e. price component type) incorrectly during the sell price calculations.
In the code below, I am showing the structure of the price components for a single line item that has two discounts applied to it, during the sell price calculation:
You'll note that the values in
components[N]['name']andcomponents[N]['price']['data']['discount_component_title']are identical. However, thecommerce_pricingmodule wants the "name" value to represent the name of price component type (see the function definition below.) Based on that, I think "name" should be a fixed value for each type of component, and not a user-defined value.In
commerce_discount.rules.inc, thecommerce_discount_add_price_componentfunction calls thecommerce_price_component_addfunction on line 361:The second value passed to the function,
empty($component_title) ? 'discount' : $component_title, contains either the discount_component_title or 'discount', but, again, per the function definition, that should be the component type name only, i.e., 'discount'.Here's the
commerce_price_component_addfunction definition fromcommerce_price.module:So, I think the call to the function should be changed to:
I've tested the patch and
discount_component_titleremains unchanged and the still presents correctly on the cart, checkout pages, etc.Let me know what you think, goldorak.
Thanks!
Comment #3
jkuma commentedHello vuzzbox,
Thanks for your patch but unfortunately that doesn't solve the issue.
e.g - here is a screenshot without your patch applied :
without patch
And the screenshot bellow is the one with your patch applied:
patch applied
As you can see, the line items have been combined in one line item. Why? During the
commerce_order_calculate_total($order), Commerce is combining the line item's component prices into the order total. If you take a closer look to that function:So all the component prices with the same name are merged into the same component price. So, if we are using the name "discount" for every discount component prices, we can't split the component prices , that's why I took the decision to change the name when creating a discount component price. I know it's a dirty solution, but I can't find an another way to do it....
Comment #4
vuzzbox commentedRight! I see that is the problem. Thanks for providing that detail. It happens that the module I am writing eliminates all but the single highest valued discount that applies to a line item. I was only seeing only one discount per item with or without the patch.
Either way, I need a simple, obvious value to test if a component is a discount. So how about a compromise: why not prepend "discount-" to the name of a discount component? For example, "discount-prod1 10%", "discount-prod2 35%"
That would consistently identify discount components, but still provide the distinct values that are needed to present each component individually.
Something to consider.
Thanks!
Comment #5
vuzzbox commentedAnd in my opinion, it would also keep the commerce discount components in closer compliance with the intent of the architecture of Commerce Pricing module.
Comment #6
jkuma commentedOk vuzzbox, let's do it this way.
Comment #7
jkuma commentedLet me know if it fits your needs.
Comment #8
jkuma commentedComment #9
vuzzbox commentedPerfecto!
Comment #10
jkuma commentedCommitted in 7.x-1.x-dev branch.
Comment #11
jkuma commented