As hinted previously, CiviCRM 3.3 introduces a new feature, a low-level tracking of everything that happens with a given installation’s data: who does what exact change (and when).
Currently the configuration is either non-existent (if you’re ok with having the log tables in the same database as the rest of CiviCRM tables) or requires setting CIVICRM_LOGGING_DSN in your civicrm.settings.php file (if you want to use a separate database for logging tables).
Logging can be enabled (and, later, disabled) by going to Administer → Configure → Global Settings … Miscellaneous and flipping the Logging Yes/No option. Enabling creates the log tables and the relevant triggers (see below) and populates the log tables with initial data. Disabling removes the triggers, keeping the log tables intact. Re-enabling drops and recreates the log tables and re-establishes the relevant triggers.
Logging is implemented by creating a set of tables that mirror the schema of almost every existing CiviCRM table (except *_cache and civicrm_import_job_* tables), with four additional columns: log_date, log_conn_id, log_user_id and log_action. Each mirrored table gets a set of ON INSERT/UPDATE/DELETE triggers that populate the relevant log table accordingly. The log tables are append-only, and so use the ARCHIVE engine, which is quite fast and shouldn’t have any visible impact on the daily operations on the logged CiviCRM installation. On the initial table creation the log tables are populated with the current database contents, with the log_action column set to ‘Initialization’. On subsequent INSERTs, UPDATEs and DELETEs the row in question is duplicated into the log table with log_action set to ‘Insert’, ‘Update’ or ‘Delete’, respectively. The log_date, log_conn_id and log_user_id columns are populated with the timestamp of when the change was made, the database connection id used (so changes can be grouped across tables) and the civicrm_contact.id of the user/operator who did the change.
Once logging is enabled, two example report templates are enabled (and two matching report instances are created) – ‘Contact Logging Report (Summary)’ and ‘Contact Logging Report (Detail)’. Currently these reports track only changes to the civicrm_contact table, but in the future releases they will be more feature-full.
Due to its heavy trigger (ab)use, currently logging cannot be used with multilingual CiviCRM installations; this will be addressed in a future release (either 3.3.x or 3.4). Also, the reported diffs are limited to the civicrm_contact table only (changes to things like custom data are tracked, but not yet reported) and show raw database changes (hence prefix change is reported as a numerical change of a prefix_id). These limitations will be addresses in 3.3.x releases – but do feel free to jump in and help (refer to the CRM/Report/Form/Contact/Logging* files).
If you find any issues with the current logging infrastructure or reports, please do comment in the relevant !