Company Names in Addresses

[Jeff Seibert]

Hey all,

Is there any particular reason addresses do not support company names
in addition to first, last, address1, and address2? This makes it very
difficult to ship to some addresses.

Wanted to see if anyone has already done the work to support this
before I start hacking on it.

Thanks,

Jeff
COO - Slouch, LLC
www.slouchback.com

[Marcin Raczkowski]

You can simply add required field to DB in site extension (like I did)

[Jeff Seibert]

Yes, that's not a problem - just wondering if there is any opposition
to me putting together a patch for core? I'm not suite sure why this
would not be supported by default.

Thanks,

Jeff

[Sean Schofield]

This might be useful. I'd make it a configuration setting so that you
could make display of the company name optional in the checkout form
for those that don't want it. What do others think?

Sean

[Eliot Sykes]

Would adding an address line 3 make sense? We could show it by default
and avoid the configuration setting perhaps, plus its a bit more
general than Company name which may or may not be a good thing.

Companies could then use address line 1 as the company name field,
perhaps.

Just an idea, not sure if its a good one though.

Eliot

[Jeff Seibert]

My concern here is that adding an address3 field leads to ambiguous
use of the address1 field, as you mentioned. This makes it difficult
to pass the correct fields to an address verification API because you
cannot infer the intent of the address1 field.

A company field is pretty standard as I look across websites.

Jeff

[John Orr]

I also agree that a company field is standard stuff and we use this method on our other platform.

John

[Eliot Sykes]

Great, company name sounds much better than Address line 3. +1

[Paul Callaghan]

A similar thing (optional field) is done for alternative phone numbers
in addresses, and it hasn't caused any problems.

Paul

[Sean Schofield]

I'm hearing enough +1 that I think someone should ticket and fix. See
the new contribution guidelines[1] as well.

Sean

[1] http://spreecommerce.com/documentation/contributing_to_spree.html

[Rob Kuhr]

Why not just call it address3 but you can have your presentation dictate if you want to show it/allow it and label it according to your site's needs.  This way it is very generic and can be flexible enough to be in core.

--
\m/^.^\m/
"Some scientists claim that hydrogen,
because it is so plentiful, is the basic building block of the universe.
I dispute that.
I say that there is more stupidity than hydrogen,
and that is the basic building block of the universe."
-Frank Zappa
http://www.tunagami.com

[scootercab]

As long as its shown at the very top of the address fields, as the
company name comes first followed by address details.

John

[Rob Kuhr]

You could always re-label your views to have address1 be the company name, address2 & 3 to be the regular address information.

We are doing something similar for our implementation of spree at the moment.

[Eliot Sykes]

Are there any requirements from credit card processors we need to
consider about company names being set to a specific field rather than
the generic "address line 1/2/3"?

[Sean Schofield]

I tend to agree with the more generic approach of address3. Then it
doesn't matter how you use them in your views. We could even use the
localization to help customize.

So t("address_one") could be Company in your site extension, etc.
This also becomes easier with the templating improvements we are
contemplating.

Sean

[Sean Schofield]

We could still use address1 and address2 for credit cards (as we do
now.) Its just that address3 might appear "first" in the form when
filling out (if I understand Rob correctly.)

Sean

[Rob Kuhr]

Like I said, that is up to you and your business needs on how you want to use address3/1/2/400.  I am just suggesting it be kept a generic name and not company name and then allow business to dictate how you want to display that.

that said, company_name as an attribute for an address is not going to cause a black-hole/time-paradox in spree-core either ;-)

[Eliot Sykes]

If address3 appears first address0 might be a better name.

[Marcin Raczkowski]

IMHO, address1 and address2 are bad enough, adding address3 (in front of
address1 and address2 nevertheless) wold only confuse everyone.
I vote for company_address + option to disable it.

[Peter Berkenbosch]

I totally agree.. +1 for company_address

----

Peter Berkenbosch

peterber...@me.com

peterberkenbosch.wordpress.com

What's not possible has never happend

[Carl Anderson]

I'd support a more specific name as well. Address 3 (or 0) is pretty non-descriptive of what it is meant to be, and it seems like it would make templates less obvious to me.

Carl

