CiviCRM Community Forums (archive)

Use case
Some countries have legitimate addresses that run to many lines. By default CiviCRM cannot handle these.

Currently
Supplemental address 3 is referenced in several places in CiviCRM (Core\DAO\Address.php) and can be enabled by hacking a few files, as noted here: http://forum.civicrm.org/index.php/topic,2827.msg12363.html

Proposed resolution
It seems strange to have 'supplemental address 3' half 'there', and half 'not there' in the code and interface. I propose that the field is fully integrated into CiviCRM by default, but not enabled by default. Ie: it would be deselected by default in the Localization > Address settings.

This allows people to hold longer addresses if they need to, but doesn't subject everyone to the extra field by default. It also creates more consistency between the code and interface, I would have thought. Let's expose it (disabled) by default, or get rid of it?

Current alternative: custom fields
Additional address lines could be added as custom fields to the address entity. They can then be output in the address structure in Localization > Address. However they cannot be placed into the correct location when editing an address on a profile (ie: a custom 'supplemental 3' would appear underneath the entire address, not underneath 'supplemental 2').

Custom fields are fine if further information is required, but my main concern is with the 'supplemental_address_3' field that is currently 'half-present' in Civi.

Yeah, I think your proposed resolution is exactly what should happen.  I don't think it would be terribly difficult to do--basically everywhere "supplemental_address_2" shows up, add an equivalent bit for "supplemental_address_3".  You'll probably come across about a hundred lines of code to edit in 80 or so files, but the work wouldn't be difficult when you get into it.  It would be intelligently copying and pasting for the most part.  If you're thinking of hacking core to do this anyway, it would save you time to do it systematically and get those changes into an upcoming version so you don't have to repeat your work later.  Let me or others on the forum know if you need any help on it, but I think it would be a good opportunity to for you to invest time now and save time later, and it would help others in your situation.

To clarify, I wasn't making a case for remove, just agreeing that the field currently serves no purpose and it would be great to fix that
I fully support your plan to enable support through it via the "Address Options" admin screen.

I've been taking a look at this today. There are indeed about 80 places to change this.

I'm really rather baffled by all the different approaches in use. A list of 'address fields' seems to get defined in a dozen places, in a dozen different ways. Surely this should all be centralised somewhere. I'll report back when I've finished the audit...