REF - Use CRM_Contact_BAO_ContactType::basicTypes() instead of hardcoded lists

[colemanw]

Overview

Uses a function to return contact types wherever they're needed.

Before

Codebase littered with hardcoded arrays like ['Individual', 'Organization', 'Household'].

After

Uses function which returns that array.

Technical Details

This makes code more flexible/forgiving if new contact types are added in the future, or if existing contact types are disabled.

Also passes TRUE as the 3rd param to in_array() which is best-practice to avoid type coercion.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[braders]

Looks good with a quick test on the test site. I've just noticed one more instance of ['Household', 'Individual', 'Organization'] in the _civicrm_api3_custom_format_params function which probably wants updating at the same time. Otherwise looks good.

I've also noticed templates/CRM/UF/Page/ProfileTemplates.tpl has the types hardcoded in the template. Possibly out of scope for this PR, but you might want to do a follow-up.

There is also the contactOptions field in CRM/Admin/Form/Options.php which should probably be built from the helper function (albiet with 'Multiple Contact Merge' added). The number of places this is hardcoded has definitely reduced after this change though.

[colemanw]

Thanks @braders I've updated _civicrm_api3_custom_format_params. The others are a little trickier so I'll keep this PR simple enough to be mergeable.

[eileenmcnaughton]

I went through this PR & all the changes make sense - a couple of unused params removed too

Merging