Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] hooks and notifications

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] hooks and notifications

Chronological Thread 
  • From: Tom Barton <>
  • To: "'Grouper Dev'" <>,
  • Subject: Re: [grouper-dev] hooks and notifications
  • Date: Wed, 28 May 2008 08:09:01 -0500

GW Brown, Information Systems and Computing wrote:

--On 27 May 2008 16:30 -0500 Tom Barton
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).

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

Archive powered by MHonArc 2.6.16.

Top of Page