Contact changes - CRM

DGG proposed this during our meeting and I felt it was too big a change at that time. On some more thinking, it might be something which we should consider.

The proposal is to merge civicrm_individual, civicrm_household and civicrm_organization into civicrm_contact. Here are the relevant fields which will need to be merged into the contact record from these three tables. (note that i have dropped fields that are currently unused)

civicrm_household

household_name varchar(128)    COMMENT 'Household Name.',
     primary_contact_id int unsigned    COMMENT 'Optional FK to Primary Contact for this household.'

civicrm_organization

organization_name varchar(128)    COMMENT 'Organization Name.',
     legal_name varchar(128)    COMMENT 'Legal Name.',
     primary_contact_id int unsigned    COMMENT 'Optional FK to Primary Contact for this organization.'

civicrm_individual

first_name varchar(64)    COMMENT 'First Name.',
     middle_name varchar(64)    COMMENT 'Middle Name.',
     last_name varchar(64)    COMMENT 'Last Name.',
     prefix_id int unsigned    COMMENT 'Prefix or Title for name (Ms, Mr...). FK to prefix ID',
     suffix_id int unsigned    COMMENT 'Suffix for name (Jr, Sr...). FK to suffix ID',
     greeting_type enum('Formal', 'Informal', 'Honorific', 'Custom', 'Other')    COMMENT 'Preferred greeting format.',
     custom_greeting varchar(128)    COMMENT 'Custom greeting message.',
     job_title varchar(64)    COMMENT 'Job Title',
     gender_id int unsigned    COMMENT 'FK to gender ID',
     birth_date date    COMMENT 'Date of birth',
     is_deceased tinyint   DEFAULT 0 ,
     deceased_date date    COMMENT 'Date of deceased',
     mail_to_household_id int unsigned    COMMENT 'OPTIONAL FK to civicrm_contact_household record. If NOT NULL, direct mail communications to household rather than individual location.'

The civicrm_contact table has 20 columns currently. Adding the above gives it a total of 37 columns. From our location experiment we add the primary ids of address / phone / email / IM (4) to make it a total of 41 columns which does not seem crazy. I suspect we might want to keep billing seperate in the individual tables as it does not seem to be used a lot across the board

contact_subtype

A field contact_subtype of contact (which exists in 1.x) will indicate that the contact is an extended contact object.

The additional fields and behaviors will be exposed as a CiviCRM 2.0 Component.

A subtype component exposes itself to CiviCRM as an object implementing the following interface:

– Note: this is a first pass, since the component architecture is still in process –

interface CRM_Core_ISubtype {
   
  /**
Called on create and update
  **/
  array create(array $params, array &$ids);

  boolean verify($params);
 
  void delete($id);

  array preProcess($params);
   
  array postProcess($params);

  /**
    @param &$title  title of tab or block
    @param &$isInline true if this is a block to render inline, else a separate tab 
    @return a path to the Smarty Template for rendering the data as either a block or a tab.
  **/
   string getViewTemplate(&$title, &$isInline);

   string getEditTemplate(&$title, &$isInline);

   string getSearchTemplate(&$title, &$isInline);

}

A instance of a class implementing this interface will be created by a component factory class (TBD by Michał).