Grouper Developers Forum

[Chris Hyzer <>]

> 
> I'm not quite clear yet about the problems these user audit
> capabilities
> will address that won't necessarily be addressable by the point-in-time
> stuff. Can you describe a distinguishing example?
> 

The PIT in time will tell you if someone was a member of a group at a certain 
point in time (among other things).  All it is is a copy of all the old data 
when a change happens.  So if there is an insert, there is not a 
corresponding record in PIT shadow table (one for each grouper table).  If 
there is an update, the old record is in PIT.  If there is a delete, the 
deleted record is in PIT.

The user auditing will tell you which PIT entries were made by whom, from 
which IP address, from which system (e.g. UI or WS), etc.  And they are 
grouped by contextId, so multiple PIT entries point to one user auditing 
entry.  If you want to know what a user did in Grouper on a certain day from 
a high level (added a group, added a few members to a group, etc), that is 
user auditing.  If you want to know all the underlying tables touched, that 
is PIT in tandem with user auditing.  We can also audit other stuff in user 
auditing too.  E.g. each web service call could optionally insert a new user 
audit (for debugging or auditing reasons).  Each UI page view could 
optionally insert a new user audit.  Then we can see page flows, and more 
easily see where a user is having issues.  We do this at Penn and it is very 
valuable...  you can then make views and reports about how many users per 
amount of time, which pages are most heavily used, etc.

Example:

User deleted a group

UserAuditing:

One Record: User John Smith deleted group a:b:c from ip address 1.2.3.4 using 
the UI

PIT:

a. 4 records for each deleted membership
b. 3 records for each deleted privilege
c. 7 records for each deleted attribute value
d. 3 records for each group type tuple deleted
e. 1 record for the deleted group

Sound good?

Thanks,
Chris