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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TR’s picture

Status: Active » Postponed (maintainer needs more info)

What type of options are you having a problem with? Checkbox? Radio? Select? Textfield? All of these?

fizk’s picture

Status: Postponed (maintainer needs more info) » Active

Having 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!

fizk’s picture

Status: Active » Needs review

Line 64 in ubercart/uc_attribute/uc_attribute.ca.inc should be:

if (isset($attributes[$attribute->name]) && in_array($option->name, $attributes[$attribute->name])) {
anschauung’s picture

I'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.

neclimdul’s picture

Status: Needs review » Closed (duplicate)

Turns 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.

anschauung’s picture

@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)

sheise’s picture

Hi,

Here is a patch that addresses the issues in #4.

It does the trick for me.

Jody Lynn’s picture

Status: Closed (duplicate) » Needs review
longwave’s picture

Title: Condition: Order has a product with a particular attribute option » "Condition: Order has a product with a particular attribute option" is broken
FileSize
2.23 KB

Patch 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.

jerry’s picture

Subscribing.

longwave’s picture

@jerry: Please test the patch in #9, if it works for you then it can be committed to Ubercart for the next release.

jerry’s picture

I have, and it does. Thanks, longwave.

longwave’s picture

Status: Needs review » Patch (to be ported)

Committed. Needs porting to the Rules equivalent in 7.x.

TR’s picture

Version: 6.x-2.2 » 7.x-3.x-dev

Moving to the Ubercart 3.x issue queue.

dave.hussey’s picture

Was this patch committed to the 6.x dev version of ubercart?

dave.hussey’s picture

we 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

dave.hussey’s picture

Status: Needs work » Patch (to be ported)
longwave’s picture

Island Usurper’s picture

Status: Patch (to be ported) » Needs review
FileSize
2.54 KB

Oof. 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.

Island Usurper’s picture

And 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.

longwave’s picture

Shouldn'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!)

Status: Needs review » Needs work

The last submitted patch, 721412_attribute_condition.patch, failed testing.

matthand’s picture

Status: Needs work » Needs review

#20: 721412_attribute_condition.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 721412_attribute_condition.patch, failed testing.

castroarguello’s picture

@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

fizk’s picture

@castroarguello, yeah, I thought I fixed this a long time ago for me :P Oh well, some things never die.

longwave’s picture

@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.

castroarguello’s picture

@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.

fizk’s picture

castroarguello: so this is still broken in 7.x?

castroarguello’s picture

Status: Patch (to be ported) » Needs work

I haven't tried 7.x yet. I cannot confirm or deny if it is solved.

stewest’s picture

Hi. 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

TxAvA’s picture

Same!

longwave’s picture

What 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?

TxAvA’s picture

Sorry. Same problem as sideswitch

longwave’s picture

So 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.

TxAvA’s picture

- 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

stewest’s picture

Hi.

@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?

stewest’s picture

A 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.

longwave’s picture

Status: Needs work » Needs review
FileSize
2.24 KB

This 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.

3CWebDev’s picture

Thanks! Works perfect to fix the "Order has a product with a particular attribute option" condition bug I was experiencing.

longwave’s picture

Status: Needs review » Fixed

Committed 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.

stewest’s picture

Hi, thanks for the update.

I'll try the latest release and see if it fixes things.

Thanks again

Cayenne’s picture

I 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...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hockey2112’s picture

Issue summary: View changes

Hello,

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:

{ "get_quote_from_flatrate_2" : {
    "LABEL" : "Local Pickup conditions",
    "PLUGIN" : "and",
    "OWNER" : "rules",
    "REQUIRES" : [ "uc_attribute" ],
    "USES VARIABLES" : { "order" : { "label" : "Order", "type" : "uc_order" } },
    "AND" : [
      { "uc_attribute_ordered_product_option" : { "order" : [ "order" ], "option" : "26" } }
    ]
  }
}

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!

hockey2112’s picture

Version: 7.x-3.x-dev » 7.x-3.6
Status: Closed (fixed) » Active
longwave’s picture

Status: Active » Closed (fixed)

Please 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.

hockey2112’s picture