Expose 'supplemental address 3'

[John.K]

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.

[Coleman Watts]

Agree there's no need to have the field in the db if there's no way to enable it.

[andrewhunt]

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.

[John.K]

I'm happy to take this on, but this is why I opened it up for discussion, as there have been two opposite opinions: remove or expose!

I don't have a particularly strong view either way. But I suppose if people have hacked files to get the field to show, and store data in the database, then removing the field would cause issues for those people?

Thanks for the responses.

[Coleman Watts]

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.

[John.K]

Sorry for the assumption coleman, looks like I'll go ahead and get stuck in to this when I can then. Thanks for the feedback.

[John.K]

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...

[John.K]

Unfortunately I don't think I'm going to be able to implement this, I'm not sure I'd be able to reliably find all the places this would need to be added, and develop the required automated testing. Since it affects so many files, we would also come across a number of merging issues before it was ready to roll, and we have a number of other priorities to focus on at the moment. Sorry to have to drop this one.

I think the way these location fields are set up should be addressed (no pun intended) before trying to properly integrate supplemental_address_3. Having the fields listed, and labels and titles defined in several different files does not seem like the right approach. I've attached a file which lists all the instances of supplemental_address_2, and whether they would need to be edited to introduce supplemental_address_3. If someone else wants to pick up the mantle then this might be of some use.