Grouper Developers Forum

[Chris Hyzer <>]

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

I think it should be possible (maybe configurable) that subjectId change warrants notification

 

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

 

No, a change subjectId can now be in the same tx.  I would think if something is in the same tx that audit table should be consistent with that.

 

> With the current set of re-worked examples, it looks like the only changes of interest to consumers for notification are those of

> the 'group' object_type. If the changed object_type is 'stem' or 'type' or 'subject', then consumers can ignore those changes, but

> they are audited. So I'm leaving the "transparent change" column out for now, unless other convincing occurs.

 

I think consumers should get the choice for what they want notification on…  might not even be site-wide, but instead could be different for different types of notifications…

 

Perhaps the audit data could have the same level of granularity (e.g. maybe some people don’t want to audit certain things, or the cleanup rules are different for different types of things), and could be accomplished via hook.

 

Regards,

Chris

 

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Friday, June 06, 2008 2:35 PM
To: Tom Barton
Cc: GW Brown, Information Systems and Computing; Grouper Dev
Subject: Re: [grouper-dev] changelog implementation sketch

 

On Fri, Jun 6, 2008 at 9:27 AM, Tom Barton <> wrote:

Tom Zeller wrote:

       8) We should also audit/notify when a Member's subject id is changed

       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.

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?

 

Well, "change subjectid" actions were bundled when I thought that changing a member's subjectId should include auditing effective group membership changes, but I see now that those group membership changes shouldn't be audited after all. So, changing a subjectId looks like an atomic (stand alone, unbundled) change. phew.

 

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?

 

With the current set of re-worked examples, it looks like the only changes of interest to consumers for notification are those of the 'group' object_type. If the changed object_type is 'stem' or 'type' or 'subject', then consumers can ignore those changes, but they are audited. So I'm leaving the "transparent change" column out for now, unless other convincing occurs.