Jump to content

Fundraising/Internal-facing/CiviCRM/Triggers

From Wikitech

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.php

Triggers are also used to update calculated custom fields in the WMF Donor field group when a civicrm_contribution row is added, updated or deleted. These triggers are defined in the wmf-civicrm extension in CalculatedData.php. After making changes to this file locally, you can flush caches and then turn logging off and on again as below to update the triggers as below.

You can also run (locally or on prod):

wmf-cv api4 WMFConfig.syncCustomFields

to update the custom fields defined in this file.

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 (ext/wmf-civicrm/sql/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

wmf-cv Setting:set 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

wmf-cv Setting:set logging=0
wmf-cv Setting:set logging=1

This will generate a file named something like CiviCRM.trigger62451ae5ab5a5mYm67702126718965e4a41105a08d6202e60.sql that will be in private/log/ - copy this back to your home drive and scp it back to your local machine as ext/wmf-civicrm/sql/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