Ability to add fields to address model

[andris-sevcenko]

Created by: Maarten (wiejeben@gmail.com) on 2017/10/05 08:20:13 +0000 Votes at time of UserVoice import: 3

---

I would like to have the ability to add custom fields to the address model. For example last names in the Netherlands often include a middlename like mine "Maarten de Graaf" where de is sort of apart of my last name but not really.

Custom fields would also allow me to add for example a "floor" field or a hidden external ID for when the addresses have to be synced up with a CRM.

[jose-verissimo]

Any progress on this one?

[lukeholder]

Still on the list, but not a priority at the moment. Thanks.

[engram-design]

Adding a +1 here, and ideally for Addresses to be elements, so you can attach custom fields to them.

Use-case, people want to store delivery instructions on their shipping address, or 'label' a billing address ('work', 'home', etc).

A simple notes column would be fine, but if going to the effort of adding that, probably better to make addresses elements.

[sjcallender]

This just came up for us as we work on a subscriptions site. We're hoping for a way to label addresses and leave delivery notes to each.

[lenvanessen]

Any ETA on this?

[lukeholder]

We are planning to add address3, label, notes, and fullName properties to addresses.

Any that we are missing?

[engram-design]

@lukeholder No option to have custom fields for addresses? We had a client recently that wanted shipping addresses to include a bunch of stuff - like University Name (and department), Hospital Name (and Ward), Hotel Name (and Room Number), etc. Currently, we're just JSON-encoding this information into the Business Name, and doing a lot of hacks to get around it.

I suppose, maybe having a TEXT column similar to line item options might suffice for most people's needs?

[keyurshah]

address type ( business / residential)?

[lenvanessen]

Housenumber addition, although we could use address3 for that as well

[tim-van-dijkhuizen]

It would be great if you could customize the address fields the same way you can edit the order field layout. I'm working on a project that requires some unusual extra fields and I'm currently having to use some hacky Javascript to make that work. The reason I prefer a field layout editor over the ability to add more fields is because there are a bunch of fields that I do not need. I feel like it would become a huge mess if the default fields can not be removed.

There is probably some commerce logics that use address attributes for things like shipping cost calculation. This problem could be solved by having a function that gets its information from certain field types? For example a country field type of which only one can be added to the layout. When this field type is present shipping cost calculation will start working, else you can only have static shipping costs. There would be a default field layout containing the fields currently present in the Address model, both for migration purposes and to give people something to start with.

This is just an abstract idea. Feel free to add things to further improve it or share potential problems caused by this setup.

[AugustMiller]

I rather like the notion of Addresses-as-Elements, with (potentially) a discrete FieldLayout for Billing + Shipping addresses—with the changes Luke mentioned in 2.2, re: dynamic Tax + Shipping matching, these custom field values could start to be really useful.

It also partially side-steps a whole class of issues that crop up when dealing with localized/regional addresses…

Curious how this would end up jiving with the conditional fields setup that's in the pipeline?

[tim-van-dijkhuizen]

I rather like the notion of Addresses-as-Elements, with (potentially) a discrete FieldLayout for Billing + Shipping addresses—with the changes Luke mentioned in 2.2, re: dynamic Tax + Shipping matching, these custom field values could start to be really useful.

It also partially side-steps a whole class of issues that crop up when dealing with localized/regional addresses…

Curious how this would end up jiving with the conditional fields setup that's in the pipeline?

Yes, that is pretty much what I meant. But since elements might be to heavy to be used for addresses I didn't mention it. However, after looking at your arguments as to why elements would be a good fit for addresses I think I agree. Thanks! 😁

[bossanova808]

I think if moving to elements then there still needs to be a set of 'core' required fields or the logic in various places is going to spin out of control - basically the current core set plus the news ones you mention above Luke would cover the great maority of things I would have though...and Commerce's own shipping/tax stuff is going to need to rely on a minimum subset of fields being present/used or they simple won't work.

[bossanova808]

Thinking about it, I think this address data problem is quite in line with the customers issue - there is very often a need with both address and customers (commerce customers, whether users or not) - to store more data for various business logic reasons. Elements seems a natural fit as they give you all the custom field stuff & management interfaces 'for free' but the danger is too much flexibility means it all gets too complicated and hard to maintain. Still, elements do seem the most consistent approach...but some sort of psuedo element with key fields locked (for consistency and so that plugins have something minimum to target in their implementation) - but with flexible extra fields available would be ideal.

[AugustMiller]

Most all Element implementations do have some core attributes + built-in validation rules (think, authorId or sectionId on an Entry), so in this regard, what exists as attributes of the Address Model just become attributes on a new Address Element. Some would still be non-negotiable, or universally-available, like firstName, lastName, address1, etc.

I believe Elements still produce all the same low-level Yii events for modifying their validation rules, so the same methods for handling changes to the rules about the core properties would probably be pretty portable between the Model and Element implementations.

Just a bit of extra context, for anyone joining the conversation! 😉

[tim-van-dijkhuizen]

The reason I would like to see as little default properties as possible is because I'm not going to use most of them. I would not be using the following properties anymore:

• title
• lastname
• address1
• address2
• businessTaxId
• businessId
• stateName
• stateId

I would however replace a lot of these properties by multiple custom fields to keep the values seperated. That is why I think it would become a big, confusing mess if I were not able to remove those default properties.

It is going to be a breaking change anyways so we might as well do this right. Addresses should get a default field layout containing the current properties, which values should be migrated to the new custom fields. So templates should be fine, plugins may need some minor changes.

[peteeveleigh]

a big, throbbing +1 for this

[lukeholder]

Commerce 4 uses Address elements for addresses that came in Craft CMS 4, which can have their own custom fields.