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.
I've set up an attribute which contains a few options. When the user has made the order, I'm having the admin update the order to complete. I am trying to add an admin comment to the order if an order includes a particular attribute option. Simply, with the attribute condition included in this action, the trigger never seems to be fired and the comment is never added. As soon as I remove that attribute condition, it works correctly and the comment is added.
Comment | File | Size | Author |
---|---|---|---|
#39 | 721412-uc_attribute-condition.patch | 2.24 KB | longwave |
#20 | 721412_attribute_condition.patch | 2.74 KB | Island Usurper |
#19 | 721412_attribute_condition.patch | 2.54 KB | Island Usurper |
#9 | 721412-uc_attribute_condition.patch | 2.23 KB | longwave |
#7 | uc_attribute_action_721412.patch | 816 bytes | sheise |
Comments
Comment #1
TR CreditAttribution: TR commentedWhat type of options are you having a problem with? Checkbox? Radio? Select? Textfield? All of these?
Comment #2
fizk CreditAttribution: fizk commentedHaving this problem too. I'm using checkboxes.
This is affecting more than just a few people:
http://www.ubercart.org/forum/support/15440/condition_order_has_product_...
Please fix!
Comment #3
fizk CreditAttribution: fizk commentedLine 64 in ubercart/uc_attribute/uc_attribute.ca.inc should be:
Comment #4
anschauung CreditAttribution: anschauung commentedI've had the same problem. There seems to be at least two problems with function uc_attribute_condition_ordered_product_option:
1) It checks for isset($attributes[$attribute->name]), but the name returned by uc_attribute_load($option->aid) a few lines earlier might not be the same name as the one attached to the order, since users can specify new labels for attributes
2) $attributes[$attribute->name] == $option->name always fails in my tests, since the $attributes are indexed by number and not by name;
I'll look into it a little deeper and see if I can suggest a patch. In the meantime, #3 seems to fix the problem so long as you don't customize the attribute labels for individual nodes.
Comment #5
neclimdulTurns out this is really a duplicate of #600892: Attribute Value Based Tax Rules Disappear Between Checkout and Review. I've posted a patch over there that fixes what sounds like the same problem listed here.
Comment #6
anschauung CreditAttribution: anschauung commented@neclimdul:
I'm not sure if this is really a duplicate, expect that they both might be symptoms of the same problem elsewhere. This particular issue stems from how $attributes[$attribute->name] == $option->name always compares integers to strings, and thus returns false in most cases.
Your patch didn't effect this in my tests (though it seems to solve the issue you described in the other thread)
Comment #7
sheise CreditAttribution: sheise commentedHi,
Here is a patch that addresses the issues in #4.
It does the trick for me.
Comment #8
Jody LynnComment #9
longwavePatch attached that reworks #7 from this thread and #10 from #600892: Attribute Value Based Tax Rules Disappear Between Checkout and Review into a single patch. This now appears to allow CA to correctly test checkbox options (and other types), both for items that are still in the cart (which have numeric keys) and ordered products (which have string keys).
The root cause of this issue and the linked one is from when checkbox options were first introduced; the format of $product->data['attributes'] changed (if it wasn't confusing enough already) but uc_attribute_condition_ordered_product_option() was never updated to match.
Comment #10
jerry CreditAttribution: jerry commentedSubscribing.
Comment #11
longwave@jerry: Please test the patch in #9, if it works for you then it can be committed to Ubercart for the next release.
Comment #12
jerry CreditAttribution: jerry commentedI have, and it does. Thanks, longwave.
Comment #13
longwaveCommitted. Needs porting to the Rules equivalent in 7.x.
Comment #14
TR CreditAttribution: TR commentedMoving to the Ubercart 3.x issue queue.
Comment #15
dave.hussey CreditAttribution: dave.hussey commentedWas this patch committed to the 6.x dev version of ubercart?
Comment #16
dave.hussey CreditAttribution: dave.hussey commentedwe were referred here, sources suggest this is a core problem fixed in the latest dev, but we're still having an issue... it's particular to a module, but same symptom
http://drupal.org/node/1035700
Comment #17
dave.hussey CreditAttribution: dave.hussey commentedComment #18
longwaveClosed #1085760: Fix for Condition: Order has a product with a particular attribute option as duplicate
Comment #19
Island Usurper CreditAttribution: Island Usurper commentedOof. Looks like the attribute condition was only half-way ported to Rules. As part of applying #9's patch, I also had to refactor the parameters that were actually passed into that function. Instead of $order, it gets the actual product from the order, as well as the option id.
Comment #20
Island Usurper CreditAttribution: Island Usurper commentedAnd now with actual working code.
It may have been some changes to attributes, and possibly something with entity.module. I think since only ordered products will be given to this callback, I believe that only attribute names will be available in the product data. In addition, all of the chosen options will be given as arrays, even if they you can't select multiple options.
I think I need to find my patch to Rules for the Any/All plugins. As of now, you have to select which particular product you want to check on the condition (1st, 2nd, etc.). The allowed selectors only go up so far, and the order that the products were added to the cart matter, then.
Comment #21
longwaveShouldn't this just be "Order has at least one product with a particular attribute option", ie. "any"? That way it can take a full order object instead of a product, and save selecting a specific product or waiting for a patch to Rules (it would be nice to run loops in conditions eventually!)
Comment #23
matthand#20: 721412_attribute_condition.patch queued for re-testing.
Comment #25
castroarguello CreditAttribution: castroarguello commented@fizk
I've tested with this solution (http://drupal.org/node/721412#comment-2933518) and it worked fine.
I found your code more useful than walking through the array with foreach().
Thanks
Comment #26
fizk CreditAttribution: fizk commented@castroarguello, yeah, I thought I fixed this a long time ago for me :P Oh well, some things never die.
Comment #27
longwave@castroarguello, @fizk: So you think this is still buggy in 6.x? Or are you talking about 7.x? In #13 a patch to fix this was committed 11 months ago in 6.x.
Comment #28
castroarguello CreditAttribution: castroarguello commented@longwave: actually, this is resolved in Ubercart 6.2.7, but we're in the process of upgrading the Ubercart and other modules for the site that I am currently working on. As you mentioned, the patch was committed long ago.
Comment #29
fizk CreditAttribution: fizk commentedcastroarguello: so this is still broken in 7.x?
Comment #30
castroarguello CreditAttribution: castroarguello commentedI haven't tried 7.x yet. I cannot confirm or deny if it is solved.
Comment #31
stewest CreditAttribution: stewest commentedHi. Nervous to open another issue/bug, as this is Ubercart 6.2.7 and 6.x-2.x-dev but it is related.
I'd have to mentioned @castroarguello that this is still an issue for me in Ubercart 6.2.7 and 6.x-2.x-dev with Drupal 6.25.
It seems that since I upgraded to Drupal 6.25 (from 6.22), the Conditional actions stopped working where CA = "Order has a product with a particular attribute option".
I had tested this before the upgrade and it worked!? Weird. We even went live because of the successful test, but I thought I'd do a final security update. Updated Drupal then it stopped working.
There is some code here found at http://drupal.org/node/1085760 that might be useful to browse through. I used the code, but still it didn't fix the problem.
I'm at a loss
Comment #32
TxAvA CreditAttribution: TxAvA commentedSame!
Comment #33
longwaveWhat do you mean by "Same!"? Same as which post?
@sideswitch: I am not sure why upgrading Drupal core from 6.22 to 6.25 would cause any issue like this, did you upgrade any other modules at the same time?
Comment #34
TxAvA CreditAttribution: TxAvA commentedSorry. Same problem as sideswitch
Comment #35
longwaveSo you upgraded from Drupal 6.22 to 6.25 and found the exact same issue? Which CA rules have you configured to use this condition, what are they meant to do? Steps to reproduce this would be helpful.
Comment #36
TxAvA CreditAttribution: TxAvA commented- Ubercart 6.x-2.x-dev (6.2.7 same)
- Drupal 6.25 (worked before upgrade)
- 50% fee created
- In CA:
50% fee condition: "Order has a product with a particular attribute option"
In order review the fee is lost :-(
Sorry, I don't speak english
Comment #37
stewest CreditAttribution: stewest commentedHi.
@longwave - I have two sites, almost identical. Both were on Drupal 6.22, and Ubercart 6.2.4. I had tested the CA "Order has a product with a particular attribute option" and it worked on both sites.
I upgraded Drupal Core on both, and on only the one, I upgraded from Ubercart 6.2.4 to Ubercart 6.2.7 and then when that didn't work either I tried 6.x-2.x-dev on the one site. (At the same time as upgrading Drupal Core. It is possible that other modules were also updated... (sorry don't have the logs)
Now, on both sites (even though I didn't upgrade Ubercart on the one site), the CA "Order has a product with a particular attribute option" doesn't work anymore. Could be total coincidence?)
These are my conditions which depending on the attribute of the product bought, sends an email to a particular store (Which was selected by user):
Trigger: A payment gets entered for an order
Condition: Order has a product with a particular attribute
Action: Email Order invoice (to particular email specified)
The order completes, and the user does get their standard CA triggered email of the invoice, but the store who's email was meant to be triggered by the CA doesn't work... (linked to the attribute selected on the product)
Other Conditions also tried to do with Attributes was "Check an Order's Products with a product model (From attribute)" selected which also doesn't work.
Is it possible that because these products with attributes were created before the upgrade, they don't work, and possibly if I recreate the product and its attributes, it may then work?
I'm going to try and then get back to you.
Hope this all makes sense?
Comment #38
stewest CreditAttribution: stewest commentedA quick update note from: (http://drupal.org/comment/reply/721412/5895888#comment-5895888)
(this note has to do with the Drupal 6 version - but seems related to this post. Please let me know if I should be posting this in another queue such as http://drupal.org/node/1085760)
One site 1: Where the "Condition: Order has a product with a particular attribute" seemed to stop working after I updated Drupal Core. Obviously this shouldn't be the cause. I was running Ubercart 6.x-2.4 at the time, and upgraded this site to 6.x-2.7 to try to fix the issue. Still didn't work.
To try to fix the issue: I used the 6.x-2.x-dev (which was, at the time the dev version of 6.x-2.7). Still no joy.
I deleted the attributes, and removed the product. I recreated them all and edit the conditional action. Unfortunately, didn't work. I took a break.
One Site 2: where I had Ubercart 6.x-2.4 and had only upgraded Drupal core.
The above condition didn't work either making me think that the update around when I updated core had something to do with it. But that was odd.
On this 2nd site I didn't try the dev release on site 2. Recently however, I upgraded directly from ubercart 6.x-2.4 to 6.x-2.9 and I upgraded Drupal core and a few other modules (token and some others).
This site's particular attribute condition works now!! Great.
Back to site 1
Seeing the success on Site 2, I went to Site 1 and also upgraded to UC 6.x-2.9 and drupal core, and latest recommendation for other modules needing an update - But, the "particular attribute condition" still didn't work.
I just uploaded the ftp files, as I don't have drush available on that shared hosting. I did run update.php.
That's the latest status for me.
Do you think I should try now to remove the product, attributes and CA and start from fresh?
Thanks again.
Comment #39
longwaveThis patch fixes a number of issues with this condition in 7.x-3.x, and simplifies the logic to make the condition function easier to follow.
Comment #40
3CWebDev CreditAttribution: 3CWebDev commentedThanks! Works perfect to fix the "Order has a product with a particular attribute option" condition bug I was experiencing.
Comment #41
longwaveCommitted to 7.x-3.x, thanks for testing.
@sideswitch: Apologies for not getting back to you earlier, but if you are still having this issue, I am not sure what to suggest next as I cannot reproduce this. If this is still a problem please reopen this issue.
Comment #42
stewest CreditAttribution: stewest commentedHi, thanks for the update.
I'll try the latest release and see if it fixes things.
Thanks again
Comment #43
Cayenne CreditAttribution: Cayenne commentedI installed the patch against the current dev and found that it fixed the problem. See the discussion at http://www.ubercart.org/forum/support/31918/payment_options_product_feat...
Comment #45
hockey2112 CreditAttribution: hockey2112 commentedHello,
Not sure if my issue is related to this one, but thought I should post it here to begin with. I have set up an "Order has a product with a particular attribute option" condition, but the Rule does not seem to be taking that condition into account during checkout. Here is an export of the rule:
In a nutshell, I want the flatrate_2 shipping method to show up in the cart only if the cart product has the attribute option with ID "26".
Thanks for any help!
Comment #46
hockey2112 CreditAttribution: hockey2112 commentedComment #47
longwavePlease open a new issue, this issue is over 18 months old and was considered solved; it is unlikely you are experiencing the exact same problem.
Comment #48
hockey2112 CreditAttribution: hockey2112 commentedDone: https://drupal.org/node/2265569