Grouper Developers Forum

[Tom Barton <>]

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?

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?

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