Grouper Developers Forum

[Tom Barton <>]

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?

Are there other actual use cases for enhancing groups by plug-in?

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

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

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

Tom
begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard