I'm moving this task into the current sprint as it is actually a better descriptor of the work I had been tagging against T127133: - which I can close out if I bring this one in instead.
I'll re-submit those patches against this one
Description
Description
Event Timeline
Comment Actions
Turning logging on normally involves manually enabling the setting in the UI under administer/admin/setting/misc - however we need to turn it on without it running the sql to create the triggers and then running that manually.
Ideally the steps would happen in the following order ....
First (ie. these have to be before later steps but not necessary 1,2,3
- deploy setting metadata updates & refresh the cache table. This can happen at any time & I expect it will be deployed in advance of the main deploy & include the settings in 4 & 5 T131225
- Update civicrm.settings.php on live to hold information about the log table database
a) we need to resolve the question Adam raised as to whether there is any ACID transaction down-side to putting the tables in different DBs T131231
b) Create the log table database on live, give the mysql user permission to create tables & edit them in this DB
- Create any extra fields desired for Major Gifts - T128818
- fix the logging code so that it is in sync with 4.7 & the enable can be done by script T131228
- fix the logging code so that the triggers are not created in realtime if a setting is in play - https://issues.civicrm.org/jira/browse/CRM-18212. This also allows us to remove a custom hack. T131224
- agree how we will deal with the trigger create mysql. As a result of no 5 this is generated when enabling logging by script or through the UI. The file is created in the ConfigAndLog directory & will have a name like CiviCRM.trigger56fb312761e9b.ad99b4408e6ec145cc669e040d87818c.log - it can be checked into github or we can use the one we generate when doing the logging. I am more inclined towards generating it in advance T131230
Once the setting metadata is deployed & flushed
- enable setting to log triggers offline
Actual deploy
- disable long process killer
- run the command to enable logging via the drush or upgrade script. This will create all the log tables & take aaaages. Note that if it did fall over then it should continue from where it left off if run again. I haven't cleaned up the process for creating the tables to the same extent as I have the the trigger sql because it is possible to run this as the mysql user without involving root
- Jeff needs to run the trigger sql with his mysql permissions
Dev installs
- Figure out a process to set up our logging on people's dev installs. If they have Create Trigger permission already for their mysql user then it would just be a case of enabling e.g via drush in the build script. Otherwise wen't need to figure out importing the trigger sql. T131232
Note that if we need to do this in build kit we should probably deal with the issue of our buildkit being massively out of sync with the upstream one at the same time (possibly rebranching master & re-applying our patches selectively).
I feel like this is a follow on task. Noting this makes me inclined to enable the logging manually or via drush at time of deploy rather than put it in the upgrade script.