CiviCRM Community Forums (archive)

You do NOT need to add activity types for actions which are related to CiviContribute, CiviEvent, CiviMember, CiviMail and Send Email functions.

These are the modules in activity_history table for which history records are migrated to 'activity' table provided -
- their activity-types are common such as 'Membership - New' /  'Membership - Current' (for module=CiviMember), 'Event Registration' (for module=CiviEvent) ..etc
OR
- a corresponding entry is found for the activity-type in civicrm_option_value table for the group 'activity type'.

When I run SELECT DISTINCT(activity_type) FROM civicrm_activity_history; on the 1.9 db I get:
Event Registration
Email Sent
Membership - Good Standing
Membership - Inactive
Membership - New
Phone Call

Why am I getting this error?

So there could be cases when all the history records can't be migrated to activity tables for which activity_history table (along with un-migrated records) is retained in your database and hence you receive that warning, pointing to wiki-doc - which tells you 'how you can migrate rest of the history records to activity table'.

In your case the uncommon activity types are - 'Membership - Good Standing' and 'Membership - Inactive'.

I just checked the query and confirmed that it checks for 'Email' and NOT 'Email Sent', since 'Email' was used as option_value.label for 1.9 and same has been continued for 2.0.

So 'Email Sent' also comes under uncommon activity-types.

(Sorry for not pointing this out in previous post.)

OR another option would be to change 'Email Sent' to 'Email' for your history records.

If you want to change it in the file - here it is : CRM/Upgrade/TwoZero/sql/activity.mysql (line 312)

Sorry again. Infact there are two lines which will require the change -
line-312 and line-351

line-312 migrates record to activity table and

line-351 deletes the records from history table.
DELETE FROM civicrm_activity_history WHERE module IN ('CiviCRM') AND activity_type IN ('Meeting', 'Phone Call', 'Email', 'SMS', 'Event');

So records must have been migrated but couldn't have been deleted from history table (since line-351 change was not there).

I made an amendment and a comment to Upgrade Drupal Sites to 2.0 last week re activity history as a result of my experiences:

Amendment (in italics):

Migrating Activity History Records from 3rd Party Modules or with Types missing from current Activity Types list

If your CiviCRM installation includes integration with other Drupal modules which have inserted Activity History records, or if - perhaps due to activity types having been renamed - there are Activity History records having types not in the current Activity Types list, and you want to retain these records - please refer to this document before continuing the upgrade. You can check for such records with the following  SQL query:

SELECT DISTINCT(activity_type) FROM civicrm_activity_history
  WHERE activity_type NOT IN (SELECT label FROM civicrm_option_value WHERE option_group_id = 1)

Comment:

    Sometimes I've been warned about 3rd Party Activity records when there were none.

- Same here. I've just encountered this upgrading a db where no 3rd party apps were used. The problem seems to be inconsistency in the activity_type stored in civicrm_activity_history: the db has over 5000 records with type 'Email Sent' and 31 with type 'Email', but civicrm_option_value has only 'Email'. Similarly civicrm_activity_history has records of type 'Event Registration' but civicrm_option_value has only 'Event'.

I'm not sure how this occurred. The db started life in Civi 1.4 . I couldn't rule out that the client has changed activity type labels in Civi admin; certainly they have added new ones.

Here's a query to identify any problematic activity types:

SELECT DISTINCT(activity_type) FROM civicrm_activity_history WHERE activity_type NOT IN (SELECT label FROM civicrm_option_value WHERE option_group_id = 1)

I resolved the problem by making the civicrm_activity_history records consistent with the civicrm_option_value activity types, e.g.:

update civicrm_activity_history set activity_type = 'Email' where activity_type = 'Email Sent'

The upgrade procedure now completes but much of the activity details have been lost: most dates are now NULL and most view links for activities are broken. So maybe don't do what I did. I'm hoping that the fix for CRM-2914 will resolve this.

I've just re-done the upgrade with Civi 2.0.3 and I still have the issue with null dates and broken links on most activity records. The records in question are custom activity types that the client set up through Civi Admin. No 3rd-party apps are involved. AFAICS the approach of the upgrade script activity.sql is to throw away all the date data (DROP `scheduled_date_time`) and then reinstate it for specific known activity types, e.g. phone calls. Would it be possible instead to retain the dates and overwrite them only where there is a known better source, e.g. by renaming the scheduled_date_time column instead of dropping it?

I'm not clear why I now have broken links for almost all the activity records. Here's an example:

Before upgrade - view link from Civi 1.8:
/civicrm/contact/view/activity?activity_id=6&action=view&selectedChild=activity&id=794&cid=2663&history=0&context=Home

After upgrade: - view link from Civi 2.0.3 for same activity:
/civicrm/contact/view/contribution?action=view&reset=1&id=&cid=3&context=home

Note the missing value for id, hence the broken link ("Sorry. A non-recoverable error has occurred. is not of the type Integer"). The "/contribution" in the URL is odd too, as the client does not use CiviContribute. The activity in question is of a custom activity type ('Newsletter Query') set up through Civi Admin.

The good news for us is that we really haven't started using the activity tracking features much yet.  All we're really using is CiviEvent while my administrator edits the 100's of individual contacts to mark and link each one to "use household address"

However, I think that there is data loss with this upgrade.  I used the system to send an email to event attendees.  That activity shows under my activity history.  Shouldn't it also show under the recipient's history?  Phone calls seem to show on both.

There's another issue with activity history. In 1.9, there seem to be 2 civicrm_activity_history records per activity: one with entity_id = source and the other with entity_id = target and no indication in the db AFAICS of which is which, except that the record for the source seems to have been inserted first and so have a lower id. The 1.8/1.9 activity display code is clever enough to work out which is which and show the correct contacts as 'With Contact' and 'Created By'.

The 2.0.3 code doesn't handle this and instead displays two rows for a single activity.

In the target contact's Activities view, both rows have the correct target contact but one says Added By the target contact, the other says Added By the source.

In the source contact's Activities view, both rows have the correct Added By contact but one shows the target contact under 'With', the other shows the source contact.

(Use case: I came across this issue when the client asked me to set up CiviReport, initially for activity history - they need to tell their funding body how many queries of various types they have dealt with. In 1.8 I was getting 2 rows per activity. At that point I read about the new db structure for activities in 2.0 and so tried upgrading a copy of their db on a test server - their live server is still on MySQL 4.1 . I was hoping that the new structure would resolve the duplicates.)