Grouper Developers Forum

[Chris Hyzer <>]

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

 

Yes

 

> and if we take this approach there are issues about

> versioning of these representations.

 

Well, I am too concerned about versioning per my previous email

 

>

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

 

Chris