Grouper Developers Forum

[Chris Hyzer <>]

> 
> I'd like us to review ideas for how the string and int cols will be
> used
> for a representative set of operations, before you get too far down
> this
> path.

Here is my current plan (who wants to look at some source code?!?!  :) ):

http://viewvc.internet2.edu/viewvc.py/grouper/src/grouper/edu/internet2/middleware/grouper/audit/AuditTypeBuiltin.java?root=I2MI&view=markup

So far, only the String cols are used, not integer.  I picture int cols for 
things like the loader where you capture how many inserts/updates/deletes 
took place.

Anwyays, so for a membership add:

MEMBERSHIP_ADD(new AuditType("membership", "addMembership", null, "id", 
"fieldId", "fieldName", "memberId", "membershipType", "ownerType", "ownerId", 
"ownerName")),
 
The audit category is "membership", and the action in that category is 
"addMembership".  The category and action are a unique key in the audit type 
table.  The String fields to capture for a membership add are:

"id", "fieldId", "fieldName", "memberId", "membershipType", "ownerType", 
"ownerId", "ownerName"

And all the other standard data is always captured: IP address, who was 
logged in, what system, actAs user, etc

For a group update, I will capture this misc string data:

"id", "name", "parentStemId", "displayName", "description"

Note, the old values arent in there, just the new values.  I was thinking I 
would put that in the audit description column, something like:

Group 'penn:community:employee' was changed:
  - Display name was: 'Penn:Community:Employee Group', and is now: 
'Penn:Community:Employees of Penn'.

Note that this is just for a UI so people can see who (or what) invoked high 
level grouper operations, and what the user did.  If you want a more data 
oriented output of what fields and underlying tables were changed, it will be 
in the point in time auditing tables by context id.  I don't think we need to 
reinvent that here by making an XML representation of what changed etc... it 
is in the point in time system...

Sound good?

> 
> > 3.       I think we should drop the created_by and modified_by cols
> in
> > the grouper tables (e.g. grouper_groups and grouper_stems), since
> these
> > will be maintained in the user auditing.  The user auditing will tell
> > you who the logged_in user is, who the act_as user is, etc.  I think
> the
> > created_by and modified_by is just who the grouperSession belongs to,
> so
> > it might even be meaningless.  Does anyone use these, or does anyone
> > object?  Oh yeah, I need to update those in memberChangeSubject calls
> > potentially when merging subjects...
> 
> Any reason they can't stay there, maybe purposelessly, until we're
> happy
> with how the auditing is going?
> 
> Are there GrouperQuery filters that select on these?
> 
> If those cols are gone and deployer opts to disable logging, deployer
> is
> just totally blind to what's happened then?


We can keep them until 1.6 if people need them...  they are not great data 
though, if someone cares about knowing who created something or who last 
updated something, I would think they would want it to be correct.  i.e. in 
the UI if I act as admin, it is logged as GrouperSystem added a membership... 
that doesn't do me much good.  anyways, we can wait until later if you like.  
Though I might note, the point in time auditing is something people might 
want to turn off since it might require a lot of space in the DB.  The user 
auditing I would think is more lightweight, and people should only turn it 
off if it is causing problems... but anyways, we can see how it goes.  :)

Kind regards,
Chris