Change commerce_addressbook in to a field widget.

Some interesting thoughts... Perhaps instead of a field widget, it could be separate pane on the checkout form, that updates the customer profile pane(s) via the #ajax property of the select formAPI item?
This would limit its usage to the end user though, and not show up in administration pages, which might be the desired option in most use cases, but perhaps there are use cases where that would cause trouble...

With regards to creating a new customer profile vs update an existing, there is also an issue about it: #1193802: Don't store unchanged customer profiles as new entry.
I'm thinking we should store a unique combination of entered data as a new customer profile, while a customer profile with values that are 100% similar to an earlier submitted one, could just link to the earlier ID instead of adding a new one. I suppose this could be achieved with hashing the values, but don't know if that'll work in practice :)

Sven

I have plans to go a different route as soon as I get this version up and running at least for the moment. I think I am just going to create a new entity for the addressbook and make it non commerce specific. The goal would be to be able to add the addresses in the user pages and have a checkbox that will allow you to save an address to your addressbook on checkout. This is just a thought at the moment, but in the mean time I plan on getting the current version working at least for the checkout only. The hash issue is something I took care of yesterday by changing the md5 contents to use the full address array in lowercase.

At this point if you want to make a widget version go ahead and make a new branch (or I can make one for you) and that way, like Sven mentioned in another post, we can merge it in later.

Freixas and I are working on a new version of Ubercart Addresses which will get a rich API for addresses. If possible, we want to make the module to be compatible with Drupal Commerce too. The experimental code we currently have (not public available yet) is only compatible with Ubercart.
I wonder if we can work together as we are trying to accomplish the same thing?

Sounds like a good idea to put our heads together to make sure we aren't duplicating work and what not. Let me know how you want to proceed.

@megensel
It's a long story to tell what our plans for Ubercart Addresses are, but shortly:
- The module will first be rewritten for Drupal 6 and then be ported to Drupal 7. See also #1104854: Any foreseen porting to Ubercart for Drupal 7 ?.
- A part of the module will be object orientated, there will be an address book class and an address class.
- For each user there will be one default shipping address and one default billing address
- There will be a template for a single address and a template for the complete list of addresses for a single user (the address book)
- There will be permissions for viewing addresses, editing addresses and deleting addresses. See #1194232: Permissions ignored for detailed list.
- Some changes to addresses should go via the address book. For each user, the address book class controls that there will only be one default shipping address and one default billing address. It also will ensure that (nick)names of addresses are unique per user.
- We looking for a way to let other modules add additional address fields. Freixas thought about a system with field handlers. These handlers could be defined as 'plugins' and the system could be implemented with the help of the Ctools module (my idea). The module Extra Fields Pane should take care for implementing the extra address fields. With Extra Fields Pane you can currently already add extra address fields (for Ubercart), but it's not fully integrated with Ubercart Addresses yet (that's why the rewrite for Ubercart Addresses was planned)

The reason why extra address fields are important? In Europe, some addres data needs to be more refined. In the Netherlands the name can exist out of 3 parts instead of two. Beside first name and surname we have also a surname prefix, in the Netherlands called 'Tussenvoegsel':
http://en.wikipedia.org/wiki/Tussenvoegsel
Other things that some shops want to be more refined: separate the house number from the street, a title field for people with a particular study level (Dr. (Doctor) for example), a gender field.

I can mail you a link to the experimental code if you want. The code is currently for Drupal 6 only. The reason why the code is not on Drupal yet is because it's not yet operational and because the API is not definitive.

because it's not yet operational

I should have said "not fully operational". Except for the address edit form, the "core" features of the address book are already functional (but may need to be refined some more).

@svendecabouter: Appreciate your contribs a lot. Awaiting for following step in this approach: posted in drupalcommerce.org a long time ago about this issue. Greetings!

Thank you very much for providing a much needed contrib for commerce.

Subscribing

Eagerly subscribing.

+1

subscribe

I'm having a hard time seeing how calling this will allow us to implement these features:

/**
 * Implements hook_field_widget_WIDGET_TYPE_form_alter().
 */
function commerce_addressbook_field_widget_addressfield_standard_form_alter(&$element, &$form_state, $context) {
  // Do some stuff here.
}

You do not have access to the $form, so adding the saved address drop down and js is not possible. If you made this into a widget, how do you use the above hook to add that widget to the addressfield? I'd love to see any code you have using a widget like this. I'll try and help finish it I can figure it out.

I think the original issues raised in the first post can be addressed through some simple changes to the existing code.

1. If you load any entity for which an addressfield is added, you'll get the "Saved Address" drop down. This includes editing customer profiles in the admin.
2. There's another issue related to it only showing the currently logged in users addresses, instead of the user for which you are editing.
3. Additionally the Javascript populate doesn't work in any case except for the checkout case.

Proposed changes:

