Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is using:
- Drupal 7.42
- Inline Conditions 7.x-1.0-alpha5
- Commerce Discount 7-x.1.0-alpha and 7.x-1.x-dev
To reproduce:
- Create New Discount
- Choose Discount Type "Order Discount"
- Under "Order discount conditions" -> "Apply To", select "Product(s) and quantity"
- Enter any existing product name and set "quantity equals" to any integer
- Complete the "Choose offer type" (there appears to be another css bug which I'll open another issue for)"
- Save discount
- Try to apply discount (it will not)
- Edit the reaction rule for the created discount and you'll get the error:
Warning: call_user_func() expects parameter 1 to be a valid callback, function '_inline_conditions_order_operator_options' not found or invalid function name in RulesDataUI::renderOptionsLabel() (line 155 of /Users/chrisrockwell/Sites/quick-drupal-20151129042144/drupal-7.x/sites/all/modules/rules/ui/ui.data.inc).
There are a couple ways to fix this. I'm going to attach a couple patches in hopes of getting feedback. I prefer patch #2 (commerce-discount-7.x-options-list-function-doesnt-exist-2.patch) because it aligns the options available in the discount with what is used within the rule. However, it's entirely possible that it should be aligned with `commerce_discount_rules_condition_info()`.
Comments
Comment #2
chrisrockwell CreditAttribution: chrisrockwell commentedFixing patches; realized they had .txt when I tried to use drush-patchfile.
Comment #3
chrisrockwell CreditAttribution: chrisrockwell commentedAnd the second one.
Comment #4
chrisrockwell CreditAttribution: chrisrockwell commentedI just realized I didn't include the module_load_include which is required for patch #2; I'll submit another patch shortly.
Comment #5
joelpittetThanks for the patch @chrisrockwell.
Here's a review: The nitpicks are for your reference, I'd have fixed them on commit if it was just those.
Maybe we should use the existing _commerce_discount_operator_options?
nitpick: white space at end of line added.
Typo added
Nit: all sentences with periods at the end.
Please if you post another patch set the status to "Needs Review". They get more attention with patches. https://www.drupal.org/node/156119#needs-review
Comment #6
joelpittetOh and make the patch relative to the commerce_discount modules. With
git diff --relative
flagComment #7
joelpittetComment #8
chrisrockwell CreditAttribution: chrisrockwell commentedThank you for the feedback @joelpittet. I've made the changes noted in 2,3, and 4. 1 is addressed by the first patch (most up-to-date is in comment #2: https://www.drupal.org/files/issues/commerce_discount-inline_conditions_...). The reason for creating the alternate (#3) is that what is returned by _commerce_discount_operator_options() isn't consistent with the options available when creating the discount.
And thank you also for the tip on --relative - I've been trying to figure that out since the first patch I submitted.
Comment #9
chrisrockwell CreditAttribution: chrisrockwell commentedComment #11
joelpittetSorry for being a dunce but I can't follow how the patch resolves the problem in the issue summary.
I wonder if there is a reason for not just using the same callback for the options list too.
Comment #16
chrisrockwell CreditAttribution: chrisrockwell commentedHi @joelpittet,
I probably muddied the waters by submitting two different patches for the same issue. They both solve the issue, but I'm not sure that either are the right way to do it.
The first patch updates the 'options list' (http://cgit.drupalcode.org/commerce_discount/tree/commerce_discount.rule...) to use the existing callback. However, the callback that I think you're referring to (http://cgit.drupalcode.org/commerce_discount/tree/commerce_discount.rule...) doesn't return the same options that are used when building the actual discount: http://cgit.drupalcode.org/commerce_discount/tree/commerce_discount.inli...
Are you suggesting we simply update commerce_discount.inline_conditions.inc to use the existing callback? If so, that *sounds* like a good idea to me but I haven't researched enough to know why only those three options (the ones on line 426 of commerce_discount.inline_conditions) were given. If we can safely use all 5, this would bet the best way to go, in my opinion, and we should also use that callback in the form builder.
Because of that....
The second patch just adds the function that doesn't exist, and returns the same options to rules that are available when creating the discount. I went back through a couple versions, and searched a lot of code assuming _inline_conditions_order_operator_options() existed at some point ( I never found it). Then I updated it the form builder to use the same callback.
Does that clear it up at all?
Comment #17
joelpittetKinda hairy but I think I understand:)
I'd like to use the same callback actually for both. One reason is you will notice the default operator is
'>='
for thecommerce_order_has_specific_quantity_products
condition. Which isn't available in that callback.I just turned on the label and changed it to 'Quantity'. Also defaulted the the value to 1 because it's nothing and that's not good UX.
And needed to include the rules.inc file to get access to that function.
I've committed this to dev. Please download and give it a try. Re-open if I made a mistake.
Comment #19
chrisrockwell CreditAttribution: chrisrockwell commentedI hope it's OK to re-open this, I think we missed something: The callback for inline entity conditions doesn't account for the new comparison operators (<=, >=) so they never kick-in as discounts.
To reproduce:
Please see the attached patch.
Comment #20
joelpittetWe should probably put in a couple test cases to ensure this is working too. Thanks @chrisrockwell. I'll commit that in a moment. Just a quick note, the whitespace should likely be trimmed in your editor, most editors can do this on save for you. Sometimes they don't and it's accident (phpstorm save on same line for instance).
I'm fine re-opening this, it's an obvious oversight. Thanks for the patch!
Comment #21
joelpittet