Grouper Developers Forum

[Tom Barton <>]

If I'm understanding this correctly, we need an audit metadata table so 
that a UI can know how to present data from multipurpose columns in the 
audit table, and if we take this approach there are issues about 
versioning of these representations.

This is so that a UI or other client of an audit interface can allow ... 
exactly which types of actions? Search all actions taken on $Subject? By 
$Subject? During [$Time1, $Time2]?

I'd like us to look at a sketch of the interface that this data 
structure will support. And will that be a java interface, a DB view, a 
WS interface, or what? Will there be, say, a Loader task that appends 
text representations of recently audited actions to a chronological log?

Tom

Chris Hyzer wrote:
> Im open to suggestions, but here is my current plan:
>
> 1. If adding, and assuming there is an open row:
>         a. Just add it, old data is null
>         -or- b. Update all existing rows to something like NA, and add it
> 2. If changing a col:
>         a. Null out all existing audit entry cells with that category / 
> action / header
>         -or- b. Update all existing rows to something like NA, and change it
> 3. If deleting a col:
>         a. Null out all existing entries of that category / action / header
>
> We need the data to be consistent, we cant have data in a cell which doesn't 
> correspond to the header.  Also, the data isn't intended to be used 
> programmatically, except possibly for UI links.  Picture a UI with audit data 
> in it, the group change could be a link based on the uuid of the group.  If 
> the description col is blank, or NA, or there, it just enhances the UI, but 
> doesn't make a system break... right?  The uuids I think are the minimum 
> data, the other stuff is nice to have.  The real data that we can link to 
> from other systems can be accessed through point in time auditing...  
> Speaking of which, we will have the same situation when we add cols to 
> things, and add corresponding cols to point in time, then we will have to do 
> option a. or b. above...
>
> Thoughts?
>
> Regards,
> Chris
>
> > -----Original Message-----
> > From: Tom Zeller 
> > [mailto:]
> >  On Behalf Of Tom Zeller
> > Sent: Saturday, February 07, 2009 11:19 AM
> > To: Chris Hyzer
> > Cc: Grouper Dev
> > Subject: Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09
> >
> > Given version +1 in which we decide we'd like to add or change the
> > string (or int) columns' data, how do we maintain the different
> > versions' representation ? especially for 'long term' auditing/history
> > ?
> >
> > On Feb 6, 2009, at 2:25 PM, Chris Hyzer 
> > <>
> >  wrote:
> >
> > > > 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...
> > > >