Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09


Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Tom Zeller <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09
  • Date: Sat, 07 Feb 2009 12:15:37 -0600

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...






Archive powered by MHonArc 2.6.16.

Top of Page