Custom Data - Contact Edit/View Form and Import Implementations

1. View/Edit Custom Data for a Contact

1.1 Initial implementation will use a hard-coded local task (tab) to 'view' and 'edit' custom data for a Contact.

• the tab is displayed under contact/view
• tab title is 'Custom Data'

NOTE: This is a temporary navigation solution. Once we have this feature coded, we will add logic to build the local task tabs dynamically within CRM code. The ultimate goal is to dynamically create a separate tab under view/contact for each Extended Property Group.

1.2 The custom data 'form' will encapsulate 0 to N extended property groups

• extended property group(s) are retrieved based on the contact_type being viewed (see 1.3 below)
• the form will be 'empty' if there are no ext property groups defined for the current contact's contact_type
• each extended property group will be displayed in it's own fieldset in the template (1 ext prop group = 1 fieldset)
• each fieldset will contain 1 to N extended property fields

1.3 A sample ext prop group with 4 fields will be pre-loaded from FixedData.sql. To retrieve property groups and fields for the form (pseudo-sql w/ sample data):

Select * from ext_property_group WHERE extends = '$currentContactType'
AND is_active = 1 ORDER BY weight

Ext property group.id 1 = Voter Info

SELECT * from crm_ext_property_field
WHERE ext_property_group_id = $extGroupID
AND is_active = TRUE
ORDER BY weight

Ext prop fld 1 = Registered Voter - Boolean - Radio...
Ext prop fld 2 = Party Registration - String - text...
etc.

1.4 For now field 'options' are not supported, and only the following html_type's are supported

• Text : <input type="text'.../>
• Textarea : <textarea $attributes></textarea> - (for now, attributes column will always contain string with 'rows="4" cols="80"' which can be inserted in textarea tag)
• Radio : supported for data_type=boolean only, so should display Yes/No radio elements
• Select Date : special instance of <select /> implemented for data_type = Date. !! Need to think about how select date range is determined (e.g. past dates, future dates, how far back/ahead ??). For now, implement w/ -5 and +5 years.

1.5 The form has 2 actions: view and update

• view displays the frozen form field elements
• update displays editable form field elements

1.6 Existing values for custom fields are retrieved from crm_ext_data. Match based on entity_id (crm_contact.id) AND ext_property_field_id.

1.7 UPDATE (save) will search for matching crm_ext_data record for each ext_property. If found, update appropriate storage bucket in that record (e.g. int_data, float_data, etc.). Else, insert new crm_ext_data record.

1.8 Validation of the input to the data_type is required (e.g. if data_type = int, input must be valid integer...)

==================================

2. Import with Custom Data
Part 2 of this task is to implement extended properties fields as 'importable' fields in the Import Wizard

2.1 Add 'active' extended property fields to the import mapper fields array

NOTE: Import only supports contact_type = Individual for now. So only select extended properties from ext prop groups with extends=Individual

2.2 Add logic to validate mapped ext property data to assigned data type

2.3 Insert crm_ext_data records for each mapped extended property field for each valid import data record

NOTE: We will be added an 'update record' option to Import Contacts pretty soon. So, the custom data import logic will then need to handle both contact insert and contact update cases. For contact update, the ext_data action may still be either insert or update depending on whether a crm_ext_data record already exists for that contact.id-ext_property_field_id combination.