1. I don't think this loading for all addressfields is a bad thing if #2 is fixed. The commerce_addressbook_field_attach_form() function needs some additional checks before it calls commerce_addressbook_get_fields($form) and commerce_addressbook_list_field($form, $profiles);
2. The commerce_addressbook_get_fields() function should find out the intended user from the path, and not from global $user and pass that into commerce_addressbook_get_customer_profiles_by_type(). Hopefully securely and with some permission restrictions so only admins can get a different user's profile info.
3. The javescript can be fix. I already have it working for custom fields #1280248: Add support to handle custom fields

I'm getting close on a working solution for this.

It's not done yet, but should be next week. You can see the progress so far in the attached patch. I still need to fix the javascript so it works on non-checkout forms. I also need to change the flow of how the functions are called to attach this to forms in a more straight forward way.

Nice work bendiy!
I'm started a new branch "field_widget", that incorporates your patch.
I've been building further upon it, in the hopes to get the module working with the Drupal #ajax callbacks instead of custom javascript.
I'm also focussing on following the workflow as laid out by Ryan at http://drupal.org/node/1193802#comment-4724358

Hopefully my changes don't interfere too much with the plans you have, and I hope we can join forces to move this more generic approach forward, instead of starting yet another fork.
Catch me on IRC if you want to discuss this further, or get Git commit access to help build upon the progressed code.

Thanks so much for your help!

@svendecabooter I took a look at the commits so far for the "field_widget" branch. If you can work out the details on the #ajax callbacks, go for it. I don't have much experience with that yet.

I noticed that you pulled out some of my code to get all the entities and changed it to just ' commerce_customer_profile'. What I had in place was able to also pull in a user's addressfields that were attached to the 'user' content type as well as any addressfields used by the Profile2 module. My goal is the make it possible to have the user enter Billing and Shipping addressed under the "My Account" profile and have the addressbook module pull those in on checkout or even use the addressbook module to populate the addressfields in their profile.

@TODO: do we really need to get all entities, or can be have hardcoded default to commerce_customer_profile?

I haven't tried your changes yet, but that is the direction I was going. Make addressbook generic enough to work on all addressfields no matter where they are used. I was also considering adding a form field to the widgets settings that would restrict it to specific entity types. For example, when you add the saved addresses widget to the checkout form, you could restrict the entities it pull from to use addressfields attached to the user or profile2. This way, each time you add the widget, you can specify what it's pulling from. Ideally, you would add the widget to the checkout form for a billing address and restrict it to just the Billing profile you have created under "My Account". You then add it to the checkout for the shipping address and restrict it to use the Shipping profile under "My Account".

I'll look over your changes in more detail tomorrow.

Hi,

Thanks for your feedback.
The problem with this module seems to be that everyone has another slightly different use case, which results in a lot of attempts, but no solid release that people can actually start using. That is my focus right now.

That said, I'd also love the module to be able to cater for the use cases you described. I'd have to think about them in more detail to find out what's possible or not.
My currently committed code indeed makes some shortcuts for now and assumes customer profile entities, but the basic architecture has been created with more than customer profiles in mind. This was mainly done to get a better view of whether it was possible what I wanted to achieve.

Adding the field to other things like User entities and Profile2 entities will probably be possible. The #ajax code should also make it possible to dynamically fill in the entity fields. The main problem is see is that it might not be possible to prefill one entity type (customer profile on Commerce checkout) with values from another entity type (User entity address field). But perhaps that is functionality that should be more tightly coupled to the Addressfield module instead of the Commerce module?

Just a quick overview of functionality that is currently added to the field_widget branch:

* Ability to add a 'Saved addresses' dropdown widget to customer profile entities - code & inspiration by bendiy.
This should work with multiple customer profile types, such as billing and shipping (via http://drupal.org/project/commerce_shipping)
--> TODO: make this more generic

* Ability to prefill customer profile fields by selecting a saved profile via AJAX - code & inspiration by jsacksick & rszrama
This doesn't only fill in the address fields, but also any other custom fields that have been added to the customer profile entity.
--> TODO: prefill the first address initially on page load.

* Customer profiles that are selected from the dropdown and left unchanged, are now directly referenced by the order. This avoids lots of duplicate customer profile entities being saved when users make a lot of orders with the same (address)info.

Other big TODO: remove dependency on the currently logged in user. Use the order uid instead.

You might need to reinstall the module to get everything working.

Feedback welcome.

I thought a lot about prefilling the first address initially on page load. I initially had this working, but then removed it. I don't think it's needed. If this module evolves to be more generic and not specific to Commerce, it will be hard to figure out which address was last used for the user or profile forms.

Also, having the user start from an empty form makes the address they select or enter a deliberate choice. If you prefill the form, I think there's a greater chance that there will be an error due to the user's tendency to gloss over it since it's already filled out.

The prefilling of the latest address on checkout page load is now added as an option, which is off by default.
So people who want it, can activate it.

Marking this issue as fixed, because the initial purpose of it has been implemented.
Other todo's can be discussed in seperate issues.

I have read all comments, but could not find where is solution?
Any help?

This functionality was used in the 1.x branch of the module, but abandoned in the 2.x branch, since it turned out to be quite unusable.
So the addressbook widget is no longer a field.

How can I achieve this on the current 3.x branch? Are there any other alternatives