CiviCRM Community Forums (archive)

Hi,

My specific needs are fairly basic and would be covered by what you describes:

- being able to track changes before/after the contact himself modifies his datas (eg. registration on an event with a profile)
- being able to track changes on the imports (easy way to quickly mess a lot of contacts in a row).

My experience with storing all the versions of all the fields everytime you modify a single letter is that it quickly becomes unbearably slow (won't drop name, but the guilty should recognise themselves). I personally think there is a much bigger risk in slowing down the regular "edit" of a contact by 0.5 second than overwriting the previous version.

Instead of storing the before/after of all the fields, I'd rather have a system that only stores the ones that have changed (Yes, I'm aware that checking which ones have changed might be as time consuming as copying them). However, having a "attribute granularity" in the history would fit very well with another feature i'd love seeing:

front office "web 2"  editing, eg. in the view contact page, you double click on the first name on the person, this transforms it into a field and add a save/cancel button, you can alter the first name and saves it directly, without having to go through the complete edit page with all the fields. In this usage scenario, saving the fields separately (even with keeping the history) would actually be quicker than saving all the fields of the contact.

Another feature that is somehow related to the contact/field versioning is provide a beloved "undo" instead of the uber annoying "are you sure you want... ?".

What do you think ?

On my side, I'm willing to put some money on the table to see an contact versioning, I'd strongly suggest doing it at the attribute level, and I'm going to try enrole people around for that idea.

Stay tuned...

X+

I think one potential solution for this is to use a combination of triggers and stored procedures. the system can use some UI screens to modify the default tables / fields that are being tracked. On any insert/update/delete for a row in a table, the appropriate trigger is invoked. This can call a stored procedure and based on how you want the differential stored, you can either store it in a shadow table or a log table.

There is a fair amount of info on the web on various ways to do so (search for shadow table, versioning, logging). I suspect doing it at the database level will be a faster, cleaner and more scalable approach

lobo

Lobo's database-based solution sounds like the way to go. Especially if we can (eventually) expose some admin controls for it in the UI and functions in the API. A revision browser, revert controls, audit log viewer based on the revisions (on 9/1/07 user X edited the foo field from "blah" to "meh"), etc.

We'll probably need this too in the not-so-distant future (i.e. once more of the folks I work with start using Civi, they'll ask for it).

tha same place as it was on june 18. still in the feature request/suggestion queue. this is currently not on the short/medium term roadmap. will need to be either community contributed or sponsored feature

lobo

if i had to take a random guess, revisioning for contacts is probably a HUGE project (note that this encompasses a lot of other tables in addition to civicrm_contact (address, phone, email,  notes, activity, all custom fields etc). This is not including any of the component tables (contribution etc)

i'd probably throw out at least 300-400 hours to begin with. it will be a major release (IMO)

lobo