Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] changelog implementation sketch

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] changelog implementation sketch

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>, Tom Zeller <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Fri, 06 Jun 2008 16:03:43 +0100

--On 06 June 2008 09:27 -0500 Tom Barton

Tom Zeller wrote:
8) We should also audit/notify when a Member's subject id is

I've worked out an example for this.

Interesting. Strictly speaking we don't remove/add members where we
change subject id, on the other hand consumers of the affected
groups would probably want to 'know' about such changes. Possibly we
could indicate the member_uuid as well as the subject identifiers
without implying and add/remove?

Ah, right, membership persists when subject ids change as far as
grouper is concerned. Perhaps consumers would just have to know whether
or not to ignore consequent membership changes in the same change as a
subjectId modification.

I think a change to a subjectId is needed for audit, but should be
transparent to notification. Only grouper needs to know about such a
change - presumably if the change has impact in other parts of a site's
IAM operation, they'll make corresponding updates using tools other than
their group management system.
There is interest in using notifications to prompt provisioning of changed objects. In effect the membership of one or more groups are likely to have changed and would need to be re-provisioned.

This makes me think about how transactions are bundled and assigned
change numbers. A "change subjectId" action probably shouldn't be bundled
into a transaction that also impacts groups, stems, or memberships. Is
that how it works now?
Any of these changes may well be in one database transaction - in the UI they would be. Someone coding the API in their own tool could code different transactions.

Changes to grouper metadata also fall into the same category.

Maybe a "transparent change" boolean column is needed in the audit table,
to let notifiers skip transparent changes?
We should be recording the type of object a change was made to - so a notifier should register for the types of changes it is interested in


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page