1

Heres the thing. We have a customer profile of type 'Delivery' which contains a delivery address for an order. It also has other non-addressfield data like driver route, delivery day (M-F, day of week), default product (recurring order kit), and delivery frequency (how often to receive new orders).

The customer can, at any time, change their delivery frequency, default product, and delivery address. Here is the issue... any slight change and/or order reference and the profile is cloned. I get that Drupal Commerce does this to preserve historical order data integrity, however, the new profile ID needs to be assigned to all non-completed orders. We can't store this as a Profile2 object, because changing address or product affects their available delivery day and driver route, which has to go along with the order.

Orders are generated by the system based on this profile data... so it is important to maintain order reference and the 'newest' profile of record that is the basis for new orders and any editing. Profile data cannot be edited at the order level itself.

I am having a lot of difficulty wrapping my head around how to wrangle profiles to either prevent dozens of clones or making it make sense to administrators (Views reports will show tons of user profiles).

What is the most sensible way to manage this? Currently I have set up a Rule that when a customer profile is created or updated, the profile ID is proliferated through orders... but not sure this is the best approach.

  • 1
    "Dozens of clones" is how it's supposed to work. Not good, I grant you, but definitely "works as designed" – Clive Oct 29 '14 at 12:10
  • I guess that is okay, but how can I ensure that the freshest copy is assigned to any un-delivered order? – Kevin Oct 29 '14 at 12:16
  • I just realized I asked the same thing a year ago... same project. Architecture is slightly different now though. – Kevin Oct 29 '14 at 13:23
  • I'm not saying it's off topic here, but wouldn't you have a better chance to get your answer at drupalcommerce.org/questions ? I mean, a year? And no satisfying answer in old architecture? Seems like a long time and maybe people who knows simply aren't here? – Mołot Oct 29 '14 at 13:29
0

I'm not really sure what the best solution is. I'm also not particularly fond of the code I wrote to prevent customer profile changes from harming the data integrity of historical orders. Those two caveats aside, maybe the following options can help:

  1. You could patch commerce_order.module to add specific exemptions for your fields in the function commerce_order_commerce_customer_profile_presave(). You'd basically add a whitelist to the top of the foreach() loop there over field instances and if you see one that shouldn't be taken into consideration for profile copying, use a continue statement. Note that this approach means any changes to these fields would "appear" on previous orders that were placed with alternate values for these fields - if that doesn't matter to you, then this should be safe and fine.
  2. You could look into Commerce Single Address. I'm not sure it's what you want, but it may offer some insight. You may need to add code to it to handle updating those previous references that were giving you an issue.

Ultimately we need to get a reasonable API around this so there are hooks and alternate options for the copy behavior. If you decide to patch commerce_order.module, make sure you maintain that patch in your codebase and have a process in place to re-apply it whenever you update Drupal Commerce.

  • I wound up (for now) having a Rule when a profile is created or saved, to query for all pending level orders, and updating the profile reference ID on those orders to what Drupal Commerce returns after the save has occurred. Not exactly bulletproof, but facilitates the carrying of new data to a degree. The problem is it being so volatile, there are many avenues for change triggered by both an admin or customer. I think I can work with this, as long as there are no save conflicts inside of Rules. – Kevin Nov 3 '14 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.