be able to limit logging to specifc tables

[joanne]

Two things to do with logging.

1. We have logging enabled, and I do need to use it not infrequently to look up when what and who has changed contact details for particular people..  Sometimes I need to revert the changes. The change log tab takes for-e-ver to load and mostly it is things I don't need to know about.

It would be great to be able to control which tables were actually logged, or perhaps better still, which log tables where displayed in the change log tab. (Then the info would still be in the db tables on the rare occasions I need to check something other that contact changes.)

2.  The slow loading of the change log tab is actually worse since we upgraded from 4.2 to 4.4 because now I am seeing a whole lot of  Insert  - activity statements which I am fairly sure weren't showing in 4.2.  This seems a bit of an overkill actually,  as you can get that detail from the activities tab itself.

What is the reason for including insert - activity items in the change log?

[Eileen]

JoAnne,

One thing we have done in the past is actually alter the table type on some tables. The normal table type is 'archive' - fast to write slow to read. After some discussions we have felt it was safe to change the table type to INNODB on specific tables & add some indexes - which does speed retrieval susbtantially. I would be surprised if there is much performance impact except possibly in bulk operations

[joanne]

We do quite a lot of bulk operations and people already complain that civi is slow, so I am reluctant to make changes that will slow down the system for the majority of users when I am quite possible the only person who refers to the change log. 

Having said that though, the current situation is driving me crazy as it takes nearly 4 minutes to load the first page (50 items) of a change log of 142 items,  then a couple of minutes more when I want to look at page 2 and more still when I want to load page 3.

61 of those "changes" are actually insert activity (Bulk email) and another 23 are insert activity (various activity types).   We no longer create activities for the bulk emails so that 61 won't increase, but the 23 will. 

I could question the rationale behind logging Insert activity when that information is already available from the activities tab but I won't.

Instead I want to ask if there is any reason why I shouldn't go directly to the db and delete all entries relating to bulk emails ( activity Type_id = 19 on my install)  and all entries where log_action = 'Insert" from the log_civicrm_activity table?

[Donald Lobo]

note that more recent versions of the logging code have selectively disabled logging on a few more tables (specifically all the mailing_event tables)

in the long term, would be good to allow the admin to decide which tables to enable logging and optimize it that way. I suspect this is a 10-20 hour project (but seems totally worth it for folks using logging)

In the short short term, we (i.e. eileen) could introduce a hook that allows a module to disable logging in certain tables, and so u can disabled logging in the civicrm_activity_* tables

lobo

[joanne]

I think allowing admin to decide what tables to log or, even better, what tables to display in the change log tab would be a great improvement, but my organisation just doesn't have the dollars to finance that and I don't have the skills. (I've gone backwards since the Dalesbridge sprint and then all I could do was change text on forms!)

I can't even pay Eileen to do anything about a hook - it is way too far down my organisation's priority list for that.

So I have experimented on our dev db and I am reporting back here in case anyone encounters the same problems I have and finds this thread.

DELETE  FROM `log_civicrm_activity` WHERE `log_action` = 'Insert'  is not a good thing to do as it stops you retrieving detailed information from the log_civicrm_activity table for log_action = update. 

DELETE  FROM `log_civicrm_activity` WHERE `activity_type_id` = 19 is an OK thing to do (19 is bulk email on our install).  The change log tab loads faster and the details of any Activity update can be retrieved.