Custom Data - Link Custom Field Groups to Dynamically Defined Classes (Contact Sub-types, Activity Types, etc.)

Users need the ability to associate custom data fields with object types that are dynamically defined via database properties. For example, if you configure a custom Activity Type for "Field Visits" - you could define one or more custom fields that would ONLY appear on the Create/Edit Activity forms when that activity type is selected.

For this issue, following top level objects should support dynamic custom data group linkage:

• Contact : via contact_sub_type
• Activity : via activity_type_id
• Relationship : via relationship_type_id
• Contribution : via contribution_type_id

1. Add properties to civicrm_custom_group to link the group with a dynamic object type. We can handle this with two new columns:

• extends_entity_column_name (e.g. 'activity_type_id', 'relationship_type_id'...)
• extends_entity_column_value (e.g. FK to 'civicrm_activity_id'...)

EXAMPLE 1: If a custom data group is extending Activity for activity_type.id = 3

• civicrm_custom_group.extends = 'Activity'
• civicrm_custom_group.extends_column_name = 'activity_type_id'
• civicrm_custom_group.extends_entity_column_value = 3

2. Modify Custom/Form/Group.php and Custom/Page/Group.php to include support for optional property to define the dynamic subclass.

• Once user selects a "class" in "Used For" field, a new hierselect field is displayed - "Type". This drop-down should use 'any' as the null option. It should include options for all defined "types" of the selected "Used For" (e.g. extends) option. For example, if I select Activity - the 2nd drop-down displays all ACTIVE activity_type.name values.

NOTE: Same as for extends, the new Type field is read-only when custom group is being edited (it can not be modified).

• Add "Type" column to browse (selector) for custom data groups and display either (any) or the selected type name.

3. Modify edit forms/view pages for each of the above classes to handle the new "type" limit (e.g. if a custom_group extends that class, check to see if this is limited by 'type' before including the fields).

3.1 We will eventually use Ajax to dynamically update the form fields when a "type" is selected which has specific custom fields attached to it. For this first version - please implement a Javascript onchange function for the "type" <select> fields. This function reloads the form with an added GET parameter specifying the "type" - which will trigger the new type-specific custom fields to be added to the form.

3.2 The php/tpl files which extend the main object form with type-specific custom fields should be separate from the main object form. (This will make it easier to implement the Ajax "upgrade").

3.3 In EDIT mode, postProcess() will need to check if the type-driven custom fields have changed (due to a change in the "type" of the object). If so, the existing custom data values will need to be cleared and the new values saved.