Posted by halloffame on December 5, 2012 at 8:39pm
3 followers
| Project: | Ubercart Order Attributes |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Is there any way we could change order status when an attribute change occurs?
This module is aim for the end-user/customer thus they are not allowed to modify order details i.e status. So a way to automatically set an order to a particular status once an attribute has been changed?
Comments
#1
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.
#2
So as not to create another thread lets set this to feature request instead. If its alright with you.
#3
I've played around uc_rules (like hacking core) and I can't seem to add my own handler for this particular event. I managed to add an event to the edit-order-form-submit but it does not contain the uc_rules action that I need. I'm trying to fire the action (change order status) on submit of the order edit form, that would serve my purpose. Obviously, its a hackish way and I'm only in dire need that's why I'm resorting to this.
Officially adding this feature to the module will lean towards the proper and robust way. I can't complain about that and would be very grateful.
#4
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.
#5
Thank you so much for this head start. My skills are very limited but am willing to do some more digging and research. Will surely take the attribute edit form route. Thanks.
#6
Best of luck! If you end up with some working code, please feel free to post it here in the form of a patch.
#7
It's been days and I can't still figure out what arguments to pass. :(
#8
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.
#9
Can you do this for a bounty?
#10
Sure. Please contact me via my contact form to discuss further: http://drupal.org/user/581414/contact
#11
Patch attached.
(just a first shot at it, might require further improvements)
Note:
uc_order_attributesactually 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.#12
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.
#13
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); anduc_ruleshas an action to load an order by ID.An updated patch coming.
#14
Patch attached.
In this series, we generate our own tokens regardless of whether
uc_rulesis around or not.#15
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
#16
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.
#17
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.
#18
Thanks for looking into this guys...
Applied the patch but there is no corresponding 'update order status' action when adding the 'order attributes are updated' event.
Update: Totally forgot to load
[uc_order_product:uc_line_item_id]as per your first instruction but the action 'Load product node by order line item' is not available to choose as action. The only uc_rules action available is 'load ubercart order by id'. Is[uc_order_product:uc_line_item_id]a token which can be used for the 'load ubercart order by id' action? I tried adding this action and entered the[uc_order_product:uc_line_item_idtoken then other actions are now available including 'update order status'. I added the update status action but when I tested it out it doesn't seem to change the order status at all.Update 2: On the 'load ubercart order by id' action I added the
[uc_order_product:uc_order_product_order_id]token to pass the order_id but the action still doesn't fire on attributes change.I take it there is a usability settings that I'm missing here? I don't completely understand how the action (update order status) works here.
#19
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 :)
#20
I would like to point out though that I applied the patch manually. Could it be that I didn't applied the patch properly? The patch gave me a hunk failed which only make sense because your patch for the .module file pertains to line 510 and 710 where the file only has up to 400+ lines.
Would you be so kind to take a look at the patched .module file? If I applied it properly.
File attached: Lines 362 - 365. Line 501. Line 504 - 550. These are the lines where I applied the patch for the .module file.
Moreover, was my update 2 the right way to go at it? i.e Load order by id and pass the order_id by using the
[uc_order_product:uc_order_product_order_id]token? I can then trigger the update status action right?#21
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.
#22
Tried using the dev version, applied the patch, added the uc_rules event and corresponding actions but it looks like the action still does not trigger on attributes change.
I'm on local dev but I think I will be able to whip out a small test environment for you. Do you need ftp access as well?
#23
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 :)
#24
Actually yes there are a ton of sensitive information that needs to be stripped off (specially our super secret massively world domination plan) as the site is already over 90% done. Will take me a couple of light-years to be able to do that and would rather setup a new environment.
#25
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)
#26
Just as simple as when the attributes gets modified, change the status of the order. Specific use case is that a colour attribute with options (green, blue, yellow) gets modified from yellow to green so the idea is to set the order status back to 'Processing' from 'Completed'. It only makes sense though because in a store customers might change their mind after placing the order. Before the item gets shipped they can contact the site and ask for a colour change. When this happens the order reverts back to 'processing' automatically for the approval of the actual store admin or say the processing department.
#27
Here is my exported rule conf:
array ('rules' =>
array (
'rules_change_order_status_to_processing_when_attributes_has_been_changed' =>
array (
'#type' => 'rule',
'#set' => 'event_uc_order_attributes_update',
'#label' => 'Change order status to processing when attributes has been changed',
'#active' => 1,
'#weight' => '0',
'#categories' =>
array (
),
'#status' => 'custom',
'#conditions' =>
array (
),
'#actions' =>
array (
0 =>
array (
'#type' => 'action',
'#settings' =>
array (
'uc_order_id' => '[uc_order_product:uc_order_product_order_id]',
'#argument map' =>
array (
'uc_order_loaded' => 'uc_order_loaded',
),
'#eval input' =>
array (
'token_rules_input_evaluator' =>
array (
'uc_order_id' =>
array (
0 => 'uc_order_product',
1 => ':global',
),
),
),
),
'#name' => 'uc_rules_load_order_by_id',
'#info' =>
array (
'label' => 'Load Ubercart Order by id',
'module' => 'Ubercart Rules',
'arguments' =>
array (
),
'eval input' =>
array (
0 => 'uc_order_id',
),
'new variables' =>
array (
'uc_order_loaded' =>
array (
'type' => 'uc_order',
'label' => 'Loaded Ubercart Order',
),
),
),
'#weight' => 1,
),
1 =>
array (
'#weight' => 2,
'#info' =>
array (
'label' => 'Updates the order status',
'module' => 'Ubercart Rules',
'arguments' =>
array (
'uc_order' =>
array (
'type' => 'uc_order',
'label' => 'Order',
),
),
'eval input' =>
array (
0 => 'comment',
),
),
'#name' => 'uc_rules_order_update_status',
'#settings' =>
array (
'order_status' => 'processing',
'comment' => NULL,
),
'#type' => 'action',
),
),
'#version' => 6003,
),
),
)
#28
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.)
#29
Here's a new patch for this issue. In this series we:
#30
And here's an example rule for the workflow described in #26.
Features:
Assumes the patch in #29 and the patch in #1280968: uc_order argument is undefined.
#31
Just got back from New Year holiday, sorry for the late reply.
It's finally working on my initial test. Everything seems behaving as it should. Will test further and report any problem.
What's the plan for this patch now?
@Drave Robber Check PM/email (or whatever its called here in Drupal forum.)