Grouper Developers Forum

["Tom Zeller" <>]

Please see comments inline.

On Fri, May 30, 2008 at 2:18 PM, Chris Hyzer <> wrote:

I was thinking of the auditing could be used to see who did what when from where.

 

So, not considering the use of this for systems to stay in sync with grouper, it would be one table and the columns could be something like:

 

log_id,

timestamp,

subject_id_who_made_change,

source_id_who_made_change,

act_as_subject_id_who_made_change,

act_as_source_id_who_made_change,

ip_address_of_person_who_made_change,

category (e.g. group),

action (insert),

description (e.g. group created with name 'whatever:whatever' and description 'this is the des…' and friendly name 'Whatever stem: Whatever Group'),

system (prod_ui, test_web_service, my_gsh),

object_id (group_id),

optional_field,

optional_field2

 

I assume that deployers will want to store widely different searchable 'metadata' about a change and those needs may vary over time, hence the table structure which allows folks to add (and append without changing database schema) whatever attributes they desire.

Note that the behind the scenes changes to the registry might not need to be added (e.g. that GrouperAll was added as a member).  Its more just what users / clients do from an external perspective…

 

I agree that the table would need to auto-delete some old records, since these grow large.  So I would think that recreating the point in time wont be possible (or are we planning on working backwards?)  right?

I think someone mentioned that, during the first attempt at this, we might not want to tackle the ability to recreate any give point in time in the past (ala Time Machine...although that would be cool). The word snapshot comes to mind. Of course, we can only work backwards as far as we can store data, which seems site dependent.

 

I think a requirement should be that this thing should be gentle on system performance.  If we are writing files, storing multiple rows, etc it might take a performance hit…

 

Also, from an architecture perspective, I am all that keen on storing local files.  If you wanted a hot/standby redundancy setup, now the disk is involved, instead of the DB…

The filesystem (which everyone has) is a simple *default*, deployers could use ldap or a db or NFS or whatever they choose, ideally, as long as they provide that implementation (which they could then share with the rest of us :) 

 

 

Regards,

Chris

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Friday, May 30, 2008 2:50 PM
To: Grouper Dev;
Subject: [grouper-dev] changelog implementation sketch

 

Howdy folks,

 

Based on our discussions of hooks+notifications and correspondence from TomB, I have sketched a changelog implementation :

 

https://wiki.internet2.edu:443/confluence/x/lVw

 

It's rough in places (and perhaps just plain wrong in others), some ideas I scraped from the list and some I just cooked up; it however represents my allotted time so far.

 

Your comments are appreciated.

 

TomZ