If logging is on then results will be retrieved from the log_xxx tables not civicm_log.
Normally these tables use the archive engine - which is not indexable. We have in some cases selectively converted these to INNODB & added indexes
Archive tables are supposed to be quick to write to and slow to read from. They are also non-transactional - which ...
I was able to create a script to revert in bulk. I needed to look up the log_conn_id value associated with the bulk change I made. I made the change using the API import, but any change that happens in a single connection can be reverted. Simply change the value of $log_conn_id in the script below, and change $tablesToRevert to include the table(s) that ...
Fortunately, in CiviCRM 4.7 (and Civi 4.6.17+), installing ANY extension will recreate your missing logging tables. Not that enabling an extension isn't sufficient - you must install an extension. See CRM-15078
The reason this works: If advanced logging is enabled, extensions without a corresponding logging table will generate errors. Because an ...
As of CiviCRM 4.7, you can fix this by installing any extension; see CRM-15078. Schema differences are fixed on extension installation.
If you are on an earlier version of CiviCRM, there's a trick you can do. Edit the PHP for a page that doesn't normally get used - I like the API Explorer page (CRM/Admin/Page/APIExplorer.php).
Right after public function ...
If you don't need the logs, you could delete them.
Which engine are your log tables using? There is a useful article by Eileen about ARCHIVE vs INNODB: https://civicrm.org/blog/eileen/who-did-what-when
By default the Report Contact Logging Report (Summary), that is used to display the detailed logging, requires the permission CiviCRM: administer CiviCRM.
If you create a CiviCRM user without this permission, you will be able to access the regular change log. This will include the entries before and after you enabled detailed logging.
This is a very ...
We wrote an extension a while back that anonymises contacts including entries in log tables. So you could anonymise the contact first and then delete them.
As Xavier has mentioned, you will have to make sure the log_ tables will be created with the right engine (InnoDB). If you already have log tables, you can either drop them, or convert them yourself. ...
Just to be sure I understand you properly: this is about the right to erasure (a contact ask your organisation to remove any data about them), right?
It's my understanding that indeed you should remove the data both from the live and the log table (as the later isn't a temporary backup but long term archive).
I recall a discussion about changing the format ...
Logging can be turned on via Administer > System Settings > Misc (Undelete, PDFs, Limits, Logging, Captcha, etc.).
You will find the relevant page on the Drupal demo site here
(NB, i am using the link to the master to give the url longevity)
You will also find explanation in the manual here
For people googling, I significantly increased the speed of the Change Log by following Eileen's advice in her answer: convert some tables (activity, activity_contact, contact, group, group_contact) from ARCHIVE to INNODB, and adding indexes.
The Change Log still takes ~20 seconds to load, but that's much better than the minutes it used to. We've taken a ...
Most people who have this issue are on CiviCRM 5.3-5.6, and is caused by the "missing logging tables" check assuming that temp tables should have a logging table. There is a fix available on Github, and it's part of CiviCRM 5.7+.
You may want to move log tables from main database to specially created database via settings in civicrm.settings.php. Of course, new empty database has to be created first. After that please find this in civicrm.settings.php:
* CiviCRM Logging Database
* Used to point to a different database to use for logging (if desired). If unset defaults to ...
This can be done on the commandline. You can pass a list of tables to mysqldump and omit the tables starting with log_.
(Below, testdb is the name of the DB we're using. You may want to add other parameters, eg auth details to connect.)
To get the list of tables you want, exclude the log_ tables using grep. (Seems you can't SHOW TABLES NOT LIKE.)
Answering (2) only here.
CiviCRM's payment processor logs vary in their location based on the CMS in use. These logfiles include a unique string per site, as the logfiles are located within the webroot and a hard to guess filename offers some defense against attackers viewing debug output.
This is documented @ -
I would register an account on https://chat.civicrm.org (I don't think it shares logins with the rest of civicrm.org but maybe that's changed). Go into the "infrastructure" channel and someone should be able to fix any issues.
I had the same problem - we run four different civi instances.
Two had detailed change logs, two did not.
Across all instances users had same privileges and all four instances had logging enabled. The difference other than civi versions was that two had change log report. So the change log tab runs off reports. Steps to fix:
1) check logging enabled in ...
My strong advice to you would be to change the tables to be anything but ARCHIVE. Even InnoDB would be fine and preferred over ARHCIVE. We've had a number of sites have their entire audit schema's become corrupt and its been down to the storage engine being ARCHIVE.
Also you'll probably want to add indexes into the audit schema otherwise you cant access the ...
If you have enabled the detailed logging it is currently displayed under the target contact of that relationship.
Arguably it would be better if it is shown on both contacts.
You can view all changes in the Contact Logging Report (Summary).
The log tables as originally implemented (I have checked for a few years if this is the case) also contain a large number of superfluous records due to writes that don't actually change the data. Improving the triggers to check for a difference between old and new values before the write to log would improve things for everyone.
Here is summary of our situation after ours reappeared.
This was actually a wrong message shown on the status page. The logging is disabled on /civicrm/admin/setting/misc?reset=1.
The flow which can lead to this error is -
Logging is enabled on the site which generates a list of log tables in the database.
User now disables the logging functionality on ...
Writing "code" could be as simple as a cron script that runs daily and does mysql -u user -ppassword -e "DELETE FROM log_civicrm_group WHERE log_date < DATE_SUB(NOW(), INTERVAL 2 MONTH)" databasename, which deletes records older than 2 months.
EDIT: To address your comment, if you want to completely disable logging but just for this table, you could drop ...
CiviCRM relies on CMS(i.e WP) settings when creating users. By default WP doesn't provide any such settings so you may need to install some plugin which needs admin approval for newly created user. Probably something like User Approve plugin.
You're running into the effects of this code which automatically logs the user in. Unfortunately there's no way to override this code at the moment - except to override the class file itself by putting an edited copy in your custom PHP folder like this and remove those lines.
A couple of alternative approaches are to:
Use BuddyPress to create the signup ...
Thanks a lot guys. You got me on the right way and I looked for a wordpress solution instead of a civi one.
I just added the following bits of code to my function.php file (in the child theme) to get disconnected and immediately redirected to a specific page (otherwise I was getting a civicrm error telling me I had no access to the page it was redirecting me ...
It seems you already have is_active column added to civicrm_status_pref table. This was added in civi 5.19 version.
From the backtrace, it seems the error is shown after civi tries to add the same column in the existing log table of civicrm_status_pref which is log_civicrm_status_pref.
Try renaming this table to eg log_civicrm_status_pref_backup and then ...
I can think of a way to do it the other way around, by defining your own civicrm logger and having it send to syslog. The problem is large stacktraces might get cut off and be formatted badly because of the way that works.
To get php to send all its errors including 500-level errors to civi might not even be possible, because they happen before civi even ...