Usually registered user has been already given their address information at default Drupal user-module's "Personal Information" tab. So I would like to suggest the following process flow;

On clicking [checkout] button, then go to a screen like below;

"Choose your prefered address or add new address."
 (*) Address of Drupal user-module's "Personal Information" tab (default option)
 (  ) #1 of ecommerce's address, if available
 (  ) #2 of ecommerce's address, if available
 (  ) #3 of ecommerce's address, if available
 (  ) #4 of ecommerce's address, if available
 (  ) Add new address

 [submit] button

if selected default option or other ecommerce's address, go to payment process.
but if selected "Add new address" option, go to ecommerce's add new address, then go to payment process.

Comments

matt westgate’s picture

matt westgate commented
Component: cart.module » address.module

I'd like to see the addressbook removed all together and just use profile module, but that's not going to happen unless someone has a lot of time on their hands.

Because admins can setup profile fields with any variable name they choose, it makes it quite difficult for say addressbook to know what profile's definition of a 'city' for the 'shipping address' is, and so on.

If anybody has any ideas how this can be easily accomplished, lets hear 'em.

judah’s picture

judah commented

Very well point mathias.

I suggest you have the address setting page pull the profile fields down into a table. On the left table column you have the profile field and on the right table column a dropdown list of the address fields (city, state, country, etc) that the address module needs. Then the admin can go down the list and correlate the profile fields to the address fields. If you wanted to get fancy you could remove the item from the other select lists once it has been selected but this is really not necessary. If you wanted to do this though you could setup all select lists to pull from one array and after an item is selected remove it from the array refresh the other select lists to reflect the change.

But you might want to keep the address module because some users might not want to have their shipping or billing addresses made public and using the profile module would expose that when a user views a profile.

moshe weitzman’s picture

moshe weitzman commented

Perhaps the most straightforward option is top patch the core db schema so that we we include either:

- all the fields required for address tracking
- none of the fields required for address tracking. if none, then include a script which adds the required set to the DB using ec_city as a name (for example). that way you get no field name conflicts and you know the names of any field that you care about.

sime’s picture

sime
any/any
Location Melbourne
commented
Component: address.module » address
Status: Active » Closed (fixed)

housekeeping
please re-open if this is still required

ñull’s picture

ñull commented

In this discussion nobody talks about the multiple address facility (several billing and shipping addresses). In practice may be not used much, but it is offering good service to the client. When you move to a solution using profiles, this function would become limited to the number of addresses that the administrator allows. Can we live with that?

The other point on privacy, I see the following privacy setting available:
Visibility:
Hidden profile field, only accessible by administrators, modules and themes.
Private field, content only available to privileged users.
Public field, content shown on profile page but not used on member list pages.
Public field, content shown on profile page and on member list pages.

The Private field seems sufficient for our purpose.