Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
CRM-20958 - Fill in creation and modification times
This implements the migration procedure from CRM-20958. To test it, I did these steps: * Create a new build with `4.6` (eg `civibuild create d46`) * Create a new case (Housing Support; case_id=1, activity_id=625-632) * Edit one of the activities (Long-term housing plan). Tweak the subject. * Edit the same activity again. Tweak the subject again. * Create another case (Adult Day Care Referral; case_id=2, activity_id=633-637) * On the CLI, delete the "Open Case" activity. (cv api activity.delete id=633) * Create a new standalone activity (Meeting; "Mess up my history"; act_id=638) * In SQL, delete its log records (`DELETE FROM civicrm_log WHERE entity_table='civicrm_activity' AND entity_id=XXX`) * Create a new standalone activity (Phone Call; "Do some revisions"; act_id=#639) * Edit the activity multiple times * Make a DB snapshot * `civibuild snapshot d46 --snapshot d46-caseactlog` * Create a new build with `master` (eg `civibuild create dcase` or `dmaster`) * On the newer build, load the snapshot and run the upgrade * `civibuild ut dcase /Users/myuser/buildkit/app/snapshot/d46-caseactlog/civi.sql.gz` * Compare results * On old DB, run * `SELECT * FROM civicrm_log WHERE entity_table='civicrm_activity' AND entity_id BETWEEN 625 AND 639 ORDER BY entity_id, id;` * On new DB, run * `SELECT * FROM civicrm_log WHERE entity_table='civicrm_activity' AND entity_id BETWEEN 625 AND 639 ORDER BY entity_id, id;` (should match above) * `SELECT id, created_date, modified_date FROM civicrm_activity WHERE id BETWEEN 625 AND 639;` (should match above) * `SELECT id, created_date, modified_date FROM civicrm_case WHERE id BETWEEN 1 AND 2;` (should match above) Note that the data produced here is a bit dirty, but upgrade procedure commensurate output: * The last true modification in case `#2` was *deleting* the "Open Case" activity. However, there's no *record* of this deletion in the standard schema, so it doesn't influence the `modified_date` of the case. The problem is with the old data and the old tracking scheme -- not relevant to the migration. * Activity `#638` didn't have any log records, so its `created_date` and `modified_date` were left as `NULL`.
- Loading branch information