Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 28 May 2008 08:09 -0500 Tom Barton 
<>
 wrote:

> GW Brown, Information Systems and Computing wrote:
> > --On 27 May 2008 16:30 -0500 Tom Barton 
> > <>
> >  wrote:
> > > I know of actual use cases for veto (Bert, is that what you mean by
> > > "filter"?) and for notification (including notification to an audit
> > > log). I don't think I know any, as yet, for plug-ins to enhance events.
> > > Nor do I see why any such uses would have to be tightly-coupled to the
> > > originating event, in the same transaction.
>  >
> > I would like the ability, when a group is created, to set some group
> > attribute values (and possibly add some group types) and have those be
> > part of the transaction. New values would depend on existing values and
> > location in the hierarchy - but you don’t need to know the details...
> >
> > The current way of using lots of individual API calls to build a group
> > isn’t very satisfactory in this respect. Ideally these types of changes
> > could be effected using new single API methods i.e.
> >
> > Stem.addChildGroup(String extn, String displayExtn, Set types, Map
> > attributes)
> >
> > Group.setAttributes(Map attributes)
> > Group.setAttributes(Set newTypes, Map attributes)
> > Group.setAttributes(Set newTypes, Map attributes, Set removeTypes);
> >
> > Similarly, for adding / removing members or privilegees:
> >
> > Group.addMembers(Set subjects)
> > Group.addMembers(Set subjects,Set subjectsToRemove)
> >
> > Rather than generating lots of ‘small’ changes, a single ‘large’ change
> > can be vetoed, amended* or notified). I can’t sensibly choose to veto
> > type/attribute changes to a group without knowing what all the changes
> > are - and currently when you make one change the API has no knowledge of
> > any API calls you intend to make in the next lines of code.
>
> I zero in on the word "ideally" above, and agree. You are saying that
> there's a use case for enhancing the API, but you'd settle for the
> ability to meet your need with a plug-in. Why don't we just put it in the
> API for 1.4.0?
It is actually both - we need to enhance the API and then it becomes 
practical to use hooks to deal with the complete changes.
> Are there other actual use cases for enhancing groups by plug-in?
None that immediately come to mind.
> > > However, I *do* want reliable audit history. And I don't want that to
> > > depend on a separate process calling back to the DB for the details on
> > > what changed, in case it may have changed again in the meanwhile. I'd
> > > like instead to have a logical description of each completed transaction
> > > preserved somewhere in the grouper DB when the transaction completes.
> > > This history-of-changes table could have a configurable depth (time or
> > > size) and would necessarily serialize all transactions, thus also
> > > providing the basis for reliable notification by 3rd party
> > > implementations. The hard part of this is deciding what the "logical
> > > descriptions" are - it's not which columns in which tables have what new
> > > values. Think of LDIF as a motivating example. The grouper event log, at
> > > INFO level, is probably capturing the right events, but not with the
> > > right schema.
>  >
> > So are we looking at tables with:
> >
> > date, transaction_id, member_id
> >
> > transaction_id, object_id, object_type, change*
> >
> > *where change is a clob, or similar, which has a representation of
> > changes to the object.
>
> Something like that, although I don't think we need to store large
> objects, we should have a sequential change number to preserve the order
> in which things were changed in the DB, and I'd add names for objects in
> addition to their internal ids.
The reason I was thinking of large objects was that some changes to large 
memberships would beak varchar2 limits - but I see your comment below about 
using individual rows for each change.
> > New API methods would allow a client to query for all changes since a
> > certain date (filterable by object type, and optional object_id) and
> > would return consolidated changes for each object changed.
>
> Pulling things out of the history table could be but needn't be in the
> API per se as the table is independent of anything else.
I guess some tool to provide an interface to the history table would be 
useful but it could be an extension - should anyone care to write one.
> > The devil would be in the detail of how you represent the changes - they
> > need to be easily machine readable.
>
> LDIF and RDF are both machine readable and at least one certainly has the
> breadth to cover our functional domain. Probably a variation of the other
> does too. So I think we've got both semantic and more traditional means
> open to us.

> > Also, do we ‘log’ effective changes?
>
> Current event logs do contain effective changes. We could reflect each
> effective change in the history table with an additional row having the
> same change number as the originating event (and transaction id, if
> that's true).
My main concern here would be the number of database writes and the size of 
the tables, but it would certainly be easier to query.
> Tom



----------------------
GW Brown, Information Systems and Computing