This is similar to other issues, but there are problems with the way that addresses are formatted for non-US addresses. Basically the validation framework seems to assume a limited amount of formatting possibilities, locking us into non-standard formats.
Here in Australia, our postal format is:
28 Buckingham Ave
Bentleigh VIC 3204
Australia
The Google geocoding API formats this correctly. When returned from the backend, it gives: "28 Buckingham Ave, Bentleigh VIC 3204, Australia". But NPSP will format it in a very US style, expanding Ave to Avenue and shortening Australia to AU:
28 Buckingham Avenue
Bentleigh, VIC 3204
AU
This is due to the way the address format is hardcoded in the validator:
|
if (type_set.contains('postal_code')) { |
|
String verified5digs = addrCmp.long_name; |
|
String originalFull = address.MailingPostalCode__c; |
|
String original5digs = ''; |
|
if (originalFull != null && originalFull.length() > 5) { |
|
original5digs = originalFull.substring(0, 5); |
|
} |
|
//Google only returns 5-digit zipcodes. We don't want to override the original, if the |
|
//first 5 match, and the original has the additional 4. |
|
if (!(verified5digs == original5digs)) { |
|
address.MailingPostalCode__c = addrCmp.long_name; |
|
} |
|
} else if (type_set.contains('country')) { |
|
address.MailingCountry__c = addrCmp.short_name; |
|
} else if (type_set.contains('administrative_area_level_1')) { |
|
address.MailingState__c = addrCmp.short_name; |
|
} else if (type_set.contains('administrative_area_level_2')) { |
|
address.County_Name__c = addrCmp.long_name; |
|
} else if (type_set.contains('administrative_area_level_3')) { |
|
address.Administrative_Area__c = addrCmp.long_name; |
|
} else if (type_set.contains('street_number')) { |
|
streetNumber = addrCmp.long_name; |
|
} else if (type_set.contains('route')) { |
|
streetName = addrCmp.long_name; |
|
} else if (type_set.contains('intersection')) { |
|
intersection = addrCmp.long_name; |
|
} else if (type_set.contains('premise')) { |
|
premise += addrCmp.long_name; |
|
} else if (type_set.contains('subpremise')) { |
|
premise += addrCmp.long_name; |
|
} else if (type_set.contains('locality')) { |
|
address.MailingCity__c = addrCmp.long_name; |
|
} |
|
} |
I would recommend if possible, following "formatted_address" for the final format, particularly when choosing between short and long versions of the address segments. or providing the formatted address as a field on the address object for others to reference if need be. Or maybe offer a format string to allow the user to specify the address format they would like to have.
I'm very happy to contribute to a fix here, it would be good to just get guidance on the desired path to go down.
This is similar to other issues, but there are problems with the way that addresses are formatted for non-US addresses. Basically the validation framework seems to assume a limited amount of formatting possibilities, locking us into non-standard formats.
Here in Australia, our postal format is:
28 Buckingham Ave
Bentleigh VIC 3204
Australia
The Google geocoding API formats this correctly. When returned from the backend, it gives: "28 Buckingham Ave, Bentleigh VIC 3204, Australia". But NPSP will format it in a very US style, expanding Ave to Avenue and shortening Australia to AU:
28 Buckingham Avenue
Bentleigh, VIC 3204
AU
This is due to the way the address format is hardcoded in the validator:
NPSP/force-app/main/default/classes/ADDR_GoogleGeoAPI_Validator.cls
Lines 373 to 406 in 53157c1
I would recommend if possible, following "formatted_address" for the final format, particularly when choosing between short and long versions of the address segments. or providing the formatted address as a field on the address object for others to reference if need be. Or maybe offer a format string to allow the user to specify the address format they would like to have.
I'm very happy to contribute to a fix here, it would be good to just get guidance on the desired path to go down.