• Type: New Feature
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: None
    • Fix Version/s: 1.4
    • Component/s: None
    • Labels:


          • NOTE: This should be implemented AFTER CRM-675 as it will use the same logic for determining which contact the newly inserted activity record 'belongs' to.

      Users need the ability to import Activity History data - using either our PK (contact_id) OR match-able contact data (name/email) to match activity to the contact records in the DB. This functionality s/b modeled after the revised Import Contributions UI and logic.

      We use the configured Duplicate Matching rules for the site to identify the contact associated with each incoming Activity import row.

      1. Reorganize CiviCRM menu block - replacing existing 'Import Contacts' menu with a nested menu:

      • Import
      • Contacts
      • Activity History

      2. Activity History Import Wizard
      New set of wizard / statemachine files for this wizard. UI language s/b pretty similar to the contribution set.

      2.1 Field mapping Select_Values (options) include civicrm_activity_history properties (activity_type, module, callback, activity_id, activity_summary, activity_date) plus an option for each contact field referenced in that site's Duplicate Matching Rule. So, given the default matching rule (first_name AND last_name AND email) - we would dynamically add the following options for contrib import mapping:
      First Name (match to contact)
      Last Name (match to contact)
      Primary Email (match to contact)

      2.2 Validation for mapping screen:
      2.2.1 User must map one of the following combinations of 'matching columns'

      • Contact ID only
      • First AND Last Name
      • Primary Email
      • First, Last AND Primary Email
        2.2.2 User must map at least the following activity history columns:
      • Activity Type
      • Activity Date

      We do NOT validate the activity type values to our civicrm_activity_type DB values - they can insert values not defined in that table.

      3. Error handling rules:
      3.1 If more than one DB contact record matches the contact-matching data in the incoming row - the row is skipped (not imported) and it is reported in the error count, and the row is part of the error download - Error msg = "Multiple matching contact records detected for this row. The activity was not imported."

      3.2 If NO DB contact record matches, row is skipped etc (this should be exactly same as current matching on contact_id - except error msg should reflect the field(s)/value(s) which we tried to match on.

      NOTE: When viewing inserted activity history items - only items w/ callback AND activity_id values should include a 'Details' link (this s/b existing functionality - but pls verify when testing imported records).




            • Assignee:
              anil Anil Kokitkar
              dgg David Greenberg
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: