Integrate with Rules to perform actions when attributes are changed

Just to clarify, this module is not for end-user/customer use. It only makes it possible for people with the 'administer orders' permission to edit the values of product attributes after they have been added to an order. Normally, this can't be done in Ubercart (the product needs to be removed, and re-added in order to change the attributes). This module is not designed to make this data editable by customers, because it would require giving customers access to the order administration interface, which is bad.

As for your request, that might make a good feature request. Maybe we can integrate with the Rules module, and define events that can trigger other actions (like changing the order status). If this is something that would be useful to you, please open a new "feature request" ticket with that as the goal.

If it's the order edit form submission you want to trigger Rules from, then maybe a new event needs to be added to the UC Rules module (http://drupal.org/project/uc_rules). Or, maybe you can achieve the same end using the Rules Forms module that comes with Rules. It allows you to attach Rules actions to arbitrary forms in Drupal.

In terms of this module (UC Order Attributes), maybe we could add an event to the attribute editing form submission, which is separate from the order edit form. Then you could trigger actions specifically when the attributes are edited.

I probably won't have time to dig into this soon, but if you're comfortable coding it shouldn't be hard. Just add a uc_order_attributes.rules.inc with a hook_rules_event_info() function to define the event. Then, add a rules_invoke_event('the_new_event', $args) in the form submission code. It might take a little fooling around to figure out what arguments need to be passed in.

Changing the name of this issue to reflect that it's a request for Rules integration.

Best of luck! If you end up with some working code, please feel free to post it here in the form of a patch.

Do you mean which arguments to pass into rules_invoke_event()? It seems that for your purposes, all you would need is the $order object, right? I think you would be able to trigger an order status change with that.

Sure. Please contact me via my contact form to discuss further: http://drupal.org/user/581414/contact

Patch attached.

(just a first shot at it, might require further improvements)

Note: uc_order_attributes actually works on line items, so you'd need to load the order by [uc_order_product:uc_line_item_id] to be able to do anything to it.

Thanks Drave Robber! Very helpful patch! I haven't tested it, but it looks pretty good.

The one thing I might change is the use of the term "line item". In Ubercart, "line items" are not the same thing as "products" in an order. (In Commerce, on the other hand, all products in orders ARE called "line items".) So for the sake of clarity and consistency, it might be better to call them "product" or "uc_order_product".

Also, I wonder if it would be easy enough to also pass the $order object itself into the rules_invoke_event() function. I haven't looked at the code in a while, so I forget if it's easily available there. But if so, then that would allow more to be done in the conditions and actions, because more of the order's information would be available as well.

My reasoning was that this is p>0.90 likely to be used together with uc_rules, so we can make use of the tokens generated by it (not every line item is a product, true; but structurally product is a line item); but that was what I was thinking between the first and second cup of coffee and seems unnecessarily complex now :)

I don't think we need to preload $object - there might be uses that do not require it (e.g. sending notifications); and uc_rules has an action to load an order by ID.

An updated patch coming.

Patch attached.

In this series, we generate our own tokens regardless of whether uc_rules is around or not.

Awesome. Thanks again Drave Robber.

I agree that it's not necessary to load the $order object, if it can be done via the UC Rules module already. Your explanation makes sense.

Also, providing the tokens regardless of uc_rules makes sense. One thing that should be changed, though, which I didn't notice before, is the location of the Token hooks (hook_token_list and hook_token_values). They should be put into the uc_order_attributes.module file, rather than the new uc_order_attributes.rules.inc file. A similar issue currently exists in the UC Rules module itself (which I provided a patch for) here: http://drupal.org/node/1234052

Sounds plausible. (I'm not that familiar with workings of Token in D6, so I'll take your word for it :) and it won't do any harm anyway)

Patch attached.

I've been thinking about how this would look from UX perspective, and it seems to me that most users would be after 'attribute has been added' and 'attribute has been removed' events. As of #16, we're passing only an array of "new" attributes but "old" attributes aren't even known.

Would like to hear OP's opinion first, though.

I'm going to take another look at this over the weekend and set up a bit more realistic testing environment; you can save me some time if you're willing to share a snapshot of your dev site (provided it doesn't contain some secret world domination plan or other sensitive information :)

your patch for the .module file pertains to line 510 and 710 where the file only has up to 400+ lines.

You're probably using 6.x-1.0-beta5 while the patch is against 6.x-1.x-dev. HEAD is 7 commits ahead at the moment, and quite a lot of code has been added in between. The attached .module file seems OK though.

"Update 2" was [supposed to be] the right way to go;

but obviously I need to tinker with this a bit more.

No, I was looking for a copy of a site (codebase backup + database dump) that I could download and set up on my localhost, just to skip creating orders, products and so on (some stuff can be generated with Devel, but setting everything up still takes a lot of clicking). If there's any sensitive info that takes more than 10 minutes to strip, then this is out of question.

Debugging remotely is like eating your soup with a fork - possible but not very productive :)

Well, then I will need to do some clicking myself.

so far, in my tests the rule does get fired;

without disclosing the world domination plan, what exactly is your use case for this - "throwing back" an order if it gets changed by an administrator? (maybe I can create and export an example rule)

The rule is OK. It is fired, tokens are evaluated, and the order is loaded. (You can verify that by adding 'Log to watchdog' action as the last one and making it log something like Order [uc_order_loaded:uc_order_id] now has status [uc_order_loaded:uc_order_order_status].).

'Updates the order status' action fails silently, however. This seems to be an issue with uc_rules: #1280968: uc_order argument is undefined

More patches to come here and there.

(On a side note, I noticed some weird behavior when I had two almost identical rules attached to the 'Order attributes are updated' event - both were fired but only one was able to get tokens evaluated. Not sure if this is of any importance to the case at hand.)

Here's a new patch for this issue. In this series we:

• pass both old and new attributes to the Rules, hence we're able to compare them for changes,
• employ some magic to generate tokens for standard attributes.

And here's an example rule for the workflow described in #26.
Features:

• a condition to compare old and new color and proceed with processing the order only if the color has been changed;
• logs a watchdog message along the lines of Order 13: changed red to dirty yellow. (it's a bit hard to compose a meaningful message there because Rules wants it to be less than 256 chars before token evaluation, while actual limit is 256 after - so it comes out pretty short)

Assumes the patch in #29 and the patch in #1280968: uc_order argument is undefined.

Any leads for the same on Drupal 8?