Field metadata cleanup: Contact & Activity & Custom

[colemanw]

Overview

Cleans up metadata for Api4 GetFields, so it's more useful to formBuilder.

Historical note: the 'html' data was added a few years ago at a code sprint but hasn't been used for anything except CRM_Core_Form::addField, which itself is rarely used. So mistakes made in adding that metadata didn't affect anything and weren't caught.

Before

Some incorrect metadata, and fields that should not be exposed to the UI were given an html_type.

After

Metadata better.

Technical Details

• I removed html metadata for any field that should not be exposed to the UI.
• The activity_type_id field had "ID" in the user-facing label, which is a practice I'd like to discourage. Apparently this was added for the sake of export (9ab3417), so I've changed it in the export fields list instead of globally.
• Api4 was guessing the html type, which is something I added a little while ago but almost immediately regretted. AFAIK nothing uses it yet so let's get rid of it while we still can. Fields that should not be exposed to the UI should not have an html type.
• Fixed api4 to return help_pre and help_post from getFields.

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

[totten]

For a full dump of the changes, check this gist.

[totten]

@colemanw

• Impacts on APIv3 - Shows maybe 10-20 fields affected by this change
• Impacts on APIv4 - Shows maybe 400 fields affected by this change

On the APIv3 side:

Field	Comment
Activity.activity_type_id	Neutral (before or after accepable)
Activity.campaign_id	👍
Activity.duration	👍
Activity.is_current_revision	Unsure; at first glance, I'd expect this to work like is_deleted
Activity.is_deleted	👍
Activity.is_star	👍
Activity.is_test	👍
Activity.phone_id	Neutral
Activity.result	Unsure; if you were building a UI for CiviCampaign, wouldn't these fields be useful?
Activity.weight	Unsure; if you were building a UI for CiviCampaign, wouldn't these fields be useful?
Contact.addressee_display	Unsure
Contact.addressee_id	👍 Sounds sensible
Contact.email_greeting_display	Unsure
Contact.email_greeting_id	👍 Sounds sensible
Contact.postal_greeting_display	Unsure
Contact.postal_greeting_id	👍 Sounds sensible
Contact.primary_contact_id	Unsure

On the APIv4 side... that's a very long list. You might want to look at it and see if it's really intended impact.

[colemanw]

@totten thanks for making those diffs. I've gone through them and am happy with the changes. IMO this is merge-ready.
To respond to your "unsure" items:

• Activity.is_current_revision is at least partly broken and pretty much deprecated at this point. I'd love to remove it. But regardless, it doesn't appear as an input on any forms so doesn't need a widget.
• Activity.result is not used in normal activity workflows and at any rate the widget info was wrong. According to the comment it is "Currently being used to store result id for survey activity, FK to option value." so a text input would be inappropriate.
• Activity.weight - I'm not sure this is used anywhere, but in general weight is not something you'd expose an input field for, it's something you calculate when sorting items in a list.
• Contact.addressee_display, Contact.email_greeting_display, Contact.postal_greeting_display: these are calculated fields. Input would not be appropriate.
• Contact.primary_contact_id - field may be unused but anyway the widget info was wrong.
• All the Api4 guesswork - guessing field types is just a bad idea cause then you can't rely on that info for anything. YAGNI and it was getting in the way of a functional form-builder GUI.

[totten]

@colemanw Thanks for talking through those. I agree that all those Activity/Contact fields have conceptual issues. We don't do anyone a favor with odd metadata, and (if someone comes upon some unanticipated use-case which needs adjustment) it's better that they start with "this metadata field is blank/unspecified" (rather than "this field looks wrong and we don't know why"). The description here ("Metadata better") makes sense. 👍