Use description from schema if available when using entityForm

[mattwire]

Overview

Further development of entityForm.

This adds the (default) ability to automatically show the description from the entity schema instead of hardcoding in the entityFields property on the class.

Before

Converting to entityForm requires moving description from tpl to setEntityFields() in form class.

After

Converting to entityForm requires verifying metadata description in xml schema and updating if necessary. Description does not need to be hardcoded in class.

Technical Details

We get the metadata using API.getfield. Technically this means we are now calling this twice (as it is also called by addField later on).

Comments

@mlutfy Please could you comment from a translation perspective.. ie. do the schema elements get translated?
@eileenmcnaughton Next stage of entityForm...

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

[eileenmcnaughton]

changing visibility can break forms that extend the parent - I did a grep & found a few places that implement function getApiAction() with 'protection' but none with private so I guess that is fine. Also it's a bit intuitive that changing up from private is probably ok since private is not available to override

[mattwire]

Yes, so basically we're making it accessible from child classes which is needed to get the right API action to retrieve the metadata.

[eileenmcnaughton]

@mattwire So this is a good thing to do. I note a few things

1. some enotices
   

2. I think I'd probably tweak the description of the description field rather than override to block -

• changing 'verbose' to 'generic' seems like it would be fine

3. re translation - here is the DAO

        'description' => [
          'name' => 'description',
          'type' => CRM_Utils_Type::T_STRING,
          'title' => ts('Relationship Description'),
          'description' => 'Optional verbose description of the relationship type.',
          'maxlength' => 255,
          'size' => CRM_Utils_Type::HUGE,
          'table_name' => 'civicrm_relationship_type',
          'entity' => 'RelationshipType',
          'bao' => 'CRM_Contact_BAO_RelationshipType',
          'localizable' => 1,
          'html' => [
            'type' => 'Text',
          ],
        ],

You can see description is not translated - I think maybe it should be @colemanw @mlutfy - any concerns if we add ts around description field when generating DAOs

[seamuslee001]

This may need to change to

Suggested change

	if ($props['not-auto-addable']) {
	if (!empty($props['not-auto-addable'])) {

[mattwire]

Yes. Done :-)

[mattwire]

2. I think I'd probably tweak the description of the description field rather than override to block -

I didn't want to touch the actual descriptions until we got this PR into shape and merged. And I think there will be situations where there is a description in the schema that we don't want to show on the form but may popup elsewhere (eg. API explorer). So blocking this particular description was more of a proof of concept to show we can override/hide them if desired.

[eileenmcnaughton]

@mattwire OK - we'd better resolve the ts issue then - @colemanw ....

[eileenmcnaughton]

If we can resolve #13005 then we can merge this

[eileenmcnaughton]

@mattwire the other PR is merged so merging this so we can 'mature it up'