Simplifying Contact Info/Contact Method

[knelson-farmbeltnorth]

In the 21 June 2023 meeting it was proposed that we change Contact/Contact Type to Contact Method/Contact Method Type. This was generally agreed. (A Contact is an email address/ phone number etc.)

The question was also raised why Contact Info, its parent object that contains a mailing address in separate data fields, should not itself simply be a Contact Method (e.g., mailing address, physical address, etc.) The implication would be that address would be free entry of text as email and phone are today.

My first thought is that there is no difference between not modeling a phone number in separate fields for country code, area code, etc. than not modeling an address in its constituent fields. Contact Info is all metadata in ADAPT. E.g., querying ADAPT for all parties within a certain postal code is not a common agronomic use case, and even if it were, there is nothing to guarantee the address fields are filled.

As such, I recommend we collapse mailing address into a contact method and wherever Contact Info is used today we simply create a list of Contact Methods.

[knelson-farmbeltnorth]

Discussion in 28 June 2023 meeting. We should retain address and its constituent fields, but allow for multiple addresses like multiple telephone numbers and email addresses.

[knelson-farmbeltnorth]

Below is a proposal for simplifying ContactInfo following our discussion. Contact Info would become Contact Method, with polymorphic attributes for the type of Contact, vs. having 1 address at the top with multiple contacts

[knelson-farmbeltnorth]

Agreement in 5 July 2023 meeting to implement the following:

1. Retain a single Contact Info on each place it exists today.
2. Contact Info will contain a list of 0-many AddressContactMethods and a list of 0-many TelecommunicationContractMethods
3. Address Line 1/2 will be replaced by an open array of Address lines
4. Each of the address and telecommunication objects will have a type field with relevant members.