Grouper Developers Forum

[Tom Barton <>]

Chris Hyzer wrote:
>  > 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]?
>
> For this particular query, Im not sure the search will happen on the 
> user auditing, but rather it might go against the point in time data...  
> e.g. if you want to know all memberships changed for a person, that will 
> be in the point in time, but if someone creates a table, there are 
> permission memberships created for that group.  There would not be a 
> user audit for that membership (but there would be for the create 
> group).  I would picture queries like:
>
> 1. Find all actions that a person did on a certain day.  Filter on 
> certain columns (if no action type is selected, then you cant really 
> filter on string01 col effectively).
>
> 2. Find all group actions done to group id fds78sdf687sd
>
> In order for it to work, first you pick the category or action you want, 
> and the filters would become available (e.g. the group id is string01)
>
>  > 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?
>
> I already have a DB view: but the cols are: label_string01, string01, 
> label_string02, string02, etc.
>
> We can easily make a Java interface, and a GSH interface.  The WS if we 
> need it could be like the DB view.  And the UI could go one of two ways:
>
> 1. If the user selects a category and action pair, the headers could be 
> across the top, and the data in a grid.
>
> 2. If multiple types of actions are displayed at once, then each cell 
> will need the label and the data...  I assume the grid will be sortable, 
> so we cant really group by action type...
>
> One thing that will make this better is if I move ID and NAME out of the 
> string01 string02 fields, and make their own column.  This way on the UI 
> you could just search by id abc123 and more easily find what you are 
> looking for...  all actions have an id col, and most have a name col...
>
>  > Will there be, say, a Loader task that appends
>  > text representations of recently audited actions to a chronological log?
>
> I hope the text description is in the description field, so it wont need 
> to consult the string01 fields.  Also, we should discuss the 
> requirements, since this also might be a good candidate for either point 
> in time, or even notifications which queues up actions in a list...
>
> Im not really sure what the concern is...  do you not think this data 
> structure will work?

Partly it's to help bake the data structure. Partly to get clearer about 
what else, beyond this structure, is needed as part of the solution. 
Partly to bake a little further which capabilities are needed in which 
systems (user audit, PIT, notification), and which problems those 
capabilities are needed for.

I didn't have the impression we'd all gotten on the same page about such 
things yet, only for lack of sufficient time to discuss it.

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?

Thanks,
Tom