Closed (won't fix)
Project:
Commerce Core
Version:
7.x-1.x-dev
Component:
Payment
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Sep 2010 at 17:09 UTC
Updated:
3 Apr 2013 at 21:17 UTC
Because we're storing payment method settings in the action used to enable the payment method, we need to always match the payment method of the order with the specific action used to enable it. For example, two different PayPal accounts might be used, and we wouldn't want to send the payment to the wrong one. : )
Comments
Comment #1
rszrama commentedI ran into the blocking issue in that Actions during Rule evaluation had different element IDs than the same Actions on a Rule configuration freshly loaded from the database. This means when I created a key based on the element ID in the payment checkout pane, that same element ID wouldn't be recognizable later in checkout when I wanted to load the settings from the Action.
Right now I've stripped the element ID out of the key and will have to enforce the requirement of each payment method enabling Rule configuration only being allowed to enable a single instance of a given payment method. I'll see if fago can follow-up to let me know if this is expected behavior with element IDs and if there's a better way to identify a specific Action within a given Rule configuration.
The code thus far is available here:
http://github.com/rszrama/drupalcommerce/commit/8a88d0d6d0881715499ac556...
Comment #2
fagoHm, they were completely different some (~2) months ago, but as of now they should be static. Perhaps make sure you use a recent Rules version?
However.. if rules are kept in code, nothing saves the ids, but still the algorithm should number it the same way.
Anyway, I'd not recommend referring back to the action settings. Either pass the action settings directly to the order and save it there or introduce a separate way of editing and saving payment method settings. I'd not expect existing orders to fail when I delete the rule that changed them and e.g. create another rule instead.
Comment #3
fagoops, that's your queue :D
Comment #4
rszrama commentedAhh, ok, a little more context. The Rules themselves are being defined in code, one for each payment method. However, the actions are being saved when I edit to enter settings for the action. Additionally, it's not working for cloned rule configurations which I'd expect would be fully loaded from the database. I'm also using Rules CVS HEAD, so maybe I can create a test or something that demonstrates the issue without requiring you to debug Drupal Commerce. ; )
Also, after thinking about it further, I think the business rule of only permitting a single instance of a payment method to be enabled by any given Rule makes fine sense. But I'll still see if we can debug this further.
Comment #5
rszrama commentedThis just needs to be revisited to see if it's a quick fix now based on fago's comments above. If not, just postpone the issue instead of pushing for a solution, as what we have now is good for most use cases, and everyone else can just use two separate Rules to enable multiple payment methods. ; )
Comment #6
fagook, in the meantime some things changed:
* The rule in code will be saved to the db once the module is installed.
* The IDs of elements are now serialized too, that means they'll stay for the whole life-cycle of a rule.
Together, both changes should make the element IDs persistent. They might only change when a rule is reverted, though again the algorithm should number the elements the same way as before as long as the default rule stays the same.
FYI: You can/should use $action->elementId() to get the id.
Comment #7
rszrama commentedAwesome, fago. Thanks for the info... should be a much simpler patch then. : )
Moving to "needs work" so we know to go forward with the change.
Comment #8
rszrama commentedfwiw, I couldn't get this to work - in my one attempt, it still appears there's some discrepancy in the IDs that I don't really have time to track down. The gist of it is I had a single payment method enabled and its action's ID was 4. I installed another payment module and added an action to that rule whose ID appears to be 5 when the action to enable it is executed but is later 4.
I don't have time to track this down, and since we do have a working solution, I'm just going to postpone this on our end.
Comment #9
rszrama commentedI don't see this as important to fix in 1.x at this point. The 1 payment method per rule hasn't been a hindrance thus far, and in 2.x we'll be moving payment method configuration out of Rules actions anyways. Closing this out.