Hello,

I've made major revisions to the uc_addresses module started by Ben
and Rich. My goal is to submit it to drupal.org/ubercart.org as a new
module. Before I go that route, I wanted to make sure I was not
stepping on anyone's toes, particularly the developers who came before
me.

I want to repeat that this is a major revision. I've touched
just about every line of code. Even the database is not the same:
if you have installed a previous version of uc_addresses, you must
uninstall it before installing my version. I'm attaching a few
screenshots to this post to make it easier to evaluate the module
without installing it.

I appreciate the work that Ben and Rich put into this. I could have
started from the uc_orders module, but they made it really easy to
create the features I wanted. It would have taken a lot longer without
their work.

I realize that while I fixed a number of bugs, I probably also put
some in. The code runs pretty well for me, but I'm sure that as soon
as someone else touches it, it will break. Please e-mail me with bug
reports.

I've attached the module package along with some screenshots. If I
don't hear of any major objections or problems within a week, I'll
begin the process of getting it up to submission quality.

What follows are the gory details...

The Short Story

Ubercart

Ubercart stores addresses with orders. The drawbacks to this are:

• Without an order, the store owner has no contact information for a
  user.
• The user has no control over this list.

The "original" uc_addresses

The Ben/Rich version of uc_addresses overcomes a lot of this, but I
felt it still had some problems:

• Each address was given a name, but the name was not used for
  selection when placing an order.
• Addresses from the user's list were combined with addresses from
  the orders, so that the user still didn't have complete control over
  the list.

The uc_addresses module was adapted from uc_orders and some
questionable operations were carried along, such as the "review"
feature. It's important to review an order, but not an address (you
can always edit or delete it).

I ran into (and fixed) a number of bugs. Unfortunately, I don't have
the fixes independent of the new code. Sorry.

My new uc_addresses

My version of uc_addresses let's the user add addresses to his profile
without requiring a name. One address is called the "default" address
and should be the main contact address/phone for a user. This address
can be edited, but not deleted.

When users register for an account, their first address automatically
becomes the default address. This is also true if you add this module
to a system with existing customers. Once the first address is
entered, it becomes the default address.

The system ensures that all addresses are unique.

The order addresses are never used for selection when placing an
order--all addresses come from the user's address book. Admittedly,
this is a major philosophical change. However, every address used for
billing or shipping is automatically saved to the user's address book.
The convenience is the same, but the user can now edit and delete old
addresses.

The order selection box has been changed to display the full address,
not just the street 1 field. You'll need to be careful to theme the
box size to prevent a long address from creating a huge selection box.

The order system and its address features are otherwise unaltered by
these changes. Addresses are still placed into orders and can be
viewed and modified by the administrator. In the future, perhaps these
two systems can be combined in some reasonable way, but that's beyond
my immediate goals.

The Long Story

Here's a detailed list of differences between the old and new
uc_addresses module:

uc_addresses.info

• uc_addresses.info - Changed the description.

uc_addresses.install

• The database structure is different.
• Fixed an error in the pgsql: It tried to create a uc_orders table
  instead of uc_addresses.

uc_addresses_address_pane.inc

• Eliminated the address label.
• Eliminated the "review" step.
• Moved the phone number to the bottom of the address fields.
• Removed some variables that were assigned but never used.
• Added an option to convert any address into the "default"
  address.

uc_addresses.module

• Added a lot of documentation (so I could figure out what
  was happening).
• Tossed out the old permissions and came up with new ones. The user
  can always view and modify his own addresses. For others, you can
  enable: view all users' default addresses, view all users' addresses,
  and add/edit all users' addresses.
• Eliminated the unused Address Admin Settings page.
• Addresses now show up in a tab in the user's account page. This
  has two sub-tabs: View addresses and Add a new address.
• When the user views his own profile, the page now has a message
  saying "Click here to manage your addresses." similar to the what is
  done for Orders.
• Various fixes for the proper use of t().
• More extensive alterations of the checkout page address
  forms.
• Address from checkout get automatically added to the user's
  address book.
• Added a small memory cache so that's it fast to repeatedly query
  the same address record.
• Suppress the Delete button for the default address.
• Revisions to the database methods to check for errors and to
  handle the new database structure.
• And a lot of other little changes...

Tony Freixas
tony@tigerheron.com
http://www.tigerheron.com