Overview

We use triggers to store forensic information using CiviCRM's core logging functionality - we also alter these in

wmf_civicrm_civicrm_triggerInfo in wmf_civicrm.module

Update triggers on production

We use mysql triggers to log civicrm database updates to the log tables. These triggers are managed by CiviCRM. However, our production user does not have enough mysql permissions to create the triggers within mysql. To get around this we use a CiviCRM setting on production to log the sql to update the triggers to a file rather than live update them. We then check this file into our crm repo (sites/all/modules/wmf_civicrm/scripts/triggers.mysql currently) and fr-Ops run the file on live.

On development environments triggers are automatically updated in the database - which is generally easier - but to make your local output the triggers as live does the logging_no_trigger_permission setting can be enabled

drush @wmff cvapi Setting.create logging_no_trigger_permission=1

Trigger generation needs to be done on production as the fields differ slightly on staging / dev environments. There are a few methods but turning logging off & back on generally generates consistent output. ie

 drush @wmff cvapi Setting.create logging=0
 drush @wmff cvapi Setting.create logging=1

This will generate a file named something like CiviCRM.trigger62451ae5ab5a5mYm67702126718965e4a41105a08d6202e60.sql that will be in drupal/sites/default/files/civicrm/ConfigAndLog/ - copy this back to your home drive and scp it back to your local machine as sites/all/modules/wmf_civicrm/scripts/triggers.mysql. Changes to this files are committed, reviewed and deployed but they will not be 'live' until fr-tech-ops loads them so once deployed they need to be engages to run the latest triggers.mysql file