[Jeff Seibert]

I am in agreement here, though the field should be called "company" or "company_name" or "firm" or "business" because it is the name of the organization, not the address.

Jeff

[Stephanie Powell]

Hi,

It seems like there is a lot of talk over adding this one field to the
spree core. Has anyone thought of adding generic meta data fields to the
addresses that are not required (for example: metadata1, metadata2,
metadata3). I realize this isn't always the best data model to extend an
object with generic fields, but it seems likely that in most situations
no more than several custom fields would be required and this eliminates
the argument over what to call each extended field or what to include in
the core. This might be a situation where you are sacrificing the data
model a bit for improved flexibility to many developers.

After adding three metadata fields, a developer would be required to:
1) update the locale file for display of that field (company, firm,
business, address3, cow, moose, etc etc)
2) add validation for the field in an extension (validate_presence_of
metadata1) if necessary
3) update the frontend and admin address views to show this new field

All of these things would be required for any developer that wants to
extend the address currently. With the checkout javascript validation
method, a simple class="required" could be added to the input so that
the element would be validated. I could see some situations requiring
more modification of the checkout javascript, but I've had luck with
using a separate javascript that binds / unbinds onclick events and adds
additional listeners to avoid messing with the core checkout javascript.

IMO, it's not that hairy to extend the checkout model in the first
place. You'll have to do the steps mentioned above plus add a migration
file. Maybe there are other mysterious things that would be required
that I can't think of right now, but perhaps offering this kind of
metadata flexibility would appeal to many business cases and would
eliminate the need for us to discuss what to call the field.

~Steph

Jeff Seibert wrote:
> I am in agreement here, though the field should be called "company" or
> "company_name" or "firm" or "business" because it is the name of the
> organization, not the address.
>
> Jeff
>
> On Aug 18, 2009, at 1:40 PM, Peter Berkenbosch wrote:
>
>> On Aug 18, 2009, at 7:30 PM, Marcin Raczkowski wrote:
>>
>>>
>>> IMHO, address1 and address2 are bad enough, adding address3 (in
>>> front of
>>> address1 and address2 nevertheless) wold only confuse everyone.
>>> I vote for company_address + option to disable it.
>>
>> I totally agree.. +1 for company_address
>> ----
>> Peter Berkenbosch

>> peterber...@me.com <mailto:peterber...@me.com>

[Sean Schofield]

Well "organization" is even a more generic term.

Sean

[qwan]

The approach I have taken is to add AddressType table with a code and
a description, and Address belongs_to :address_type

Enables a User (actually I added a Customer class to keep from
cluttering up User too much) via join table (CustomerAddress) to
store many different addresses, simply assigned as Shipping, Billing,
PrimaryContact etc, which can be picked at checkout

Perhaps that could be extended to actually making Address itself
polymorphic and for the different address types to have different
features/fields based on the Type of address ... would perhaps be a
good place to hang Stephanie's meta data idea ?

or maybe thats serious over kill for one field in a migration ? :-)

Cheers
tom

[Sean Schofield]

Sounds like we're getting overly complicated here. Keep in mind that
if you really needed to change it, you could so with an extension
containing a simple migration and view alteration.

I think we just call it organization_name and move on. You can always
treat it as something other then organization and you have the option
to rename it or exclude it from your views (and to change the order in
which it appears.) I also tend to agree with people who say address3
is a little confusing, at least this is clear what the intent is.

Sean

[Ted]

Hi Jeff,

Did you ever put such a modification for adding a company_name field into Spree?  It's obviously not in the 0.60.3 release, which is what I'm running, but if it made it anywhere else in the code I can probably port it into my fork of the release.

Otherwise I'm too much of a beginner to know how to start coding it myself.

[Ryan Bigg]

We could look at adding this to the next release if there's enough demand for it. And if there was a patch that added it well, then I guess we'd have to add it :)

--
You received this message because you are subscribed to the Google Groups "Spree" group.
To view this discussion on the web visit https://groups.google.com/d/msg/spree-user/-/03i3uSEok0MJ.
To post to this group, send email to spree...@googlegroups.com.
To unsubscribe from this group, send email to spree-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spree-user?hl=en.