Question regarding upgrade from 0.8.4 to 1.0

[torkiljohnsen]

With the release of 1.0 I started looking at upgrading from 0.8.4. Ran into some issues and have some questions too:

1. Given/family name shouldn't be required

Given name and family name are always required now it seems, yet in Norway it is perfectly legal to send something to an organization and use for example this address format:

Organization
Street name
Postalcode LOCALITY

For instance:

Acme Inc.
Storgata 1
1234 OSLO

There is no need to specify a person; you can very well address a shipment to an organization. So you have to specify a recipient, but you are free to use organization name for that purpose too.

Is it possible to adjust the address contraint/validation to require either organization OR given/family name?

2. Address line 1 shouldn't be required

Some addresses in Norway don't require an address line 1 (see https://www.posten.no/sende/klargjoring/adressering). This is for instance a valid format:

Given name Family name
Postalcode LOCALITY

I guess this is a minor issue that can be easily fixed in the AddressFormatRepository class, or is requiring address line 1 also intentional?

3. Got an error when trying to use additional name

Seems like the additional name field is not in use by the address formatter, which is probably why I get an error saying the field should be blank when I try to use it in an address. Sorry for not providing code to reproduce this, I'm just wondering if this is expected behavior?

Example NO format:
%givenName %familyName\n%organization\n%addressLine1\n%addressLine2\n%postalCode %locality

[bojanz]

We are still following Google's Address Data service, as used by Android and Chrome.
The relevant definition for Norway is here:
https://www.gstatic.com/chrome/autofill/libaddressinput/chromium-i18n/ssl-address/data/NO

As you can see, it specifies that both the recipient (split into individual first_name/last_name fields in this library) and the addressLine1 are required. You can open an issue in their repo to argue for changing this: https://github.com/googlei18n/libaddressinput/issues

In the meantime, you can extend AddressFormatRepository and modify the address format in processDefinition(), make the rules to your liking.

And you are correct in noticing that right now no address format uses %additionalName. We've added this field, but Google's not giving us information on where to use it, so we've left it to implementors to decide by themselves, for their own countries. We'll be revisiting this in future releases.

[torkiljohnsen]

I looked at https://www.gstatic.com/chrome/autofill/libaddressinput/chromium-i18n/ssl-address/data/NO. The format is not familiar to me, but it says:

{  
   "locality_name_type":"post_town",
   "name":"NORWAY",
   "require":"ACZ",
   "key":"NO",
   "zipex":"0025,0107,6631",
   "zip":"\\d{4}",
   "id":"data/NO",
   "posturl":"http://adressesok.posten.no/nb/postal_codes/search",
   "fmt":"%N%n%O%n%A%n%Z %C"
}

According to the docs, ACZ means
A – Street Address Line(s)
C – City or Locality
Z – Zip or postal code

Where does it say that it requires recipient?

From the format (fmt) string, I can see both N-Name and O-Organization, but none of them are listed in required?

[torkiljohnsen]

… and I opened an issue as you suggested @bojanz, maybe because I like to argue, and perhaps also because I live in a sparsely populated area of Norway where not having a street address is not at all uncommon 🙂 google/libaddressinput#163

Sorry for making a fuzz here, but upgrading to your version 1.0 have made very common Norwegian organization addresses invalid, like the one I showed above. Previously I "fixed" it with just mapping the organization name to the recipient field, but with the split into given name/family name, that is no longer possible.

[bojanz]

Thanks! Always good to get feedback from people actually using the formats. We'll see what Google says.

Keep in mind that you still have full control over all the fields, just override the address format definition.

You are right, the recipient is not required in the source data, I misread the definition when I was linking it to you. Looks like requiring firstName/lastName is a port of the v0.8.4 code: https://github.com/commerceguys/addressing/blob/v0.8.4/scripts/generate.php#L286
So it's worth investigating why the library requires the names and the source data doesn't, but it's not a change from the previous branch.

[torkiljohnsen]

True, but earlier I could just map Organization to Recipient to make things work, since Recipient was required. Mapping Organization to Given Name + Family Name is harder. In a way, organization is also the same as recipient, so I was okay with that, but organization is not the same as given/family name, so now I halted 😊

So I would argue that requiring recipient to be present in v0.8.4 was wrong too, as a Norwegian address could very well just consist of organization, postal code and locality.

I guess I have to start with overriding the address format definition then…

[bojanz]

You make a valid point. I'll leave this issue open and look into whether we can make the name fields optional.

[torkiljohnsen]

I added two extra properties to an extended AddressFormat called requireWithout and requiredWith, so I can make given_name required with family_name, and organization required without given_name and family_name and vice versa, thus ensuring a recipient of some sort has been specified. Then I added validation checks for requiredWith/-without to an extended AddressFormatConstraintValidator. Also overloaded the Norwegian format so that name and street address is no longer required.

So now I can require either organization or family/given name for Norwegian addresses, I no longer need the street name, and stuff works fine.

[torkiljohnsen]

I am beginning to think the hardcoded family/given name requirement is not a good thing @bojanz. I see plenty of examples of countries where organization name is a perfectly fine addressee, and given/family name of a person is not required. Serbia for instance 😊